Использование SSH ключей
From ArchWiki
i18n |
---|
English |
Русский |
Использование SSH-ключей для подключения к серверу
Зачем использовать эти ключи?
Использование ssh-ключей, а точнее открытого и закрытого ключей - простой способ подключаться к серверу или к целой связке серверов используя один пароль ИЛИ не используя пароль вообще. Лучше было бы выбрать комбинацию пароль/ssh-agent!
Шаг 1: генерирование ключей
mith@middleearth||[[~]]:~ > ssh-keygen -b 2048 -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/mith/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/mith/.ssh/id_dsa. Your public key has been saved in /home/mith/.ssh/id_dsa.pub. The key fingerprint is: x6:68:xx:93:98:8x:87:95:7x:2x:4x:x9:81:xx:56:94 mith@middleearth mith@middleearth||[[~]]:~ >
Что было сделано? Была сгенерирована пара ключей public/private DSA (-t dsa
) длиной 2048 bit (-b 2048
) с помощью команды ssh-keygen
. Вы также можете создать RSA ключ (-t rsa
). Вы можете изменять параметр длины в битах (по умолчанию она равна 1024).
Если вам не нравится имя ключа по умолчанию, вы можете указать имя, используя параметр -f name
.
В процессе вам было предложено выбрать место хранения ключей. Был выбран стандартный путь. Потом вас спросят о фразе-пароле.
Есть два пути, которые вы можете выбрать:
a) короткий, но небезопасный путь: не использовать фразу-пароль, иметь лёгкий доступ до удалённого сервера, бояться кражи ключа
b) более длинный, менее удобный, но безопасный путь: использовать фразу-пароль, использовать ssh-agent и чувствовать себя в безопасности.
Шаг 2: копирование ключа на удалённый сервер {одинаково для A и B}
mith@middleearth||[[~]]:~ > scp .ssh/id_dsa.pub mith@metawire.org:
Скопируйте public ключ (id_dsa.pub
) на ваш удалённый сервер с помощью scp (обратите внимание на :
(двоеточие) в конце адреса сервера. Таким образом файл окажется в домашнем каталоге на сервере, но вы можете указать другой путь, если хотите.
Шаг 3: вход на удалённый компьютер и выкладывание своего ключа в нужном месте {одинаково для A и B}
mith@middleearth||[[~]]:~ > ssh metawire.org mith@metawire.org's password: -bash-2.05b$ mkdir .ssh/ -bash-2.05b$ cat id_dsa.pub >> .ssh/authorized_keys -bash-2.05b$ rm id_dsa.pub -bash-2.05b$ chmod 700 .ssh -bash-2.05b$ chmod 600 .ssh/authorized_keys
Мы подключаемся к удалённому серверу и используем команду cat
для добавления содержимого id_dsa.pub
в authorized_keys
, который находится в скрытой директории .ssh
. Обратите внимание: Если вы получаете сообщение об ошибке, связанное с тем, что директрия .ssh
не существует, просто создайте её (mkdir .ssh
).
После этого мы удаляем публичный ключ (rm id_dsa.pub
) и выставляем правильные права на .ssh
и authorized_keys
.
После этого следует выйти из системы и войти снова. В зависимости от того пути, который вы выбрали, вас спросят или не спросят о секретной фразе. Путь A здесь кончается.
...продолжение пути B...
Теперь о том, что делает этот путь практически таким же простым, как и путь без секретной фразы. Это ssh-agent. Он просто спрашивает у вас один раз каждую сессию секретную фразу вашего приватного ключа и каждый раз, когда вам нужно будет его ввести, ssh-agent
сделает это за вас. ssh-agent
включен в пакет openssh
, поэтому беспокоиться об этом не стоит...
mith@middleearth||[[~]]:~ > ssh-agent SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK; SSH_AGENT_PID=2148; export SSH_AGENT_PID; echo Agent pid 2148;
Когда вы запустите ssh-agent
, он выведет на экран несколько команд, задающих переменные окружения. Если их выполнить, эти переменные станут доступны другим процессам, запущенным позднее. Чтобы сделать это, вызовем ssh-agent
таким образом:
mith@middleearth||[[~]]:~ > eval `ssh-agent` Agent pid 2157
ID процесса, конечно, может отличаться от вашего. Добавление eval `ssh-agent`
в ваш файл .bashrc
- возможный вариант, чтобы команда запускалась каждый раз, когда вы запускаете новый shell
Итак, теперь ssh-agent
запущен, осталось сообщить ему, что имеется приватный ключ и место его расположения.
mith@middleearth||[[~]]:~ > ssh-add .ssh/id_dsa Enter passphrase for .ssh/id_dsa: Identity added: .ssh/id_dsa (.ssh/id_dsa)
При вопросе о секретной фразе, просто введите её. Теперь вы можете залогиниться на удалённую машину без нужды вводить ваш пароль, а ваш приватный ключ находится под паролем. Неплохо, ага? Единственный минус этого подхода - то, что вам придётся создавать новый процесс ssh-agent
для каждой открытой консоли (оболочки), поэтому вам придётся каждый раз запускать ssh-add
в новой оболочке. Есть обходной путь для этой проблемы, использующий программу (скорее, скрипт), который называется keychain, он будет, возможно, описан в следующей секции {...работа продолжается}.
Использование keychain
Keychain управляет приватными ключами. При запуске он спросит вашу секретную фразу для ключа (каждого) и сохранит ее. Таким образом, ваш приватный ключ защищен паролем, но вам не придется вводить ваш пароль раз за разом.
Установите пакет keychain.
Отредактируйте ваш ~/.bashrc
и добавьте следующие строки:
/usr/bin/keychain ~/.ssh/id_dsa [[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh
Я понимаю, что не все используют bash. Запустите keychain --help
и узнаете, как это сделать для других оболочек.
Закройте шелл и откройте снова. Keychain должен запуститься, и, если это его первый запуск, спросит секретную фразу для указанного приватного ключа.
Использование ssh-agent и x11-ssh-askpass
Вам необходимо запускать ssh-agent в каждой новой X-сессии. Ssh-agent будет закрыт, когда X-сессия закончится. Установите x11-ssh-askpass, и он будет спрашивать секретную фразу в начале каждой X-сессии:
pacman -S x11-ssh-askpass
Добавьте в начало вашего ~/.xsession
строки:
eval `/usr/bin/ssh-agent` SSH_ASKPASS=/usr/lib/openssh/x11-ssh-askpass ssh-add < /dev/null # then the end of the file with for example "exec dwm"
Управление SSH-соединением
В файл ~/.ssh/config добавьте следующие строки:
host * controlmaster auto controlpath /tmp/ssh-%r@%h:%p
Что это дает? Это устанавливает "master control" сокет, когда вы производите SSH-соединение. Название сокета определяется параметром controlpath
(%r
= имя пользователя, %h
= имя хоста, %p
= порт).
Этот мастер-сокет используется для каждого успешного соединения после первого, так долго, как существует соединение. Таким образом, если вы подключаетесь командой ssh myuser@myhost.com
, будет создан сокет с именем /tmp/ssh-myuser@myhost.com:22
. Затем, если вы снова подключаетесь по ssh к тому же самому хосту, сокет будет найден и удаленной ssh-сессии будет сказано породить новый шелл. В этот шелл не придется логиниться, он появляется немедленно, как будто вы уже залогинились.
PuTTY
Вышеописанный способ немного сложен при использовании PuTTY на Windows, из-за того, что PuTTY не умеет напрямую использовать ключи, сгенерированные при помощи ssh-keygen. Приватный ключ необходимо сконвертировать утилитой PuTTYgen, которую можно найти здесь. Происходит это так:
- сгенерируйте пару ключей с помощью ssh-keygen на вашем Linux-компьютере (вы можете зайти на него через PuTTY, используя ваши обычные логин/пароль)
- добавьте открытый ключ в файл ~/.ssh/authorized_keys
- переместите приватный ключ на машину с Windows
- откройте приватный ключ в PuTTYgen и нажмите Save private key. Он будет сконвертирован таким образом, что PuTTY сможет его использовать.
- запустите PuTTY, зайдите в SSH->Auth и найдите приватный ключ. Затем просто подключитесь к вашему Linux-компьютеру. У вас будет запрошено имя пользователя и секретная фраза (если вы ее вводили, когда генерировали ключ).
Заметьте, что обратный процесс, то есть генерирование пары ключей с помощью PuTTYgen и конвертирование публичного ключа с помощью ssh-keygen, НЕ будет работать.
Полезные ссылки и дополнительная информация
- Man-страница на русском: ssh-keygen(1)
- SSH with Keys HOWTO
- HOWTO: set up ssh keys
- OpenSSH key management, Part 1
- OpenSSH key management, Part 2
- OpenSSH key management, Part 3
- Getting started with SSH
- Manual Pages: ssh-keygen(1)
- Sharing SSH keys on 2 linux servers
- How to set up SSH keys: Frustration with "Server refused our key" [PuTTY]
- Securing your secure shell (SSH) service
- RFC 4251 — Архитектура протокола SSH