SSH. Как это работает
Часть 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)
- Установка WireGuard на Ubuntu 20.04 LTS. Часть вторая из двух
- Установка WireGuard на Ubuntu 20.04 LTS. Часть первая из двух
- Удаленный рабочий стол в Ubuntu Desktop 18.04 LTS
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 12 из 12
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 11 из 12
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 10 из 12
- Установка OpenVPN на Ubuntu 18.04 LTS. Часть 9 из 12
Поиск: Linux • SSH • Ubuntu • Клиент • Ключ • Сервер • ssh-keygen • ssh-agent