[devel] Добавить новый пакет keychain в Sisyphus (fwd)

Andrei Bulava =?iso-8859-1?q?abulava_=CE=C1_altlinux=2Eru?=
Чт Мар 4 19:59:29 MSK 2004


On Thu, 4 Mar 2004, Dmitry V. Levin wrote:

<skip>

> Я не улавливаю, зачем про каждый новый пакет спрашивать
> incoming@?

:-))) ответ, на мой взгляд, должен быть занесен в fortunes-ALT,
но как его понимать мне?

Первое, что приходит в голову - истолковать ваш риторический
вопрос в свою пользу, т.е. залить keychain в
/incoming/Sisyphus/BTE несмотря на

> Что касается моего личного мнения, то я активно использую ssh
> agent и при этом считаю keychain совершенно ненужным
> изобретением.

Вот прямо сейчас у меня открыта ssh сессия на шлюз, с которого я
достаточно часто и в разные места хожу по ssh. Я не знаю, как мне
задействовать ssh-agent и при этом иметь возможность не держать
постоянно открытой сессию на шлюз. keychain позволяет мне не
задумываясь открывать / закрывать сессию на шлюз тогда, когда
мне это удобно.

> Что касается ввода пароля и подтверждения разрешения
> использования ключа, то я настоятельно рекомендую ознакомиться
> с этим советом:
> http://www.mindrot.org/pipermail/openssh-unix-dev/2004-February
> /020641.html

Если я правильно понял, то речь идёт о полезности использования
"ssh-add -c". На мой взгляд, вопросы о пользе keychain и пользе
"ssh-add -c" находятся в ортогональных плоскостях. ssh-agent, в
который добавлена identity с опцией "-c", ведёт себя точно также,
как если бы я просто не использовал ssh-agent, а держал
запароленный приватный ключ в домашней директории или в любом
другом месте файловой системы.

Случай "ssh-add -c" даёт мне возможность не держать приватный
ключ на ФС, а загнать его в память. Ещё раз: при использовании
keychain я смогу добавить ключ через "ssh-add -c" и спрятать
носитель с приватным ключом до тех пор, пока не будет остановлен
keychain.

cron задачи - отдельная история, для них, как правило, заводятся
ключи, помещаемые в authorized_keys[2] с опцией command. Тем не
менее, это ещё не повод для того, чтоб делать такие ключи
беспарольными. Есть некоторая разница в уровне квалификации,
необходимом для получения прав root с перезагрузкой системы или
без таковой. Во втором случае, конечно, проблема при
использовании keychain проявится. С беспарольным ключом она
проявится в обоих.

Есть ещё и третий случай - смотреть
http://www.kde.org/history/rms.php по ключевому слову passwords.

Лично я не до конца разделяю оптимизм Столлмэна и предпочитаю при
использовании cvs over ssh висящий в памяти ssh-agent с
расшифрованным ключом, а не забивать пароль в услужливую среду
разработки. А вводить пароль при каждом обращении к cvs мне бы
пришлось слишком часто.

// AB1002-UANIC



Подробная информация о списке рассылки Devel