Ssh fingerprint что это

Что такое протокол SSH

Иными словами, SSH — это дистанционная командная строка. Визуально вы работаете на своем компьютере, но в реальности — на другом.

Что значит «протокол»?
Что значит «защищенный протокол»?
Для чего нужен SSH?
Как подключаться по SSH?
Подключение по SSH по паролю
Подключение по SSH по ключу, без пароля
ssh-agent
Форвардинг (проброс) ключей
Частые вопросы
Дополнительные ссылки

Что значит «протокол»?

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

Пример: вы вводите команду удаления файла. Эта команда передается на другой компьютер и выполняется там. Ответ (или сообщение об ошибке) возвращается и показывается на вашем компьютере.

Что значит «защищенный протокол»?

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

Для чего нужен SSH?

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

Как подключаться по SSH?

Для подключения к удаленной машине по SSH нужен клиент — специальная программа. В *nix-подобных системах (Linux, macOS) клиент обычно установлен в системе по умолчанию, поэтому достаточно просто открыть терминал.

Для подключения нужно указать адрес сервера и, опционально, имя пользователя и порт. Вот как выглядит команда при использовании консольного клиента (в терминале):

ssh username@remote_host -p port

Например, для подключения к серверу 52.307.149.244 в аккаунт ivan нужно ввести:

ssh ivan@52.307.149.244

Если не указывать порт, то будет использован порт SSH по умолчанию — 22 . Используемый порт задается при настройке SSH-сервера — программы, которая запущена на удаленном компьютере и ожидает подключения извне.

Fingerprint

При первом подключении появится сообщение:

The authenticity of host '52.307.149.244 (52.307.149.244)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

Введите yes в первый раз.

Это нужно для повышения безопасности. При настройке SSH-сервера создается уникальная комбинация символов — fingerprint («отпечатки пальцев»). Ваш компьютер запоминает эту комбинацию и сверяет ее при каждом новом соединении. Представьте, что кто-то внёс изменения в систему, например:

Переустановил SSH-сервер
Переустановил всю операционную систему
Заменил удаленный компьютер, сохранив его адрес

Даже в этом случае вы заметите изменения, потому что fingerprint тоже изменится.

Если fingerprint не меняется, то такое сообщение не будет появляться.

Подключение по SSH по паролю

Простейший вариант — подключение по паролю. После ввода команды ssh система запросит пароль:

ivan@52.307.149.244's password:

Пароль придется вводить каждый раз.

Подключение по SSH по ключу, без пароля

Для удобного подключения по SSH (и многим другим сервисам) без ввода пароля можно использовать ключи.

Нужно создать пару ключей: приватный (закрытый) ключ и публичный (открытый) ключ. Приватный ключ нужно хранить и никогда никому не показывать. Публичный ключ можно показывать всем и распространять свободно.

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

Генерация ключей

Создадим пару ключей:

ssh-keygen

Программа запустится и спросит, куда сохранять ключи:

Generating public/private rsa key pair. Enter file in which to save the key (/home/demo/.ssh/id_rsa):

Нажмите Enter для сохранения в стандартное место — директорию .ssh/id_rsa в вашей домашней директории.

Программа запросит passphrase. Это вроде пароля для ключа. Можно просто нажать Enter и пропустить этот шаг. Или ввести passphrase — тогда его нужно будет вводить каждый раз, когда используется ключ.

Enter passphrase (empty for no passphrase): Enter same passphrase again:

Your identification has been saved in /home/demo/.ssh/id_rsa. Your public key has been saved in /home/demo/.ssh/id_rsa.pub. The key fingerprint is: 8c:e9:7c:fa:bf:c4:e5:9c:c9:b8:60:1f:fe:1c:d3:8a root@here The key's randomart image is: +--[ RSA 2048]----+ | | | | | | | + | | o S . | | o . * + | | o + = O . | | + = = + | | . Eo+ | +-----------------+

Теперь у вас есть два файла:

~/.ssh/id_rsa — приватный ключ. Никогда никому и никуда не передавайте его!
~/.ssh/id_rsa.pub — публичный ключ. Спокойно распространяйте его.

В Windows можно использовать ssh-gen в подсистеме Ubuntu for Windows или в командной строке Git for Windows.

Загрузка публичного ключа на сервер

Нужно добавить публичный ключ на сервер в файл ~/.ssh/authorized_keys. Самый простой способ — запустить на локальной машине команду для копирования ключа:

ssh-copy-id -i /home/demo/.ssh/id_rsa.pub ivan@52.307.149.244

Другой способ — подключиться по паролю, открыть в редакторе файл ~/.ssh/authorized_keys и добавить в конец текст из вашего файла ~/.ssh/id_rsa.pub.

Теперь при подключении пароль запрашиваться не будет 1 .

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

ssh-agent

При работе с ключами возможны две неудобные ситуации:

Если при создании ключа вы указали passphrase (пароль для ключа), то вам придется вводить пароль при каждом подключении
Если у вас есть несколько ключей для разных целей, то при соединении по ssh придется указывать нужный ключ вручную

ssh-agent решает эти проблемы. Этот агент аутентификации (authentication agent) работает на фоне в *nix-системах. В некоторых других системах приходится устанавливать и настраивать его автозапуск самостоятельно.

Если добавить ключ к агенту, то:

для него больше не будет спрашиваться passphrase
не нужно будет вводить ключ вручную — он будет автоматически использован при соответствующем подключении

ssh-add /home/demo/.ssh/id_rsa добавит ключ id_rsa в запущенный в системе агент. Если у него есть passphrase, то агент попросит ввести его.

Если запустить ssh-add без аргументов, то будут добавлены ключи ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 и ~/.ssh/identity.

Список добавленных в агент ключей можно посмотреть командой ssh-add -L :

→ ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC91r/+5WEQHcxVMrxpP9jKuONjlrnEHshfG3v/ab2NKDSljdskODOIsdhaaoDoiSADhAaoDISHasoiDiASisjadOHISDdKJDASHSidshIHDSIHDIAsdjasAs7XG/drBhi16zQ2e8VcLD7bVQS1Cpo0O1tP+93YQBvcIE02RltqVKYo7BlgCaJzpdowK8fHSzpfCYsEFjdjosOjfdsjdjkAJOKkKKHJHhaIiAiaihsiIoqkpqdmlnvnuuUSCaAS8aDhajiadiiAahhakKAKDHAKurmD08jnX9HfH/d15pLK/Glo1Su6iEOU3bW8k92QlY54pPFLKiNRPFuUryE5md7T /Users/demo/.ssh/some_key.pem ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsLC9WpSZ/9YpQ2z1FTSsORcP+ohzCdVjYaoc3C0fRnUbkp4SnvMHFTHNFFod0FhV0cQcOLvBsZAK/0tUPIXeDDFvYD70r5i0AsQbqA0k7gK3b3MP7tmnPxMHd607TI+1FMO54Yig0vnpZOgKmgCsxWq6tckwyLB91BlPiGxLBZiu5yPDIguEQCSnAwkF0vjqrNGsoHB4+fkj0USfjiifsjihf39hifSIHiJFHSijshfj39jfsjisfiisfiissr893IFsifijfsjSOIiAShadfhssU0q0JpjaDEWcMmYXmuz3xSnbhkueGLBXMU2zXDFDWCDSHq9/oRr29UAfVaHAMw == /Users/demo/.ssh/id_rsa

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

Форвардинг (проброс) ключей

Представим, что вы подключились к удаленному серверу X. Дальше вы хотите подключиться с него к другому серверу Y — например, чтобы сделать git pull с GitHub. В этом случае придется держать копию ваших ключей на сервере X.

Утилита ssh с флагом -A позволяет «пробросить» ключи с подключаемой машины в удаленную:

ssh -A ivan@52.307.149.244

Ключи, добавленные к агенту аутентификации (ssh-agent), станут доступными на удаленном сервере. При этом файлы-ключи физически не будут находиться на сервере.

Частые вопросы

Чем Telnet отличается от SSH?

Telnet это конкретная программа с графическим интерфейсом, с помощью которой можно соединяться по SSH. Обычно ей пользуются только Windows пользователи, в Linux и MacOS используют консольную утилиту ssh.

Дополнительные ссылки

Основы SSH / Видео на канале Хекслета
SSH Essentials: Working with SSH Servers, Clients, and Keys
Памятка пользователям ssh

Возможность и специфика подключения по ключу зависит от настроек SSH-сервера. Возможно такое, что подключение по ключу запрещено администратором.

Отпечатки ключей SSH на GitHub

Отпечатки открытых ключей можно использовать для проверки подключения к удаленному серверу.

Отпечатки открытого ключа GitHub:

SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s (RSA)
SHA256:br9IjFspm1vxR3iA35FWE+4VTyz1hYVLIE2t1/CeyWQ (DSA — не рекомендуется)
SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM (ECDSA)
SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU (Ed25519)

В файл можно добавить следующие записи ~/.ssh/known_hosts ключа SSH, чтобы избежать ручной проверки узлов GitHub :

github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl github.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg= github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=

Дополнительные сведения см. в разделе «AUTOTITLE».

Отпечатки SSH-ключей (key fingerprints)

Публичный отпечаток ключа (key fingerprint) может быть использован для проверки соединения с удалённым сервером.

Ниже представлены примеры публичных отпечатков ключей (в шестнадцатеричном формате):

16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48 (RSA)
ad:1c:08:a4:40:e3:6f:9c:f5:66:26:5d:4b:33:5d:8c (DSA)

Здксь показаны SHA256-хэши в OpenSSH 6.8 и выше (в формате base64):

SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 (RSA)
SHA256:br9IjFspm1vxR3iA35FWE+4VTyz1hYVLIE2t1/CeyWQ (DSA)

Защита с помощью SSH ключей

Это первая из серии статей, рассказывающих об особенностях использования SSH. Мы начнем с рассмотрения стандартных SSH ключей, изучив процесс верификации, чтобы гарантировать, что вы не стали объектом атаки. Обратите внимание, что эта статья применима к широко используемому приложению OpenSSH, которое присутствует в большинстве Unix-подобных операционных систем, а не к коммерческой версии SSH.

Брайен Хатч, перевод Владимир Куксенок Это первая из серии статей, рассказывающих об особенностях использования SSH. Мы начнем с рассмотрения стандартных SSH ключей, изучив процесс верификации, чтобы гарантировать, что вы не стали объектом атаки. Обратите внимание, что эта статья применима к широко используемому приложению OpenSSH, которое присутствует в большинстве Unix-подобных операционных систем, а не к коммерческой версии SSH.

SSH ключи как защита от атак «человек посередине»

Клиент (веб браузер) соединяется с сервером (HTTPS веб сервер на 443 порту)
Сервер предоставляет свой открытый ключ (Сертификат X509)
Сервер предоставляет некое математическое число, доказывающее, что у сервера есть доступ к закрытому ключу, связанному с открытым ключом.
Браузер проверяет, подписан ли открытый ключ доверенным Certificate Authority (такими как Verisign, Thawte или другими).
Браузер проверяет, соответствует ли значение CN (X509 Common Name) сертификата сервера имени хоста, которое вы использовали для соединения с сервером. Т.е. если соединились с https://www.example.com, значение CN сертификата должно быть www.example.com.

SSH ключи в действии

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

$ ssh ssh-server.example.com The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established. RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d. Are you sure you want to continue connecting (yes/no)?

Ответим «да», и подключение продолжится:

$ ssh ssh-server.example.com Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'ssh-server.example.com,12.18.429.21' (RSA) to the list of known hosts. Password: (введите пароль) ssh-server.example.com $

На начальном этапе установления связи сервер предоставил клиенту свой ключ. Магическое математическое число доказывающее, что сервер имеет доступ к этому ключу, не упоминалось выше, что показывает отсутствие связанных с ним ошибок. Так как мы подключаемся к этой машине впервые, и SSH не работает по принципу третьего доверенного лица, такого как Certificate Authorities в мире SSL/TLS, вся работа, связанная с управлением ключами, лежит на вас. Ваш клиент показывает отпечаток ключа (key fingerprint), простую для чтения строку чисел, которую вы можете использовать для проверки ключа вручную, что мы и сделаем позже. Если вы отвечаете «Да, отпечаток правильный», ваш SSH клиент продолжит аутентификацию, дав вам возможность ввести ваш пароль и приступить к работе. Когда вы выше ответили «да», ваш SSH клиент сохранил ключ сервера в файле $HOME/.ssh/known_hosts . Это файл фактически является вашим личным Certificate Authority — списком ключей всех SSH серверов, с которыми вы работаете. Давайте посмотрим на последнею строку этого файла, которая была только что добавлена вами:

$ tail -1 $HOME/.ssh/known_hosts ssh-server.example.com,12.18.429.21 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA0 6jFqviLMMJ/GaJNhGx/P6Z7+4aJIfUqcVjTGQasS1daDYejcfOAWK0juoD+zS3BsGKKYKPA 5Gc5M8v+3NHLbPn1yTpDBgl6UzA0iiMPCbwnOLx61MrBTk+/qJI9kyDaJf4LEY6Chx4IJP0 ZN5NmAlCtXQsca3jwFAF72mqPbF8=

Одно или несколько имен серверов или IP адресов, разделенных запятыми.
Тип ключа (описан ниже).
Непосредственно открытый ключ (закодированный в пределах диапазона символов ASCII).
Любые дополнительные комментарии (не показаны в выводе выше)

$ ssh ssh-server.example.com Password: (введите пароль)

Глобальный файл, обычно /etc/ssh/ssh_known_hosts . Этот путь может быть изменен редактированием параметра GlobalKnownHostsFile в конфигурационном файле ssh (обычно это /etc/ssh/ssh_config ).
Файл пользователя, обычно $HOME/.ssh/known_hosts . Этот путь может быть изменен редактированием параметра UserKnownHostsFile в конфигурационном файле ssh.

Подтверждение подлинности ключа

Я показал, как происходит первое соединение и принятие открытого ключа. Но как вы узнаете, что получили правильный ключ? Если во время соединения с сервером атакующий перехватил ваше SSH соединение и пропустил через себя весь трафик, он может подсунуть вам свой ключ, вместо реального открытого ключа хоста. Здесь мы сталкиваемся с классической проблемой курицы и яйца. Лучший способ проверки подлинности ключа состоит в использовании нескольких различных методов. Например, владелец системы может разместить отпечаток ключа на своей защищенной SSL веб странице. В одном месте, где я работал, ключ главного сервера был напечатан на наших телефонных карточках, так, чтобы мы могли проверить его, всего лишь заглянув в бумажник, при посещении Интернет-кафе. Если вышеописанный способ вам не доступен, проверить ключ системы, в которую вы вошли, можно следующим образом. Открытый ключ обычно доступен в директории /etc/ssh/, так что после входа в систему вы можете проверить отпечаток ключа (используя ssh-keygen), который вы приняли во время входа в систему. (ssh-keygen также используется для создания SSH ключей и Identities/PubKeys, которые мы обсудим позже.) Вернемся к первому соединению, которое мы создали, и посмотрим, как мы можем проверить отпечаток ключа:

$ ssh ssh-server.example.com The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established. RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'ssh-server.example.com,12.18.429.21' (RSA) to the list of known hosts. Password: (enter password) ssh-server.example.com $ cd /etc/ssh ssh-server.example.com $ ls *.pub ssh_host_dsa_key.pub ssh_host_rsa_key.pub ssh_host_key.pub ssh-server.example.com $ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub 1024 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d ssh_host_rsa_key.pub

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

Проверка ключа

SSH имеет три способа реагирования на неопознанный или измененный ключ, основанных на значении переменной StrictHostKeyChecking: StrictHostKeyChecking=no Это самое небезопасное значение, разрешающее соединение с сервером вслепую. Если ключ сервера не присутствуют на локальном компьютере или ключ был изменен, он добавляется автоматически без каких-либо вопросов, всего лишь выдав предупреждение [сноска 5].
Ставить этот режим не очень хорошая идея.

StrictHostKeyChecking=ask Это параметр по умолчанию. Если у вас нет ключа сервера, вам будет показан отпечаток и запрошено подтверждение, как показано в примере выше. Если вы соединитесь, и ключи не совпадут, ваш вход в систему будет приостановлен и вам будет выдана информация, где в known_hosts находится конфликтующий ключ:

$ ssh -o stricthostkeychecking=ask ssh-server.example.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 the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 23:00:20:83:de:02:95:f1:e3:34:be:57:3f:cf:2c:e7. Please contact your system administrator. Add correct host key in /home/xahria/.ssh/known_hosts to get rid of this message. Offending key in /home/xahria/.ssh/known_hosts:8 RSA host key for localhost has changed and you have requested strict checking. Host key verification failed.

StrictHostKeyChecking=yes Эта самая безопасная, возможно даже недружелюбная установка. Если у вас нет ключа сервера, вы вообще не сможете войти в систему:

$ ssh -o 'StrictHostKeyChecking=yes' ssh-server.example.com No RSA host key is known for localhost and you have requested strict checking. Host key verification failed.

Если у вас есть ключ, но он не совпадает с ключом сервера, вы получите ошибку, такую же, как и при StrictHostKeyChecking=ask.

Почему ключ может измениться?

Было обновлено либо клиентское, либо серверное ПО, которое использует SSHV2, вместо прежнего SSHV1 [сноска 6].
Машина была переустановлена с тем же самым именем хоста, но исходные ключи не были восстановлены. После того как они будут созданы снова, они, конечно, не будут соответствовать вашему файлу known_hosts.
У компьютера, с которым вы хотите соединиться, было изменено DNS имя или IP адрес, или этот компьютер был заменен на новый.

Типы ключей

SSH поддерживает два основных протокола — SSHv2 и SSHv1 [сноска 7]. Старый протокол SSHv1 основан на алгоритме асимметричного шифрования RSA, тогда как более новый протокол SSHv2 поддерживает RSA и алгоритм aсимметричного шифрования DSA. SSH сервер может использовать один из трех типов ключей: SSHv1 RSA ключи, SSHv2 RSA ключи, или SSHv2 DSA ключи. Я буду называть их rsa1, rsa и dsa ключи соответственно, поскольку эта терминология используется в утилитах OpenSSH. SSH ключ создается с помощью команды ssh-keygen [сноска 8]. Вероятнее всего, когда SSH был установлен на вашу машину, программа инсталляции или стартовый скрипт создали их для вас. В файле sshd_config, обычно находящемся в директории /etc/ssh, перечислены ключи, загружающиеся во время старта системы.

# Which protocol(s) should we support? Protocol 2,1 # 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

Если вы собирали SSH из исходников, вы можете создать эти три ключа с помощью ssh-keygen:

# ssh-keygen -t rsa /etc/ssh/ssh_host_rsa_key # ssh-keygen -t dsa /etc/ssh/ssh_host_dsa_key # ssh-keygen -t rsa1 /etc/ssh/ssh_host_key

Программа ssh-keygen создает по два файла для каждого ключа. Первый содержит и закрытый и открытый ключ, а второй только открытый ключ. Таким образом, впервые запустив ssh-keygen, вы создадите файлы /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub . Нет никаких причин скрывать открытый ключ, но закрытый ключ должен быть надежно скрыт, так как он не защищен никаким паролем (passphrase) [сноска 9]. К счастью, ssh-keygen устанавливает параноидальные разрешения на доступ к файлу. Если вы сомневаетесь, что первый файл, не оканчивающийся на .pub, содержит закрытый ключ, или по каким-то причинам вы потеряли открытий ключ, вы всегда можете восстановить его с помощью той же самой команды ssh-keygen:

$ ls -1 /etc/ssh/ssh_host_rsa_key* /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub $ cat /etc/ssh/ssh_host_rsa_key.pub ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEApCyGZbDdzrRdszzQUZI+siu3 /mUI57nmjzKwHS7M27AoMZNJ6yIDTn5J3/MVCDJAeyB53LvIFFD9Kzp6P9 fhNhPm8+b0joJ5Wrn+YfUnt2moI3lkAzQUZI+siu3/mUI57nmjzKwH $ ssh-keygen -y -f /etc/ssh/ssh_host_rsa_key ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEApCyGZbDdzrRdszzQUZI+siu3 /mUI57nmjzKwHS7M27AoMZNJ6yIDTn5J3/MVCDJAeyB53LvIFFD9Kzp6P9 fhNhPm8+b0joJ5Wrn+YfUnt2moI3lkAzQUZI+siu3/mUI57nmjzKwH

Есть ли какие-либо причины использования одного типа ключа, а не другого? Нет. Ключ rsa обычно бывает несколько быстрее с математической точки зрения, но для больших возможностей взаимодействия лучше включать оба. Оба алгоритма не запатентованы [сноска 10], поэтому насчет этого вы можете не беспокоиться. Если вам нужна поддержка SSHv1, у вас должен быть ключ rsa1.

Советы

Есть множество приемов, позволяющих сделать управление ключами более простым и безопасным для вас и/или ваших пользователей. Используйте глобальный файл известных хостов ( /etc/ssh/ssh_known_hosts ), содержащий все машины, с которыми соединяются ваши пользователи. Если вы выделите время для проверки этих ключей, вам не нужно будет полагаться на пользователей. Удостоверьтесь, что вы получаете все три типа ключа, rsa, dsa, и rsa1. Также, когда вам нужно будет изменить ключ (например, машина была переустановлена, и вы забыли сохранить старые ключи), у вас будет только один файл, который нужно обновить. Используйте для хостов псевдонимы (aliases), которыми могут попытаться воспользоваться ваши пользователи. Например, вы должны включить и mail и mail.my_co.com , если к этому хосту можно получить доступ, используя оба этих имени. Если у вас несколько компьютеров, доступ к которым можно получить, используя одно и то же имя хоста, например пара веб серверов, включите оба ключа для общего имени. SSH клиент будет проверять все совпадения, пока не найдет нужное, так что вы можете использовать общее DNS имя, без использования общего ключа. Вот очень простой скрипт, соединяющийся с SSH сервером и добавляющий все три возможных ключа в файл. Он может быть полезен для создания вашего глобального файла ssh_known_hosts. Обратите внимание, что здесь не происходит верификации ключа, это вам придется сделать самим.

#!/bin/sh # # add-known-hosts # Add all possible SSH keys for the specified hosts to the file # specified. It's your responsibility to be sure that the keys # found are, in fact, valid. # # Copyright 2003, Brian Hatch # Released under the GPL KNOWN_HOSTS=./ssh_known_hosts SSH_ARGS="-o StrictHostKeyChecking=no -o UserKnownHostsFile=$KNOWN_HOSTS" if [ $# -lt 1 ] ; then echo "Usage: $0 hostname [hostname . ]" >&2 exit 1; fi for host in "$@" do ssh $host $SSH_ARGS -1 echo '' ssh $host $SSH_ARGS - o'HostKeyAlgorithms=ssh-rsa' echo '' ssh $host $SSH_ARGS -o'HostKeyAlgorithms=ssh-dss' echo '' done

Опции настройки

StrictHostKeyChecking: Определяет, нужно ли при игнорировании ошибки во время соединения, связанной с ключом хоста, завершить работу сразу или спросить пользователя, хочет ли он продолжить работу.
CheckHostIP: Определяет, нужно ли проверять IP адрес сервера в файле known_hosts.
NoHostAuthenticationForLocalhost: Выключает проверку ключа для локальной машины. Может быть полезно, если вы настраиваете переадресацию трафика с порта SSH на удаленные машины, например ssh -p 9999 localhost, но вам нужно работать на локальной машине. Для этого лучше использовать HostKeyAliases.
HostKeyAlias: Эта опция позволяет указать псевдоним, который будет использоваться в командной строке вместо реального имени хоста, при поиске соответствия в файле known_hosts. Особенно это полезно для команд, использующих ProxyCommands для соединения, или при использовании различных портов на компьютере, которые переадресуют трафик на различные SSH сервера, находящиеся, например, за межсетевым экраном.
HostKeyAlgorithms: Алгоритм, который вы предпочитаете, RSA или DSA для второй версии протокола. По умолчанию это RSA, и если вы хотите, можете также следовать этой установке.

Сноски

[сноска 1] Это потому, что криптография, использующаяся для защиты вашего соединения, основана на надежном асимметричном шифровании, которое используется для верификации хоста. [сноска 2] Имейте ввиду, что это описание правильно для любого SSL/TLS совместимого сервиса с включенной авторизацией — это не должен быть HTTPS, а, например, может быть MySQL или LDAP через SSL. [сноска 3] Существуют патчи к OpenSSH, позволяющие производить аутентификацию по стандарту X509, поэтому вы можете использовать эту модель, если хотите. [сноска 4] Всегда есть возможность, что атакующий по схеме «человек посередине» следит за этой верификацией и может изменять ответы, чтобы убедить вас в совпадении ключей. Если атакующий хорошо подготовлен, он может доставить вам много проблем. [сноска 5] Это действительно так, однако, отключая проверку пароля, вы по крайнее мерее должны использовать SSH Identities/PubKeys, Challenge/Response или какие-нибудь другие формы аутентификации, которые не могут быть повторно использованы атакующим. [сноска 6] Обратное возможно, но маловероятно. [сноска 7] SSHv1 считается менее безопасным, чем SSHv2. Если вам не нужно использовать клиентское ПО, поддерживающее только старый протокол SSHv1, в целях безопасности лучше всего будет включить поддержку только SSHv2 на вашем сервере. Строчка Protocol в файле /etc/ssh/sshd_config должны выглядеть следующим образом:

# Protocol 2,1 would allow either SSHv1 or SSHv2. # Let's be paranoid and only support the later. Protocol 2

[сноска 8] ssh-keygen используется и для создания SSH Identities/PubKeys. Действительно нет никакой разницы между ключом пользователя и хоста. [сноска 9] Закрытый ключ не должен быть защищен паролем, чтобы sshd мог запуститься без вмешательства администратора после перезагрузки. [сноска 10] Срок патента на алгоритм RSA истек в 2000 году.