• Партнер

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

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

    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии