OpenSSH Public Key Authentication

Привет. Сегодня поговорим о OpenSSH, а в частности об аутентификации на SSH сервере с использованием ключей. Метод Identity/Pubkey довольно популярный, прост в настройке и считается более безопасным, чем метод аутентификации по паролю. Целью использования идентификации Identity/Pubkey является исключение использования статических паролей, а использование ключей (метод открытого ключа). Метод заключается в следующем. В место того, чтобы каждый раз набирать пароль (который может быть перехвачен или подсмотрен) мы используем пару ключей, хранящихся на диске, которые и используются для проверки подлинности. Ваша учетная запись на сервере имеет список Identities/Pubkeys, которому можно доверять и если Вы сможете доказать, что у вас есть и публичный и приватный ключ, то доступ будет предоставлен без запроса пароля. Метод эффективен только если авторизация по паролям отключена.

Authentication

Вот некоторые из положительных моментов этого типа аутентификации:

  • Никто не сможет войти на сервер с Вашей учетной записью, так как им необходимо обладать приватным ключом и кодовой фразой.
  • Администратор сервера может вообще убрать пароль учетной записи, дабы исключить его дискредитацию.
  • Вы можете использовать утилиту ssh-agent и он будет предоставлять аутентификационные данные за Вас.
  • Вы можете устанавливать определенные ограничения, например запрещая перенаправление портов, выполнение определенных программ и т.д.
  • Вы можете распространять публичный ключ, без угрозы для вашей учетной записи.

В этой статье мы подробно рассмотрим данный метод.
Реализация данного метода графически:

ssh-client-server

Все операции необходимо выполнять от имени вашего пользователя. Использование root привилегий крайне не приветствуется.
Первое, что нам необходимо сделать, это проверить что OpenSSH установлен у вас в системе.

$ ssh -V
$ ssh -V

Если да…то удалите его и все конфигурационные файлы. Сделать это можно следующим образом. Система -> Администрирование -> Менеджер пакетов Synaptic как показано на рисунке.

Снимок

Дабы убедиться в том, что все конфигурационные файлы были удалены, делаем так:

$ sudo rm -rf /etc/ssh/
$ sudo rm -rf /etc/ssh/
$ sudo rm -rf ~/.ssh/
$ sudo rm -rf ~/.ssh/

Теперь устанавливаем все пакеты заново.

$ sudo aptitude install ssh openssh-client openssh-server
$ sudo aptitude install ssh openssh-client openssh-server

Системa на которых проводились тестирования:

$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 9.10
Release:    9.10
Codename:   karmic
$ lsb_release -a
Distributor ID:	Ubuntu
Description:	Ubuntu 9.10
Release:	9.10
Codename:	karmic

Все эти операции необходимо проделать как на Сервере так и на Клиенте.
Чем вызваны такие непонятные на первый взгляд операции? Ответ прост, не сделав этого, в конце, когда вы попытаетесь присоединиться к вашему серверу, с использованием ключей вы получите ошибку вида:
Permission denied (publickey,password,hostbased).

Теперь приступим непосредственно к созданию ключей, правкам конфигов и т.д.
Генерирование ключей выполняем только на стороне Клиента

client$ mkdir ~/.ssh
client$ chmod 700 ~/.ssh
client$ ssh-keygen -q -f ~/.ssh/id_rsa -t rsa
Enter passphrase (empty for no passphrase): …
Enter same passphrase again: …
client$ mkdir ~/.ssh
client$ chmod 700 ~/.ssh
client$ ssh-keygen -q -f ~/.ssh/id_rsa -t rsa
Enter passphrase (empty for no passphrase): …
Enter same passphrase again: …

Не используйте пароль вашего аккаунта или пустой пароль, это может скомпрометировать безопасность. Пароль может быть до 16 символов. Далее необходимо выставить верные права для директории .ssh и ее содержимого:

client$ chmod 700 ~/.ssh
client$ chmod go-rwx ~/.ssh/* 
client$ chmod 700 ~/.ssh
client$ chmod go-rwx ~/.ssh/* 

Теперь вы обладатель двух ключей, которые находятся в папке .ssh:

client$ ls -la .ssh/
-rw-------  1 user user   1743 2009-10-31 15:38 id_rsa
-rw-------  1 user user    397 2009-10-31 15:38 id_rsa.pub
client$ ls -la .ssh/
-rw-------  1 user user   1743 2009-10-31 15:38 id_rsa
-rw-------  1 user user    397 2009-10-31 15:38 id_rsa.pub

id_rsa – приватный (секретный ключ)
id_rsa.pub – публичный ключ (можно выложить на ftp или samba)

Теперь необходимо скопировать ваш публичный ключ на сервер, перезаписать его в файл authorized_keys, и настроить конфиг сервера.
Копируем id_rsa.pub на сервер. (Для примера адрес сервера будет 192.168.1.1)

client$ scp ~/.ssh/id_rsa.pub user@192.168.1.1:
client$ scp ~/.ssh/id_rsa.pub [email protected]:

Уберите файл id_rsa.pub из папки .ssh на съемный носитель или в зашифрованную директорию. Данное действие обязательно.

Все дальнейшие действия проводятся на стороне Сервера.

server$ mkdir ~/.ssh
server$ chmod 700 ~/.ssh
server$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
server$ chmod 600 ~/.ssh/authorized_keys
server$ rm ~/id_rsa.pub
server$ mkdir ~/.ssh
server$ chmod 700 ~/.ssh
server$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
server$ chmod 600 ~/.ssh/authorized_keys
server$ rm ~/id_rsa.pub

Пожалуй это все. Проверьте записался ли файл authorized_keys командой:

cat authorized_keys
cat authorized_keys

Теперь необходимо настроить конфиг сервера.

server$ sudo nano /etc/ssh/sshd_config
server$ sudo nano /etc/ssh/sshd_config

Вот как должны выглядеть необходимые директивы в файле

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
 
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys
 
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no 
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no 

PermitRootLogin no – запретить авторизацию по руту
RSAAuthentication yes – разрешить RSA аутентификацию
PubkeyAuthentication yes – разрешить Pubkey аутентификацию
PermitEmptyPasswords no – запретить пустые пароли
PasswordAuthentication no – запретить аутентификацию по паролю

Выполняем подключение клиента к серверу

client$ ssh -o PreferredAuthentications=publickey user@192.168.1.1
Enter passphrase for key '/…/.ssh/id_rsa': …
…
server$ 
client$ ssh -o PreferredAuthentications=publickey [email protected]
Enter passphrase for key '/…/.ssh/id_rsa': …
…
server$ 

В дальнейшем выполняем подключение к серверу командой:

client$ ssh -v user@192.168.1.1
client$ ssh -v [email protected]

Помним, user – это учетная запись на сервере.

Если вы вдруг потеряли ваш публичный ключ, его можно восстановить следующим образом:

client$ ls -1 /etc/ssh/ssh_host_rsa_key*
client$ cat /etc/ssh/ssh_host_rsa_key.pub
client$ ssh-keygen -y -f  /etc/ssh/ssh_host_rsa_key
client$ ls -1 /etc/ssh/ssh_host_rsa_key*
client$ cat /etc/ssh/ssh_host_rsa_key.pub
client$ ssh-keygen -y -f  /etc/ssh/ssh_host_rsa_key

Если вы потеряли ваш приватный ключ, то можете забыть о всякой аутентификации и создавать все ключи заново.

Можно еще более упростить процесс авторизации создав файл

client$ nano .ssh/config
client$ nano .ssh/config

А в него добавить следующее:

Host 192.168.1.1
ServerAliveInterval 60
User YourUserName
Compression yes
ForwardX11 yes
IdentityFile ~/.ssh/id_rsa
Host 192.168.1.1
ServerAliveInterval 60
User YourUserName
Compression yes
ForwardX11 yes
IdentityFile ~/.ssh/id_rsa

Теперь что-бы попасть на сервер, достаточно ввести в командной строке.

ssh 192.168.1.102
ssh 192.168.1.102

Полезные ресурсы:
Трюки, секреты SSH
OpenSSH
OpenSSH в Wikipedia