Мало кто знает, что пароль далеко не единственный способ авторизации в системе. Все большую популярность представляют собой беспарольные методы аутендификации. Один из таких методов - ключи.

Смысл ключей состоит в следующем: на удаленную систему закачивается публичный ключ. На компьютере входящего хранится приватный. Затем, после обмена этими ключами система решает - пускать или не пускать клиента.

Теперь расскажу о настройке. Вначале консольный вариант. В комплект пакета OpenSSH поставляется бинарник ssh-keygen, который собственно и занимается генерацией ключей. От тебя требуется указать в параметре -t тип ключа. Их 3 - rsa1, rsa и dsa. Последние два предназначены для второй версии OpenSSH, поэтому их будет юзать гораздо безопаснее. Но стоит упомянуть и об rsa1. После запуска ssh-keygen, ты увидишь примерно следующее:

[forb@ruhost4 forb]$ ssh-keygen -t rsa1 -C 'mykey'
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/users/forb/.ssh/identity): testkey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in testkey.
Your public key has been saved in testkey.pub.
The key fingerprint is:
8c:b3:1f:67:ab:01:8c:ae:60:a1:98:39:32:a5:6c:61 mykey

После всего проведенного ты замечаешь у себя файлы testkey и testkey.pub (приватный и публичный ключ, соответственно). Затем твоя задача будет сделать следующие действия:

scp testkey.pub [email protected]:.ssh/authorized_keys
cp testkey ~/.ssh/identity

То бишь, залить публичный ключ в ~/.ssh/authorized_keys на удаленный сервер и скопировать приватный ключ в свой .ssh каталог. На этом все. Первый протокол должен работать по ключам без пароля. Если ключ находится в другом месте используй параметр -i к /usr/bin/ssh, значением которого будет местонахождение приватного ключа.

Для генерации к примеру dsa ключа для второго протокола, используй тип dsa. Вывод будет примерно такой же. Только файлы нужно будет назвать другим именем. На удаленной машине authorized_keys не изменится (несмотря на man, в котором почему-то говорится, что файл должен называться authorized_keys2, но заработало у меня только с authorized_keys). Приватный же ключ сохраняй в ~/.ssh/id_dsa. Затем попробуй коннектится. В удачном случае будет примерно следующее:

ssh other.server.net
Authenticating with public key "dsa-key-20030209"
Last login: Wed Feb 12 18:09:16 2003 from far.server.net

А теперь о ключевых фразах. Если вдруг ты сочтешь небезопасным сохранять открытый доступ к твоему серверу по ключам, ставь фразу на ключ. Она задается в ssh-keygen (смотри выше). Тогда, при соединении, ssh будет спрашивать тебя фразу на данный ключ, и только в случае ее совпадении пропустит тебя.

Если что-то не получается - man ssh-keygen, man ssh, а также параметр -v к /usr/bin/ssh (verbose output - покажет детально, что в данный момент делает бинарник).

В виндовой ssh тоже все просто. Рассмотрим программу PuTTY. С ней в комплекте поставляется exe-шник puttygen.exe, который является полным аналогом ssh-keygen. Выбираем тип ключа, жмем кнопку Generate, водим мышкой по экрану, чтобы рандомайзер смог сгенерировать код, затем сохраняем последовательно публичный и приватный ключ. Внимание: из за кривоватости сохранения публичных ключей, которые у меня не распознала удаленная система, скопируй его из окошка вверху и занеси в ~/.ssh/authorized_keys на сервере. Приватный можешь сохранять как есть. Затем укажи путь к ключу в PuTTY во вкладке SSH->auth и логинься в систему.

Внимание, к ключам справедливы следующие правила:

1. Ключей в authorized_keys может быть несколько, просто дописывай их в файл, если там уже что-то есть.
2. Вход по ключам является независимым методом, то есть у пользователя может вообще не быть пароля, но по ключам он сможет авторизоваться.

Источник:
http://www.xakep.ru/post/17612/default.asp