Как настроить ssh для аутентификации пользователя с использованием ключей вместо имени пользователя / пароля?
Для каждого пользователя: они должны сгенерировать (на своем локальном компьютере) свою пару ключей, используя ssh-keygen -t rsa (в rsa можно заменить на dsa или rsa1 тоже, хотя эти варианты не рекомендуются). Затем им нужно поместить содержимое своего открытого ключа (id_rsa.pub) в ~/.ssh/authorized_keys на сервере, на котором выполняется вход.
Я действительно предпочитаю ssh-copy-id, скрипт, установленный по умолчанию на * nix (можно поставить на Mac OS X достаточно легко), который автоматически сделает это за вас. На странице руководства:
ssh-copy-id - это скрипт, который использует ssh для входа на удаленный компьютер (предположительно с использованием пароля для входа, поэтому аутентификация по паролю должна быть включена, если вы не умело использовали несколько идентификаторов)
Он также изменяет разрешения дома удаленного пользователя, ~ / .ssh и ~ / .ssh / authorized_keys, чтобы удалить возможность записи для группы (что в противном случае помешало бы вам войти в систему, если удаленный sshd имеет StrictModes, установленный в его конфигурации).
Если задана опция -i, то используется файл идентификации (по умолчанию ~ / .ssh / identity.pub), независимо от того, есть ли какие-либо ключи в вашем ssh-agent.
Хм, не понимаю. Просто создайте ключ и приступайте. :) КАК Дополнительно можно запретить вход по паролю. Например, в / и т.д. / ssh / sshd_config:
PasswordAuthentication no
Это довольно просто сделать - нужно простое пошаговое руководство. найдено здесь.
Основные моменты:
ssh-keygen на вашей машине. Это сгенерирует для вас открытый и закрытый ключи.~/.ssh/id_rsa.pub) в ~/.ssh/authorized_keys на удаленной машине.Важно помнить, что это даст любому, у кого есть доступ к закрытому ключу на вашем компьютере, такой же доступ к удаленному компьютеру, поэтому при создании пары ключей вы можете выбрать здесь пароль для дополнительной безопасности.
Для пользователей Windows для установки шпатлевки
Подводя итог тому, что говорили другие, настройка ключей SSH проста и бесценна.
На машине, на которой вы будете SSHing из вам нужно сгенерировать свою пару ключей:
claudius:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/dinomite/.ssh/id_rsa): <ENTER>
Enter passphrase (empty for no passphrase): <PASSPHRASE>
Enter same passphrase again: <PASSPHRASE>
Your identification has been saved in /home/dinomite/.ssh/id_rsa.
Your public key has been saved in /home/dinomite/.ssh/id_rsa.pub.
The key fingerprint is:
a3:93:8c:27:15:67:fa:9f:5d:42:3a:bb:9d:db:93:db dinomite@claudius
Просто нажмите Enter в указанном месте и введите парольную фразу при появлении запроса - в идеале он отличается от вашего обычного пароля для входа как на текущем хосте, так и на тех, к которым вы будете подключаться по SSH.
Затем вам нужно скопировать ключ, который вы только что сгенерировали, на хост, который вы хотите использовать по SSH. к. В большинстве дистрибутивов Linux есть инструмент ssh-copy-id для этого:
claudius:~$ ssh-copy-id caligula.dinomite.net
Now try logging into the machine, with "ssh 'caligula.dinomite.net'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Если в вашем дистрибутиве этого нет, вам следует скопировать ключ на целевой хост и добавить его в (возможно, существующий) .ssh/authorized_keys файл:
claudius:~$ scp .ssh/id_dsa.pub caligula.dinomite.net:
id_dsa.pub 100% 1119 1.1KB/s 00:00
claudius:~$ ssh caligula.dinomite.net
Last login: Sat May 9 10:32:30 2009 from claudius.csh.rit.edu
Caligula:~$ cat id_dsa.pub >> .ssh/authorized_keys
Наконец, чтобы получить максимальную пользу от ключей SSH, вам нужно запустить агент SSH. Если вы используете среду рабочего стола (Gnome, KDE и т. Д.), То при выходе из системы и повторном входе для вас запускается агент SSH. Если нет, вы можете добавить следующее в свой RC-файл оболочки (.bashrc, .profile, и т.д.):
SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS="-s"
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
eval `$SSHAGENT $SSHAGENTARGS`
trap "kill $SSH_AGENT_PID" 0
fi
Это предназначено как контрольный список. Если следовать ему по пунктам, следует рассмотреть наиболее распространенные ошибки входа в систему без пароля. Большинство из этих моментов упоминается в другом месте; это агрегирование.
Должен быть ~/.ssh каталог chmod 700 на каждой машине под учетной записью, которая будет создавать или получать соединения.
(Закрытый) ключ должен быть сгенерирован без парольной фразы, в противном случае может быть запущен агент, который будет содержать расшифрованную версию ключа, содержащего парольную фразу, для использования клиентами. Запустите агент с ssh-agent $SHELL . Это $SHELL часть, на поиск которой мне потребовалось время. См. Страницу руководства, поскольку там есть множество деталей, если вы хотите использовать агент.
Не забывайте, что по умолчанию слабые (<2048 бит DSA) ключи не принимаются последними версиями sshd.
На клиентской машине необходимо сделать следующее, чтобы возникать связь.
Ваш закрытый ключ должен быть помещен в ~/.ssh/id_rsa или ~/.ssh/id_dsa по мере необходимости. Вы можете использовать другое имя, но тогда оно должно быть включено в параметр -i в команде ssh на исходном компьютере, чтобы явно указать закрытый ключ.
Ваш закрытый ключ должен быть chmod 600.
Убедитесь, что ваша домашняя папка chmod 700.
Теперь позвольте машине получить запрос. Распространенная модель - это когда администратор предоставляет вам доступ к машине, которой вы не владеете (например, к общему веб-хостингу). Следовательно, идея ssh заключается в том, что вы предлагаете свой общественный ключ к тому, кто дает вам аккаунт. Вот почему вы обычно не помещаете закрытые ключи на машину, получающую запросы. Но если вы хотите, чтобы эта машина также выполняла исходящий ssh, вы должны рассматривать ее как исходную машину с помощью шагов, описанных выше.
~/.ssh/authorized_keys под учетной записью, которая будет получить соединения. Вы также можете разместить здесь другие ключи, которым разрешено подключаться через эту учетную запись. Особенно сложная вещь, если вы находитесь в vi и вставляете ключ в файл из буфера вставки в PuTTY, заключается в следующем: ключ начинается с «ssh-». Если вы не в режиме вставки, первая буква «s» переведет vi в режим вставки, а остальная часть ключа будет выглядеть нормально. Но вам будет не хватать буквы «s» в начале ключа. Мне потребовались дни, чтобы это найти.chmod 600 ~/.ssh/authorized_keys. Он должен быть не меньше g-w.Как говорили другие, ваши пользователи должны создать себе пары ключей на своих клиентских машинах с помощью ssh-keygen и добавить свой открытый ключ в ~ / .ssh / authorized_keys на машине, в которую они хотят войти.
Однако для получения более подробной информации я настоятельно рекомендую SSH, безопасная оболочка.
Здесь есть хороший совет, поэтому повторяться не буду. После того, как вы настроили один сервер, чтобы вы могли входить в систему с ключами, вы можете настроить другие, чтобы они делали то же самое с этим одним вкладышем:
remote=server1 server2 server3 server4
for r in $remote; do echo connecting to $r; tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh $r "tar zxf -; chmod 700 .ssh" ; done
Просто перейдите в свой домашний каталог, определите переменную remote как одно или несколько имен серверов и сделайте сразу несколько. Пароль, который он запрашивает, будет вашим паролем ssh для удаленного сервера. Конечно, вы можете использовать упрощенную версию без цикла for:
tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh YOUR_SERVER_NAME_HERE "tar ztvf -; chmod 700 .ssh"
ПОМНИТЕ: копируйте только свои открытые ключи. Вы не хотите, чтобы ваши закрытые ключи лежали на каком-то сервере, где кто-нибудь с sudo может их скопировать и перебрать вашу парольную фразу.