avatar FAQ Вход ssh по ключу ( Linux/Unix )

Авторизация с использованием ключей — более удобный способ выполнять вход в систему, вы можете раскидать свой ключ на множество систем и выполнять вход на них без использования пароля, когда у вас много машин это становится невероятно удобным. Для тестов нам необходимо иметь минимум 2 машины, одна рабочая, на которой мы будем гереировать ключи и выполнять вход на удаленные машины, а вторая целевая, на которую будет выполняться вход в систему по ssh
Для того чтобы выполнить ssh авторизацию по ключу, необходимо выполнить 3 действия:
1) Сгенерировать ssh ключ закрытый ключ и сертификат ( открытый ключ )
2) Разрешить на удаленной машине выход по ключу
3) Положить на целевую машину открытый ключ

Для тестов используется имя пользователя: user

Создаем директорию для ключей
mkdir -p /home/user/.ssh


Генерируем ключи SSH
для этого существует утилита ssh-keygen
ssh-keygen -t rsa -b 1024 -f /home/user/.ssh/id_rsa

Где:
ssh-keygen -утилита для генерации ключа
-t — ключ утилиты отвечающий за тип генерируемого ключа
rsa -тип ключа бывает rsa/dsa
-b -ключ через который указывается длина ключа в bit
1024 — длина ключа, для тестов хватит и 1024 для большей безопасности указываем 2048, более длинный ключ вызывает большою нагрузку на процессор шифровака/дешифровка данных
-f -параметр указывает куда положить ключ
/home/user/.ssh/id_dsa -путь куда положить ключ

В результате в директории /home/user/.ssh/ у нас появилось 2 файла:
id_rsa
id_rsa.pub


Файл с расширением .pub это открытый ключ, его мы забрасываем на сервер к которому будем подключаться по ssh,
файл id_rsa это закрытый ключ, его не сообщаете никому, по нему вы будете осуществлять вход.
Во время генерации ключа система предложит ввести пароль, но тогда придется вводить его каждый раз при входе на сервер, так повышается безопасность, но снижается удобство, это уже решать вам, для тестов, пароль не указываем нажимаем 2 раза enter

Настраиваем целевую машину
Настраиваем машину на которую будем выполнять вход по ключу, тут необходимо выполнить 3 действия:
1) Настроить SSH сервер
2) Создать директорию для ключей в домашней директории пользователя
3) Положить на машину открытый ключ

1 — Настраиваем SSH сервер
sudo nano /etc/ssh/sshd_config

В конфиге нас интересует строки, по умолчанию они закомментированы с них необходимо снять комментарии и перевести значения этих параметров в yes если это не сделано за вас:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys


В последней строке мы указываем системе где искать ключи пользователей, их можно класть где угодно, но искать их будет проще именно в домашней директории пользователя в директории .ssh
Нам необходимо применить настройки, перезапустив ssh сервер
sudo service ssh restart


2- Создаем директорию для ключей

в домашней директории пользователя создаем директорию .ssh
mkdir /home/user/.ssh

Директория должна принадлежать пользователю который будет выполнять вход в систему по ssh

3 — Добавляем на целевую машину открытый ключ
В созданной директории .ssh нам необходимо создать файл с отрытым ключом
nano /home/user/.ssh/authorized_keys

Нам необходимо записать в него содержимое файла из id_rsa.pub который у нас получился при генерации ключей на рабочей машине
Права доступа к файлу authorized_keys должны позволять читать содержимое пользователю user

Проверяем работу
На рабочей машине, если мы работаем под именем user, пытаемся подключиться к целевой машине, набрав команду в консоли:
ssh ip__целевой_машины

Должно произойти подключение
Если на рабочей системе вы работаете под пользователем имя которого на целевой машине отличается от имени пользователя на рабочей машине, например:
Вы работаете под пользователем superuser, но на целевой машине вы работаете под пользователем user, тогда команда подключения будет иметь вид:
ssh user@ip__целевой_машины

Ну а если на целевой машине ssh сервер работает не на стандартном порту 22, а для примера, 9999, то команда подключения принимает вид:
ssh user@ip__целевой_машины -p 9999


На этом все!
Возникли вопросы, прошу в комментарии, нашли ошибку, то пишите в чилку или на email, его можно найти в нижнем левом углу страницы.
  • 0
  • avatar     

10 комментариев

avatar
Не совсем понял про файлы
id_rsa
id_rsa.pub
Это файлы с закрытым и открытым ключами. Хорошо. Ключ там только один? То есть для разных ключей нужно создавать разные файлы? Или все ключи можно сохранять в один и тот же файл?
avatar
Да ключ один, в файле id_rsa.pub содержится сертификат, если вы хотите разрешить пользователю заходить в систему по нескольким ключам, например один ключ для входа с работы, второй для входа из дома, то содержимое файлов с расширением *.pub необходимо добавить в файл:
/home/user/.ssh/authorized_keys

скопировать точно также, начиная содержимое каждого файла с новой строки
avatar
Спасибо за статью, но всё же она неполная.
С одной стороны, Вы описываете простые вещи с простыми шагами, очевидно для новичков, но с другой стороны не описываете остальные шаги. А именно:
— каким образом задаём права на файл с открытым ключом (т.е. обезопасиваем его от доступа другим пользователям);
— каким образом копируем открытый ключ на сам сервер и затем в файл authorized_keys (кстати, он может быть любой, всё зависит от конфига ssh-сервера);
— не до конца раскрыт конфиг ssh-сервера (почему не убрали авторизацию по паролю? Ведь смысл ключа не только в удобстве).
Также не согласен с формулировкой «более длинный ключ вызывает большою нагрузку на процессор шифровака/дешифровка данных», там где рассказывает про генерацию ключа. Длина ключа по сути является эдакой длиной пароля и всё. Чем он длиннее, тем сложнее его взломать. К шифрованию самого ssh соединения и нагрузке на процессор не имеет никакого отношения.
avatar
Здравствуйте.
В ваших словах есть смысл, но чисто технически, нет возможности описать все варианты конфигураций служб.
На счет того чтобы обезопасить открытый ключ, от других пользователей, так на то он и открытый чтобы раздать его всем кто должен иметь возможность обмениваться с нами сообщениями, без закрытого ключа, он бесполезен.
Раскрывать весь конфиг не вижу смысла по одной простой причине, я описал одно простое действие, а вопросы конфигурирования сервиса, это каждый решает сам, тем более что есть документация, включая русскую, да и конфигурационный файл снабжен комментариями.
Авторизация по паролю не считается уязвимостью системы в целом, просто появляется дополнительный вектор атаки, если пароль стойкий, да еще и прикручен fail2ban, брутфорс становится мало результативным. На а касаемо доставки туда ключей, установка прав доступа, это уже каждый решает сам, можно закидывать руками, можно использовать системы управления конфигурациями, можно собрать свой дистрибутив, в котором уже все есть, все зависит от потребностей и наличия знаний.
avatar
Спасибо за ответ.
Всё же я поясню, что, в том числе, я имел ввиду по поводу защиты ключа соответствующими правами. Допустим кто-то, кто также имеет доступ до сервера по своему ключу, каким-либо образом случайно (по глупости или потому что его приватный ключ был скомпрометирован) или намеренно (ака злой умысел) удалит или изменит Ваш публичный ключ так, что Вы больше не сможете подключаться к серверу. Особенно это опасно и возможно, когда у Вас нет физического доступа до сервера, а также отключен доступ по логину/паролю. Примеров можно накидать ещё, просто это самый первый, который пришёл в голову.
Насчёт fail2ban согласен, это самое простое и известное решение защиты, но его недостаток в том, что работает на основе логов, в которых отражаются попытки доступа. Т.е. просто читает их, и исходя из появления нужных уведомлений в них и правил в конфиге самого fail2ban, выполняет соответствующие действия по бану/блокировке.
И хочу уточнить, я сейчас не спора ради, а просто объяснил причину своих вопросов.
avatar
Согласен с вами.
Статью поправлю!
avatar
че то не работает. Сервер на CentOS 7, тачка на Ubuntu 16.04.
Вроде все сделал по инструкции. Только в конфиге не было PubkeyAuthentication, вписал его вручную.
при подключении все равно просит пароль.
Может есть какая-то особенность при работе с CentOS?
avatar
проверьте права доступа к файлу /home/user/.ssh/authorized_keys должны быть 600 и владелец пользователь под которым будет выполнен выход.
в чтобы убедиться в этом можно посмотреть в лог в ubuntu /var/log/auth.log в centos /var/log/secure там должны быть записи про 'bad owership'
avatar
Вы правы. В логе на CentOS:
Dec 5 11:46:28 tst sshd[6661]: Authentication refused: bad ownership or modes for directory /home/leeroy/.ssh

Но я ничего не понимаю, т.к. права все выставлены:
[leeroy@tst ~]$ ls -la /home/leeroy/.ssh/
итого 4
drwxrwxr-x. 2 leeroy leeroy 29 ноя 29 13:33.
drwx------. 6 leeroy leeroy 227 дек 1 14:37…
-rw-------. 1 leeroy leeroy 227 ноя 29 13:01 authorized_keys

И сам файл я могу открыть без sudo. Что ему еще от меня нужно? :)
avatar
Проблема решена установкой прав для самой директории /home/leeroy/.ssh
К слову, параметр RSAAuthentication для новой версии openssh-server (7.4) является устаревшим. Закомментировал его, чтобы не сыпались уведомления в лог.
Есть что добавить? Регистрируйся и оставляй комментарии!