SSH: авторизация по ключам

Автор: | 15/06/2015
Нет комментариев
 

ssh_logoУпрощенная схема, аналог поста SSH – авторизация по ключам.

Сегодня наткнулся на неё – и понял что она запутанная.

  • сервер – машина, с которой будем подключаться;
  • клиент – машина, на которую будем подключаться.

Для того, что бы авторизовываться на клиенте – нам необходимо сначала изменить настройки демона sshd.
На клиенте редактируем файл /etc/ssh/sshd_config, и в нём раскомментируем строки:

...
RSAAuthentication yes
...
AuthorizedKeysFile      .ssh/authorized_keys

Перезапускаем службу:

# service sshd restart
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]

Переходим к серверу – машине, с которой будем подключаться к клиенту.

На сервере – генерируем RSA-ключ:

$ ssh-keygen -t rsa -f .ssh/setevoy_akira
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .ssh/setevoy_akira.
Your public key has been saved in .ssh/setevoy_akira.pub.
The key fingerprint is:
09:cc:28:05:2b:6f:86:b9:54:15:c8:1a:55:d1:21:8b [email protected]
The key's randomart image is:
+--[ RSA 2048]----+
|  +o+*+..        |
| . =o+o.         |
|. =E..+          |
| *..   . .       |
|o.+     S        |
|.+               |
|.                |
|                 |
|                 |
+-----------------+

Опция -f тут – указать на файл ключа. Если её не использовать – ssh-keygen предложит сохранить в файл с именем по умолчанию – .ssh/id_rsa.

Ключ состоит из двух частей – приватная часть (собственно – .ssh/setevoy_akira), и его публичная часть (.ssh/setevoy_akira.pub).

Для авторизации – на клиенте необходимо добавить публичную часть ключа в файл .ssh/authorized_keys в домашней директории пользователя, под которым будем подключаться.

Можно это сделать вручную – скопировав текст ключа:

$ cat .ssh/setevoy_akira.pub
ssh-rsa AAAAB3NzaC1y***dSuYCdtaWQ== [email protected]

И вписав его в файл .ssh/authorized_keys на клиенте.

Можно воспользоваться утилитой ssh-copy-id:

$ ssh-copy-id -i .ssh/setevoy_akira.pub "setevoy@77.***.***.40 -p 2222"
setevoy@77.***.***.40's password:
Now try logging into the machine, with "ssh 'setevoy@77.***.***.40 -p 2222'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Где setevoy – пользователь, под которым будет выполняться подключение к клиенту,  77.***.***.40 – IP клиента, а 2222 – порт SSH.

Теперь – ключ есть на клиенте:

$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1y***dSuYCdtaWQ== [email protected]

ВАЖНО: на клиенте права на каталог ~/.ssh должны быть 700, а на файл .ssh/authorized_keys – 600:

$ chmod 700 .ssh/
$ chmod 600 .ssh/authorized_keys

И можно авторизоваться:

$ ssh -p 2222 setevoy@77.***.***.40 -i .ssh/setevoy_akira
Last login: Sat Jun 13 22:30:47 2015 from mail.domain.org.ua

Если ключ генерировался без опции -f и хранится в файле id_rsa – то при подключении опцию -i .ssh/setevoy_akira можно не использовать – sshd сам найдёт ключ по умолчанию – id_rsa.

Опция -p – использовать нестандартный порт SSH (после смены порта с 22 на 2222 – кол-во ботов, ломящихся на сервер, уменьшилось до нескольких единиц в неделю, а до этого – было по 10-20 в сутки). Ну и не забываем про Fail2Ban.

При проблемах с авторизацией по ключу (например – просит пароль) – во-первых проверьте права на каталог и файл на клиенте (см. выше).

Если с правами всё ОК (хотя в 99% случаев проблема именно в них) – запустите на клиенте демон sshd в дебаг-режиме на другом порту, и запишите данные в файл:

# /usr/sbin/sshd -p 2221 -D -d -e &>sshlog.txt

После чего попробуйте авторизоваться с сервера:

$ ssh -p 2221 setevoy@77.***.***.40 -i .ssh/setevoy_akira
Last login: Sat Jun 13 22:40:51 2015 from mail.domain.org.ua
Environment:
  LANG=en_US.UTF-8
  USER=setevoy
  LOGNAME=setevoy
  HOME=/home/setevoy
  PATH=/usr/local/bin:/bin:/usr/bin
  MAIL=/var/mail/setevoy
  SHELL=/bin/bash
  SSH_CLIENT=77.***.***.20 56250 2221
  SSH_CONNECTION=77.***.***.20 56250 77.***.***.40 2221
  SSH_TTY=/dev/pts/5
  TERM=screen

Тут ошибок нет, но в случае проблем – на клиенте sshd покажет подробные данные о подключении:

# tail -n 10 sshlog.txt
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Setting controlling tty using TIOCSCTTY.
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials
debug1: session_pty_cleanup: session 0 release /dev/pts/5