SSH. Как это работает

22.06.2023

Теги: LinuxSSHUbuntuКлиентКлючСервер

Часть 1. Процесс соединения и шифрования

Симметричное шифрование

При симметричном шифровании используется один ключ для передачи данных между участниками обмена. Это означает, любой у кого он есть, может читать и посылать сообщения другим держателям ключа. Такая схема еще часто называется с «общим секретом» (shared secret) или «секретный ключ».

Симметричный ключ используются в SSH для шифрования всего соединения. Важно понимать, что речь не о паре ключей public/private, которые применяются для авторизации. Эта пара ключей не имеет отношения к соединению, как таковому. Симметричное шифрование защищает и сам процесс ввода логина/пароля от «подслушивания».

Клиент и сервер проходят некоторую процедуру, чтобы «договориться» о вышеозначенном секрете. Она называется «обмен ключами» и происходит с помощью конкретных приемов, в результате которых, обе стороны получают один и тот же ключ, манипулируя открытыми частями информации.

Симметричный ключ, полученный таким образом, используется только для текущей сессии (соединения). Именно с помощью него осуществляется передача данных между сервером и клиентом. Как только симметричный ключ «установлен», дальнейшее соединение шифруется, в том числе последующий процесс авторизации пользователя.

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

Значения по умолчанию для сервера и клиента можно посмотреть в документации

$ man sshd_config
...............
     Ciphers
             Specifies the ciphers allowed.  Multiple ciphers must be comma-separated. If the
             specified list begins with a ‘+’ character, then the specified ciphers will be
             appended to the default set instead of replacing them.  If the specified list begins
             with a ‘-’ character, then the specified ciphers (including wildcards) will be
             removed from the default set instead of replacingthem. If the specified list begins
             with a ‘^’ character, then the specified ciphers will be placed at the head of the
             default set.

             The supported ciphers are:
                   3des-cbc
                   aes128-cbc
                   aes192-cbc
                   aes256-cbc
                   aes128-ctr
                   aes192-ctr
                   aes256-ctr
                   aes128-gcm@openssh.com
                   aes256-gcm@openssh.com
                   chacha20-poly1305@openssh.com
             The default is:
                   chacha20-poly1305@openssh.com,
                   aes128-ctr,aes192-ctr,aes256-ctr,
                   aes128-gcm@openssh.com,aes256-gcm@openssh.com
$ man ssh_config
...............
     Ciphers
             Specifies the ciphers allowed.  Multiple ciphers must be comma-separated. If the
             specified list begins with a ‘+’ character, then the specified ciphers will be 
             appended to the default set instead of replacing them.  If the specified list
             begins with a ‘-’ character, then the specified ciphers (including wildcards)
             will be removed from the default set instead of replacingthem. If the specified
             list begins with a ‘^’ character, then the specified ciphers will be placed at
             the head of the default set.

             The supported ciphers are:
                   3des-cbc
                   aes128-cbc
                   aes192-cbc
                   aes256-cbc
                   aes128-ctr
                   aes192-ctr
                   aes256-ctr
                   aes128-gcm@openssh.com
                   aes256-gcm@openssh.com
                   chacha20-poly1305@openssh.com
             The default is:
                   chacha20-poly1305@openssh.com,
                   aes128-ctr,aes192-ctr,aes256-ctr,
                   aes128-gcm@openssh.com,aes256-gcm@openssh.com

Если значения в /etc/ssh/sshd_config изменялись, то посмотреть текущие значения можно с помощью команды.

$ sudo sshd -T | grep ciphers
ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

С клиентом сложнее, нет возможности посмотреть список алгоритмов в порядке использования. Но с помощью опции -v можно определить используемый алгиритм.

$ ssh -v server.com exit 2>&1 | grep "cipher:"
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

Ассиметричное шифрование

Ассиметричное шифрование отличается от симметричного тем, что для передачи данных в одном направлении, требуются два связанных друг с другом ключа. Один из них известен как приватный (private key), другой называется публичным (public key).

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

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

SSH использует ассиметричное шифрование в процессе обмена ключами для авторизации. Клиент создает пару ключей, затем копирует свой публичный ключ на сервер, в специальный файл ~/.ssh/authorized_keys. Сервер использует этот публичный ключ для зашифровывания специального проверочного сообщения. Если клиент сможет его расшифровать — это означает, что он владеет «ответным» приватным ключом.

Хеширование (hashing)

Это еще один вид криптографических манипуляций с данными, который используется в SSH. Функция хеширования — метод создания короткой «подписи» или некая сумма данных. Основное свойство хеша заключается в его необратимости. Из него невозможно получить те данные, над которыми была выполнена функция хеширования. А еще он уникален для каждого набора данных (файл, строка).

Благодаря данному свойству, хеши используются для верификации. Главное применение в SSH — это проверка подлинности сообщений при помощи хеширования. Для того чтобы убедиться, что полученное сообщение не было изменено в процессе передачи. На английском — hash-based message authentication code или сокрещенно HMAC.

Алгоритм HMAC выбирается точно так же, как и алгоритм симметричного шифрования, из списка, в процессе выбора симметричного шифрования. Первый поддерживаемый сервером используется для соединения. Каждое сообщение, после того как будет зашифровано, «подписывается» с помощью MAC. Сама подпись передается в открытом виде, в конце пакета с зашифрованными данными.

Значения по умолчанию опции MACs для сервера и клиента можно посмотреть в документации

$ man sshd_config
...............
     MACs    Specifies the available MAC (message authentication code) algorithms. The MAC algorithm
             is used for data integrity protection. Multiple algorithms must be comma-separated. If
             the specified list begins with a ‘+’ character, then the specified algorithms will be
             appended to the default set instead of replacing them. If the specified list begins with
             a ‘-’ character, then the  specified algorithms (including wildcards) will be removed
             from the default set instead of replacing them.  If the specified list begins with a ‘^’
             character, then the specified algorithms will be placed at the head of the default set.

             The algorithms that contain "-etm" calculate the MAC after encryption (encrypt-then-mac).
             These are considered safer and their use recommended.
             
             The supported MACs are:
                   hmac-md5
                   hmac-md5-96
                   hmac-sha1
                   hmac-sha1-96
                   hmac-sha2-256
                   hmac-sha2-512
                   umac-64@openssh.com
                   umac-128@openssh.com
                   hmac-md5-etm@openssh.com
                   hmac-md5-96-etm@openssh.com
                   hmac-sha1-etm@openssh.com
                   hmac-sha1-96-etm@openssh.com
                   hmac-sha2-256-etm@openssh.com
                   hmac-sha2-512-etm@openssh.com
                   umac-64-etm@openssh.com
                   umac-128-etm@openssh.com
             The default is:
                   umac-64-etm@openssh.com,umac-128-etm@openssh.com,
                   hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,
                   hmac-sha1-etm@openssh.com,
                   umac-64@openssh.com,umac-128@openssh.com,
                   hmac-sha2-256,hmac-sha2-512,hmac-sha1
$ man ssh_config
...............
     MACs    Specifies the MAC (message authentication code) algorithms in order of preference. The
             MAC algorithm is used for data integrity protection.  Multiple algorithms must be
             comma-separated. If the specified list begins with a ‘+’ character, then the specified
             algorithms will be appended to the default set instead of replacing them. If the
             specified list begins with a ‘-’ character, then the specified algorithms (including
             wildcards) will be removed from the default set instead of replacing them.  If the
             specified list begins with a ‘^’ character, then the specified algorithms will be
             placed at the head of the default set.

             The algorithms that contain "-etm" calculate the MAC after encryption (encrypt-then-mac).
             These are considered safer and their use recommended.

            The default is:
                   umac-64-etm@openssh.com,umac-128-etm@openssh.com,
                   hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,
                   hmac-sha1-etm@openssh.com,
                   umac-64@openssh.com,umac-128@openssh.com,
                   hmac-sha2-256,hmac-sha2-512,hmac-sha1

Если значения в /etc/ssh/sshd_config изменялись, то посмотреть текущие значения можно с помощью команды.

$ sudo sshd -T | grep macs
macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,
hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

Два этапа ssh-соединения

Соединение можно разделить на два этапа. На первом, клиент с сервером «договариваются» об алгоритмах шифрования. На втором — происходит авторизация и принимается решение, имеет ли пользователь доступ к серверу.

1. Согласование алгоритмов

После того, как TCP соединение установлено (handshake), сервер присылает ответ с версиями поддерживаемых им протоколов. Если клиент поддерживает один из них, соединение продвигается дальше. Сервер так же предоставляет свой публичный хост-ключ (см.ниже), который клиент может использовать для проверки.

Следующим шагом, обе стороны генерируют симметричный ключ, используя одну из модификаций алгоритма Диффи-Хеллмана (Diffie-Hellman). Алгоритм дают возможность каждой стороне комбинировать свои приватные ключи с публичными ключами другой стороны. В результате чего у каждой стороны получается один и тот же секрет для симметричного шифрования.

Симметричное шифрование, которое используется с этого момента на протяжении всего соединения, называется бинарным пакетным протоколом (binary packet protocol). Получившийся ключ — симметричный, то есть используется для шифрации и дешифрации. Его назначение — защитить все передаваемые данные между клиентом и сервером.

Модификация алгоритма Диффи-Хеллмана, которая будет использована, задается в файлах конфигурации клиента и сервера c помощью опции KexAlgorithms. Значения по умолчанию этой опции для сервера и клиента можно посмотреть в документации.

$ man sshd_config
...............
     KexAlgorithms
             Specifies the available KEX (Key Exchange) algorithms. Multiple algorithms must be
             comma-separated. Alternately if the specified list begins with a ‘+’ character, then
             the specified algorithms will be appended to the default set instead of replacing them.
             If the specified list begins with a ‘-’ character, then the specified algorithms
             (including wildcards) will be removed from the default set instead of replacing them. 
             If the specified list begins with a ‘^’ character, then the specified algorithms will
             be placed at the head of the default set.
             
             The supported algorithms are:
                   curve25519-sha256
                   curve25519-sha256@libssh.org
                   diffie-hellman-group1-sha1
                   diffie-hellman-group14-sha1
                   diffie-hellman-group14-sha256
                   diffie-hellman-group16-sha512
                   diffie-hellman-group18-sha512
                   diffie-hellman-group-exchange-sha1
                   diffie-hellman-group-exchange-sha256
                   ecdh-sha2-nistp256
                   ecdh-sha2-nistp384
                   ecdh-sha2-nistp521
                   sntrup761x25519-sha512@openssh.com
             The default is:
                   curve25519-sha256,curve25519-sha256@libssh.org,
                   ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
                   sntrup761x25519-sha512@openssh.com,
                   diffie-hellman-group-exchange-sha256,
                   diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,
                   diffie-hellman-group14-sha256
$ man ssh_config
...............
     KexAlgorithms
             Specifies the available KEX (Key Exchange) algorithms.  Multiple algorithms must be
             comma-separated. If the specified list begins with a ‘+’ character, then the specified
             algorithms will be appended to the default set instead of replacing them. If the
             specified list begins with a ‘-’ character, then the specified algorithms (including
             wildcards) will be removed from the default set instead of replacing them. If the
             specified list begins with a ‘^’ character, then the specified algorithms will be
             placed at the head of the default set.
             
             The default is:
                   curve25519-sha256,curve25519-sha256@libssh.org,
                   ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
                   sntrup761x25519-sha512@openssh.com,
                   diffie-hellman-group-exchange-sha256,
                   diffie-hellman-group16-sha512,
                   diffie-hellman-group18-sha512,
                   diffie-hellman-group14-sha256

Если значения в /etc/ssh/sshd_config изменялись, то посмотреть текущие значения можно с помощью команды.

$ sudo sshd -T | grep ^kexalgorithms
kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,
ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,diffie-hellman-group-exchange-sha256,
diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256

С клиентом сложнее, нет возможности посмотреть список алгоритмов в порядке использования. Но с помощью опции -v можно определить используемый алгиритм.

$ ssh -v server.com exit 2>&1 | grep 'kex: algorithm:'
debug1: kex: algorithm: curve25519-sha256

2. Авторизация пользователя

Следующий этап заключается в авторизации пользователя. Тут несколько различных способов, которые могут использоваться в данных целях. Зависит, какие из них поддерживает сервер.

Самый простой — с помощью пароля, когда сервер попросту предлагает пользователю набрать его на клавиатуре. Пароль передается через установленное к этому моменту защищенное соединение. То есть третьи лица не смогут «подсмотреть» пароль во время передачи (так называемая атака MITM — Man In The Middle).

Несмотря на то, что пароль будет передан в зашифрованном виде, данный способ не рекомендуется, поскольку сложность пароля имеет очевидные ограничения. Появляется возможность подбора пароля автоматизированным способом (Brute-force атака).

Рекомендуемая альтернатива — использовать авторизацию по ключам. Два связанных друг с другом ключа используются для разных целей. Публичный — для шифрования, приватный — для дешифрации. Ассиметричность ключей позволяет серверу зашифровать сообщение для клиента с помощью публичного ключа. Затем клиент может доказать, что он владеет ответным приватным ключом, правильно расшифровав сообщение.

Часть 2. Пара ключей для авторизации

Создание ключей для авторизации

Для создания ключей используется утилита ssh-keygen, опция -t задает тип ключа, опция -b — длину ключа.

$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/evgeniy/.ssh/id_ed25519): server-ed25519
Enter passphrase (empty for no passphrase): Enter
Enter same passphrase again: Enter
Your identification has been saved in server-ed25519
Your public key has been saved in server-ed25519.pub
The key fingerprint is:
SHA256:hEConqbIX4oBKyqPd8D4dIT6wQzn/V6mLvqmagZ/nGg evgeniy@ubuntu-client
The key's randomart image is:
+--[ED25519 256]--+
|   oo            |
|  .  . .         |
| . .  . .        |
|o o .  .         |
|oX.o    S        |
|==O o            |
|O* * +  o        |
|*=E X .+         |
|B*=X.++          |
+----[SHA256]-----+

Копируем публичный ключ на сервер

$ ssh-copy-id -i ~/.ssh/server-ed25519 username@server.com
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "server-ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
username@server.com's password: пароль

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh username@server.com"
and check to make sure that only the key(s) you wanted were added.

На сервере разрешаем аутентификацию по ключу

$ sudo nano /etc/ssh/sshd_config
# разрешаем аутентификацию по ключу
PubkeyAuthentication yes
# запрещаем аутентификацию по паролю
PasswordAuthentication no
$ sudo systemctl restart ssh.service

Создание хост-ключей сервера

Вообще, в этом нет острой необходимости, потому что хост-ключи создаются при установке ssh-сервера. Но их можно удалить и создать заново с помощью утилиты ssh-keygen.

$ sudo rm /etc/ssh/ssh_host_*
[sudo] password for evgeniy: пароль
$ sudo ssh-keygen -A
[sudo] password for evgeniy: пароль
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
$ sudo systemctl restart ssh.service
[sudo] password for evgeniy: пароль

Лучше не полагаться на автоматическое создание ключей, а создать ключи вручную — это позволит задать рекомендуемую длину ключа. И не создавать устаревший ключ DSA, который считается небезопасным.

$ ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N ""
$ ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N ""

После этого при подключении к серверу ssh-клиент выдаст предупреждение, что хост-ключ сервера не совпадает с записью в файле ~/.ssh/known_hosts.

$ ssh evgeniy@server.com
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:KSdFZcrLN1N/wf1nTXFZZSJ77KCA+BzXqqw8NUNargc.
Please contact your system administrator.
Add correct host key in /home/evgeniy/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/evgeniy/.ssh/known_hosts:14
Host key for [123.123.123.123] has changed and you have requested strict checking.
Host key verification failed.

Удалить недействительные записи можно с помощью утилиты ssh-keygen. Обратите внимание, что в файле могут быть записи как с указанием ip-адреса, так и записи с указанием доменного имени сервера.

$ ssh-keygen -R 123.123.123.123
Host 123.123.123.123 found: line 14
Host 123.123.123.123 found: line 15
Host 123.123.123.123 found: line 16
/home/evgeniy/.ssh/known_hosts updated.
Original contents retained as /home/evgeniy/.ssh/known_hosts.old
$ ssh-keygen -R server.com
Host server.com not found in /home/evgeniy/.ssh/known_hosts

Отпечаток хост-ключа сервера

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

$ ssh evgeniy@server.com
The authenticity of host 'server.com (123.123.123.123)' can't be established.
ED25519 key fingerprint is SHA256:kJO8Y9mRmYsL25Adz3IPlxAWeEjogBy6da+h8id3M1Q.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'server.com' (ED25519) to the list of known hosts.

После нашего ответа yes будет добавлена запись в файл ~/.ssh/known_hosts. При следующих подключениях ssh-клиент будет проверять отпечаток хост-ключа сервера с записью в файле ~/.ssh/known_hosts. Сама эта запись выглядит вот так (хотя возможны варианты).

server.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMjT9I1DvYyBVD0b2t2i/pfcedCaTq4dcMg7eEZCEY3W

Обычно в такой ситуации просто отвечают yes, не задумываясь над тем, что же это за отпечаток и с чем его надо сравнить — так что давайте разберемся. При установке OpenSSH сервера в директории с файлами конфигурации /etc/ssh создаются хост-ключи сервера.

$ ls -la
итого 556
drwxr-xr-x   4 root root   4096 мая 27 11:42 .
drwxr-xr-x 130 root root  12288 июн  4 10:12 ..
-rw-r--r--   1 root root 505426 ноя 23  2022 moduli
-rw-r--r--   1 root root   1650 ноя 23  2022 ssh_config
drwxr-xr-x   2 root root   4096 ноя 23  2022 ssh_config.d
-rw-r--r--   1 root root   3254 ноя 23  2022 sshd_config
drwxr-xr-x   2 root root   4096 ноя 23  2022 sshd_config.d
-rw-------   1 root root    513 мая 27 11:42 ssh_host_dsa_key
-rw-r--r--   1 root root    180 мая 27 11:42 ssh_host_dsa_key.pub
-rw-------   1 root root    513 мая 27 11:42 ssh_host_ecdsa_key
-rw-r--r--   1 root root    180 мая 27 11:42 ssh_host_ecdsa_key.pub
-rw-------   1 root root    411 мая 27 11:42 ssh_host_ed25519_key
-rw-r--r--   1 root root    100 мая 27 11:42 ssh_host_ed25519_key.pub
-rw-------   1 root root   2602 мая 27 11:42 ssh_host_rsa_ke
-rw-r--r--   1 root root    572 мая 27 11:42 ssh_host_rsa_key.pub
-rw-r--r--   1 root root    342 дек  7  2020 ssh_import_id

Получить отпечаток открытого хост-ключа сервера можно с помощью следующей команды на этом сервере

$ ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub
1024 SHA256:NRq5bMIIza3UkdamvGjcJ61WRzZ0Tnb0hBD4U66G3XU root@ubuntu-server (DSA)
$ ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
256 SHA256:QfAaJ3SlnSZzYgIEJwtGu71hf4+GI6I19FpBVjEm89M root@server.com (ECDSA)
$ ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:kJO8Y9mRmYsL25Adz3IPlxAWeEjogBy6da+h8id3M1Q root@server.com (ED25519)
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
3072 SHA256:Z7upYLZhcIcWlRh2wNFVcnYj7w4L9SypC7eaEBxJm94 root@server.com (RSA)

Опция -l говорит ssh-keygen получить отпечаток открытого ключа, а опция -f указывает путь к файлу этого ключа. И только после сверки отпечатка хост-ключа можно смело печатать yes.

Какие хост-ключи использовать

Это задается в файле конфигурации ssh-сервера /etc/ssh/sshd_config с помощью опции HostKey. Для примера, разрешаем использовать только хост-ключи ED25519 и RSA.

# HostKey /etc/ssh/ssh_host_dsa_key
# HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

Типы ключей — DSA, RSA, ECDSA, ED25519

Протокол SSH поддерживает несколько типов ключей — DSA, RSA, ECDSA, ED25519. Ключи DSA устарели, их не рекомендуется использовать. Ключи RSA устаревают, но все еще активно используются, рекомендуемый размер 4096. Алгоритм ECDSA относительно новый, рекомендуемый размер 521. Работает быстрее RSA, длина ключа меньше RSA при той же безопасности. Алгоритм ED25519 — самый новый, работает быстрее ECDSA, длина ключа меньше ECDSA при той же безопасности.

$ ssh-keygen -t ed25519
$ ssh-keygen -t ecdsa -b 521
$ ssh-keygen -t rsa -b 4096

Отпечатки хост-ключей GitHub и GitLab

Общедосупные серверы, например GitHub.com и GitLab.com, публикуют отпечатки публичных ключей RSA, ECDSA, ED25519. Страница GitHub.com с отпечатками публичных ключей здесь. Страница GitLab.com с отпечатками публичных ключей здесь. Кроме того, на этих страницах есть публичные хост-ключи — можно их взять оттуда и добавить в свой ~/.ssh/known_hosts.

Когда публичные ключи уже добавлены в файл ~/.ssh/known_hosts — можно их посмотреть с помщью утилиты ssh-keygen.

$ ssh-keygen -l -F github.com
Host github.com found: line 1
github.com ED25519 SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
Host github.com found: line 2
github.com RSA SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s
Host github.com found: line 3
github.com ECDSA SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM
$ ssh-keygen -l -F gitlab.com
Host gitlab.com found: line 4
gitlab.com ED25519 SHA256:eUXGGm1YGsMAS7vkcx6JOJdOGHPem5gQp4taiCfCLB8
Host gitlab.com found: line 5
gitlab.com RSA SHA256:ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ
Host gitlab.com found: line 6
gitlab.com ECDSA SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw

Утилита ssh-agent

При создании пары ключей утилитой ssh-keygen — есть возможность защитить приватный ключ паролем. Но тогда, при каждом использовании такого приватного ключа — нужно вводить этот пароль. Это неудобно, было бы намного проще ввести пароль один раз, сохранить где-нибудь, а затем все время пользоваться. Такую задачу позволяет решить специальная утилита ssh-agent.

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXA2ck3P/agent.13152; export SSH_AUTH_SOCK;
SSH_AGENT_PID=13153; export SSH_AGENT_PID;
echo Agent pid 13153;

Мы просто запустили ssh-agent — в ответ получили bash-код, который надо выполнить, чтобы агент начал выполнять свою работу. Давайте выполним этот код в текущей bash-оболочке с помощью eval.

$ eval $(ssh-agent)
Agent pid 13156

При запуске ssh-agent создает переменные окружения

$ env | grep SSH_A
SSH_AUTH_SOCK=/tmp/ssh-XXXXXX5I9i5M/agent.13155
SSH_AGENT_PID=13156

В переменой SSH_AUTH_SOCK хранится путь к файлу сокета, через который происходит общение к агентом.

Для удобства, чтобы не запускать ssh-agent вручную — можно добавить в файл ~/.bashrc строку запуска агента.

eval $(ssh-agent) > /dev/null

Следующий шаг — добавить в ssh-agent ключи, защищенные паролем — это можно сделать с помощью утилиты ssh-add.

$ ssh-add ~/.ssh/pswd-es25519
Enter passphrase for /home/evgeniy/.ssh/pswd-ed25519: пароль
Identity added /home/evgeniy/.ssh/pswd-ed25519

Теперь, по подключении к удаленному серверу с помощью ключа, защищенного паролем, вводить пароль этого ключа больше не нужно.

Остановить работу ssh-agent можно с помощью опции -k

$ ssh-agent -k
unset SSH_AUTH_SOCK;
unset SSH_AGENT_PID;
echo Agent pid 13156 killed;

Утилита ssh-add

Утилита ssh-add сохраняет ssh-ключи для дальнейшего их использования агентом аутентификации ssh-agent. Если запущен без аргументов, то будут добавлены ключи ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa и ~/.ssh/id_ed25519. Из командной строки может быть задано альтернативное имя файла ключа. Если какому-либо файлу ключа требуется пароль — он будет запрошен у пользователя.

Для того, чтобы утилита ssh-add могла работать, аутентификационный агент ssh-agent должен быть запущен и должен являться прародителем текущего процесса.

$ ssh-add
Enter passphrase for /home/evgeniy/.ssh/id_rsa: пароль-для-id_rsa
Identity added: /home/evgeniy/.ssh/id_rsa (evgeniy@ubuntu-client)
Enter passphrase for /home/evgeniy/.ssh/id_ed25519: пароль-для-id_ed25519
Identity added: /home/evgeniy/.ssh/id_ed25519 (evgeniy@ubuntu-client)

Посмотреть публичную часть всех добавленных ключей

$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDgehmtmnWgrfCTHb03KFvY6USBugpH8KoRoIyZKkjx/UNgs7ZlD/7ZUjbeBXpT/nfJxT3bZXVUJ
vZ7JrdY3xzlkoGEbVqyvRDtQB+elCCY1HaRC76CS/XuRZ+2xB7/yi1ribXSU8ckKHRsmP7ZhUDucKNds80ZV3sSIl1IRHCeWeY1L+VZ6kOXHfB5IL
WAuRQuJ1+dswToIo7e4n/No4ZvwSeX4FTzpsekG2ZNBKB1WyWU8ynw14TDVbdp/8Xn+px7QNVUTgW7jqlYxI3F8jwYJtNKiuAaePnz6p95Iq8OTMk
UnOxnB01UhZG1T3LDsezMV76Mso3hmc9QotUdjdVlC/aSsJKvs6Vf4sDPkhps1Lr1EDlHPRXwxFN+fjkxiPfb+WfneT8ylnpPUbSeBWn6/V3bgTLi
v35E62THDuGRFfPodIKmSqQtiWQ2OVCGRluDAwEJgd5Bhhlhu7OzAnk305J9s7gmph/k8JqA5PQ2BsFauFgqex9q2x5YzWOdgWB2Q6tBSnv7qsnRl
JDbzICJ3AGc2h/YBggaOtZ7ASa0EOsPwRqel7cuJj+FCHBE/LIV50ZVAednaac2u94wIKeaGQivLBbEtCHBgcS2R0g8AZBewJCFUfEBtcYPOHwZ6l
XB1JwOmyxHBR4dniYm2P6yYkmm7YU0T/V8voCDSp7ytw== evgeniy@ubuntu-client
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFBz9Blo4nuHS4x+i/d84W9zrSl7moxPb8sp1r7F1MT9 evgeniy@ubuntu-client

Фактически — это просмотр содержимого ~/.ssh/id_rsa.pub и ~/.ssh/id_ed25519.pub.

Посмотреть отпечатки всех добавленных ключей

$ ssh-add -l
4096 SHA256:f7M5W7aSnjRd/9yhe3nAWpHu5+bUlsbjasVW4bxIZGE evgeniy@ubuntu-client (RSA)
256 SHA256:ejMRctCeC4EW5Bebw2CyzyczMI9qQHr953el/Xp6ZLU evgeniy@ubuntu-client (ED25519)

Отпечаток открытого ключа — это последовательность байтов, используемая для идентификации более длинного открытого ключа. По умочанию для создания отпечатка используется алгоритм SHA256 — но можно еще использовать MD5.

$ awk '{print $2}' ~/.ssh/id_rsa.pub | base64 -d | sha256sum | awk '{print $1}' | xxd -r -p | base64
f7M5W7aSnjRd/9yhe3nAWpHu5+bUlsbjasVW4bxIZGE=
$ awk '{print $2}' ~/.ssh/id_ed25519.pub | base64 -d | sha256sum | awk '{print $1}' | xxd -r -p | base64
ejMRctCeC4EW5Bebw2CyzyczMI9qQHr953el/Xp6ZLU=

Удалить все ранее добавленные ключи

$ ssh-add -D
All identities removed.

Удалить один из добавленных ключей

$ ssh-add -d ~/.ssh/id_rsa.pub
Identity removed: /home/evgeniy/.ssh/id_rsa.pub RSA (evgeniy@ubuntu-client)

Поиск: Linux • SSH • Ubuntu • Клиент • Ключ • Сервер • ssh-keygen • ssh-agent

Каталог оборудования
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Производители
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Функциональные группы
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.