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

Теперь расскажу о настройке. Вначале консольный вариант. В комплект пакета
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

Скрытая сила пробела. Эксплуатируем критическую уязвимость в Apache Tomcat

В этой статье мы поговорим о баге в Apache Tomcat, популярнейшем веб-сервере для сайтов на…