KWallet может управлять моими ssh паролями?
Виртуальная машина может дать Вам самую высокую безопасность без перезагрузки, но самую низкую производительность.
Другая опция, даже для повышения уровня защиты, чем виртуальная машина: загрузитесь "живой" CD/DVD/pendrive без доступа к жесткому диску (временно отключают жесткий диск в BIOS; если Вы не можете, по крайней мере, не смонтировать, что диск / размонтировал его, если смонтировано автоматически - но это намного менее безопасно),
Контейнер докера является немного менее безопасной альтернативой полной виртуальной машине. Вероятно, решающее различие (с точки зрения безопасности) между этими двумя - то, что системы, работающие в докере на самом деле, используют ядро Вашей хост-системы.
Существуют программы такой как изолированный, который создаст специальную, защищенную среду - это обычно называют песочницей - это является обычно находящимся в chroot, с дополнительным контролем - находят тот, который соответствует Вам.
Простой chroot будет наименее безопасным (особенно в отношении выполнения программ), хотя, возможно, немного быстрее, но... Необходимо будет создавать/копировать целое отдельное корневое дерево, и использование связывают, монтируется для
/devи т.д. (см. Примечание 1 ниже!). Так в целом этот подход не может быть рекомендован, особенно если можно использовать более безопасное, и часто легче настроить,sandboxсреда.
Примечание 0: К аспекту "специального пользователя", как nobody учетная запись: Это дает едва любую безопасность, намного меньше, чем даже простое chroot. A nobody пользователь может все еще получить доступ к файлам и программам, которые считали и выполняют набор полномочий для другого. Можно протестировать его с su -s /bin/sh -c 'some command' nobody. И если у Вас есть какая-либо конфигурация/история/файл кэша, доступная для кого-либо (ошибкой или незначительной дырой в системе безопасности), программа, работающая с nobodyполномочия могут получить доступ к нему, grep для конфиденциальных данных (как "передача =" и т.д.) и во многих отношениях отправить его по сети или что бы то ни было.
Примечание 1: Как Gilles, на которого указывают в комментарии ниже, простая chroot среда даст очень мало безопасности против использования, стремящегося к расширению полномочий. Единственный chroot имеет мудрый безопасностью смысл, только если среда минимальна, состоя из подтвержденных безопасностью программ только (но там все еще остается риском использования потенциальных уязвимостей уровня ядра), и все недоверяемые программы, работающие в chroot, работают как пользователь, который не выполняет процесса вне chroot. То, что chroot действительно предотвращает против (с ограничениями, упомянутыми здесь), является проникновением целевой системы без расширения полномочий. Однако как Gilles, отмеченный в другом комментарии, даже, тот уровень безопасности мог бы обойтись, позволив программе убежать из chroot.
Я не имею KDE удобный, но я ввел по абсолютному адресу в gnome-keyring немного и похоже, что это выполняет это путем предоставления ssh клиенту альтернативу askpass программа.
Проверьте значение $KWALLET_ASKPASS от Вашего терминала в KDE. Если это установлено на что-то, пробуют это: export SSH_ASKPASS=$KWALLET_ASKPASS.
Если не озираются через пакеты Вашего дистрибутива и видят, существует ли askpass заменяющая программа, связанная с kwallet. Если так, набор SSH_ASKPASS к той программе.
-
1Это работает даже на пароль (в противоположность ключевому паролю)? OpenSSH является очень привередливым о чтении паролей только от терминала. – Gilles 'SO- stop being evil' 25.07.2011, 14:34
Существует запрос новых функций KDE с 2004 для использования kwallet в качестве ssh агента. Вы могли бы хотеть прокомментировать или голосовать по той ошибке.