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

Теперь расскажу о настройке. Вначале консольный вариант. В комплект пакета
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 user@other.server.net:.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. Вход по ключам является независимым методом, то есть у пользователя может вообще не быть пароля, но по ключам он сможет авторизоваться.

Оставить мнение

Check Also

Карманные трояны. Как работают мобильные банкеры

Одним солнечным апрельским утром мой завтрак был прерван телефонным звонком приятеля — пре…