OpenSSH авторизация по RSA ключам

openssh-logo Настройка SSH авторизации только через RSA ключи не особо сложный процесс, но имеет свои нюансы. Первый и самый главный - это безопасность SSH авторизации по RSA ключам.

Почему я не люблю SSH авторизацию по RSA ключам? SSH авторизация по RSA ключам удобна, но считаю её недостаточно безопасной из-за открытости приватного ключа, а особенно если на приватном ключе нет пароля - т.е. приватный ключ доступен почти для всех программ запущенных в ОС и его утечка из файловой системы более вероятна чем утечка пароля из мозга!

При всех антивирусах, сетевых мониторах на шлюзах и в самой ОС, системах превентивного обнаружения вторжений и прочих мерах безопасности сервера или рабочей станции, которые часом приобретают параноидальные признаки - поставить 100% на то, что на машине нет, или не появится в ближайшем будущем, какой-то стучащей хрени, невозможно.

В безопасности своей рабочей машины я уверен на 99.99%, пока всё идёт хорошо (обновление всего всегда ручное, автоматически на моём ПК только время синхронизируется, входящие/исходящие жестко зафильтрованы, браузеры все в песочнице, во временных каталогах запрещена экзекуция исполняемых и т.д.), но тем не менее из-за нехватки 1-го процента уверенности не могу себе позволить SSH авторизацию по RSA ключам.

Кто-то может возразить, мол "Да, но на приватный ключ можно поставить пароль!" - согласен, можно, но в таком случае пароль будет зашит в сам ключ, что при его краже, а также достаточных вычислительных ресурсах и хороших знаниях криптографии, даст возможность для его активного брутфорса без каких либо ограничений со стороны ОС - т.е. брутфорс ОС выполнить намного сложнее (блокировка доступа после 2-3 неверных попыток входа, и пр.), чем брутфорс ключа локально!

Также если будет утерян приватный (id_rsa), то мы смело может помахать серванту ручкой и пойти с горя синевы наклюкаццо (when SSH private keys are lost) если нет физического доступа к машине - публичный (id_rsa.pub) можно восстановить из приватного, а вот приватный из публичного вряд ли... Есть некая фича отзыва (RevokedKeys) ключей, но это не одно и тоже, что восстановление - отозванные (аннулированные) ключи не могут использоваться для дальнейшей аутентификации (Revoked keys cannot be used for user or host authentication and will trigger a warning if used.)!

Автор поста остался при своём мнении - SSH авторизация по RSA ключам менее безопасна, чем авторизация по паролю, например:

  1. при парольной авторизации, угроза снифинга интернет трафика, но тут мы можем использовать дополнительный SSL туннель - вероятная приватность 99%;
  2. при авторизации по ключам, угроза утечки приватного ключа разом с паролем от королевства - вероятная приватность 50/50%;

Только не говорите, что взлом SSL трафика или брутфорс приватного RSA ключа невозможен - немцы во вторую мировую тоже думали, что шифровальная машина Энигма вермахта непобедима!

Если кто всё же решился использовать механизм SSH аутентификации только на одних RSA ключах, с запретом парольного механизма, тогда выполняем пару несложных шагов, что описаны ниже, а также пишем завещание, одеваем памперсы и держим труселя покрепче!;)

Создание пары RSA ключей

Создание пары RSA ключей не займёт много времени - ssh-keygen-им RSA ключи:

-bash-4.2$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/shaman/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/shaman/.ssh/id_rsa.
Your public key has been saved in /home/shaman/.ssh/id_rsa.pub.
The key fingerprint is:
72:b9:9a:395:b2:774:8c:59:62:90:4f:a9:03:80 shaman@openbsd.localhost
The keys randomart image is:
+--[ RSA 2048]----+
| .               |
|E .              |
|   .   . .       |
|    . o o.       |
|     ..*S        |
|      +o*.o      |
|     . =.B .     |
|      o++ +      |
|     .+. .       |
+-----------------+
-bash-4.2$

Тут мы вошли в консоль как пользователь "shaman", домашний каталог "/home/shaman", в котором по умолчанию расположен каталог .ssh с RSA ключами (id_rsa и id_rsa.pub). В примере пароль на приватный ключ не ставили, но для применения на практике желательно поставить хоть какой-то пароль на id_rsa (секретный ключ).

Копируем содержимое публичного ключа в файл содержащий авторизированные ключи:

cat ~/id_rsa.pub >> ~/authorized_keys

Разумеется все описанные здесь манипуляции, создание RSA ключей и т.п., выполняются на удалённом сервере, на котором мы и собираемся проходить аутентификацию по ключам.

Ключи можно создать и на локальной машине, но потом публичный ключ нужно будет перенести на удалённую...

Конфигурация sshd_config

Под занавес не помешает заглянуть в /etc/ssh/sshd_config и проверить всё ли там готово для авторизации по ключам:

# The default requires explicit activation of protocol 1
Protocol 2
 
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
 
RSAAuthentication yes
PubkeyAuthentication yes
 
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile    %h/.ssh/authorized_keys

Если собрались отключить логин по паролю, тогда в /etc/ssh/sshd_config отключаем:

PasswordAuthentication no
PermitRootLogin no

PuTTY Unable to use key file

Для тех, кто в первый раз на лыжах PuTTY - ошибка "Unable to use key file "X:\id_rsa" (OpenSSH SSH-2 private key)" может возникать по нескольким причинам:

  • Неформат SSH версии в которой ковался id_rsa ключ и версии в которой он пытается использоваться, для SSH-1 и SSH-2 ключи куются в разных форматах;
  • Неформат id_rsa ключа для использования в PuTTY, для PuTTY нужно ключи конвертировать в .ppk формат

Если id_rsa генерировался стандартными утилитами из пакета OpenSSH (ssh-keygen -t rsa), то для его использования в SSH клиенте PuTTY он должен быть экспортирован в .ppk формат следующим образом (CMD вариант - puttygen id_rsa -o id_rsa.ppk):

  1. Запускаем puttygen и загружаем туда наш id_rsa приватный ключ, что был создан утилитами из пакета OpenSSH, и, если хотим, ставим на него пароль:
    convert-id_rsa-private-key-to-ppk-format_1
  2. Сохраняем приватный ключ в формате .ppk (Save private key):
    convert-id_rsa-private-key-to-ppk-format_2

Теперь после попытки авторизации по ключу нам достаточно будет ввести логин, а если ставили пароль на приватный ключ, то и пароль от приватного ключа соответственно:

login as: shaman
Authenticating with public key "imported-openssh-key"
Last login: Sat Jan  4 09:50:16 2014 from 192.168.231.1
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013
 
Welcome to OpenBSD: The proactively secure Unix-like operating system.
 
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
 
-bash-4.2$

-------------
 
login as: sham
Authenticating with public key "imported-openssh-key"
Passphrase for key "imported-openssh-key":
Last login: Sat Jan  4 09:50:16 2014 from 192.168.231.1
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013
 
Welcome to OpenBSD: The proactively secure Unix-like operating system.
 
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
 
-bash-4.2$

Восстановить публичный ключ от приватного

Для восстановления публичного ключа (Create a public SSH key from the private key) от уже имеющегося приватного выполним:

ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub

Авторизация по ключам в OpenSSH server for Windows

Windows не Linux, а Linux не Windows. В принципе авторизация по ключам в OpenSSH server for Windows работает аналогично Linux/BSD, но с некоторыми существенными отличиями.

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

При такой конфигурации OpenSSH server for Windows мы можем столкнутся с ошибкой SSH клиента "OpenSSH Server refused our key", а системный журнал получим сообщения:

Не найдено описание для события с кодом ( 0 ) в источнике ( sshd ). Возможно, на локальном компьютере нет нужных данных в реестре или файлов DLL сообщений для отображения сообщений удаленного компьютера. Попробуйте использовать ключ /AUXSOURCE= для получения этого описания, - дополнительные сведения об этом содержатся в справке. В записи события содержится следующая информация: sshd: PID 1712: error: Received disconnect from 192.168.231.1: 13: Unable to authenticate.
---
Не найдено описание для события с кодом ( 0 ) в источнике ( sshd ). Возможно, на локальном компьютере нет нужных данных в реестре или файлов DLL сообщений для отображения сообщений удаленного компьютера. Попробуйте использовать ключ /AUXSOURCE= для получения этого описания, - дополнительные сведения об этом содержатся в справке. В записи события содержится следующая информация: sshd: PID 1712: Authentication refused: bad ownership or modes for directory /home/user.

Вероятно, что ошибку SSH клиента "OpenSSH Server refused our key" будем получать неизбежно и постоянно если будем пытаться использовать персональный файл ".ssh/authorized_keys" для каждого пользователя!

Какие права на домашний каталог пользователя не пробовал ставить, всё равно в SSH клиенте получаю "OpenSSH Server refused our key", а в системном журнале "sshd: PID 1712: Authentication refused: bad ownership or modes for directory /home/user" - это вероятно связано разделением прав в cygwin окружении, т.е. не при каких условиях не даёт читать домашний каталог пользователя, пока тот не пройдёт авторизацию...

Единственным выходом в этом случае является использование общего, для всех пользователей, файла authorized_keys - "AuthorizedKeysFile /etc/ssh/authorized_keys".

Каждый пользователь может создавать свои собственные ключи, в своём домашнем каталоге:

C:\OpenSSHd\bin>ssh-keygen -t rsa -f /home/%username%/.ssh/id_rsa
Generating public/private rsa key pair.
Created directory '/home/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/root/.ssh/id_rsa.
Your public key has been saved in /home/root/.ssh/id_rsa.pub.
The key fingerprint is:
9e:f8:4f:55:1a:5a:83:a9:b9:4f:5f:5d:41:28:14:1b root@local-cab12c5d9
The key's randomart image is:
+--[ RSA 2048]----+
|           E.o...|
|            ..o. |
|             ... |
|              . .|
|        So   o  .|
|       oo.+ o. . |
|      .o++ o. .  |
|      oo....     |
|      .oooo      |
+-----------------+
 
C:\OpenSSHd\bin>

Но, для разрешения доступа по ключам только администратор должен добавить содержимое публичного ключа (id_rsa.pub) каждого пользователя в /etc/ssh/authorized_keys, ну, и разумеется не забываем добавить пользователя в /etc/passwd.

Ссылки по теме:

Автор: Олег Головский


Комментарии   

АдМинь БагоИскатель
0 #1 АдМинь БагоИскатель 11.01.2014 18:23
:lol:
Цитата:
обновление всего всегда ручное, автоматически на моём ПК только время синхронизируется...
А вот тебе: DВoS атака по NTP протоколу положила крупные игровые сайты:
http://www.remoteshaman.com/news/security/ddos-attack-on-ntp-protocol-laid-big-gaming-servers

8) Переводи и синхронизацию в ручной режим...
Цитировать

Добавить комментарий


Защитный код
Обновить

4 megabytes