Проверьте, какие ключи ssh приняты на сервере

У меня есть каталог, полный секретных ключей ssh, и я хотел бы проверить, какие ключи приняты на каком сервере без входа. Как это сделать, не добавляя ssh-ключи к моему клиенту проверки подлинности с помощью ssh-add или logging in на сервере? Как ssh знает, с какими ключами он должен пытаться аутентифицироваться? Отправляет ли сервер отпечатки пальцев ключей, которые он может использовать, или клиент отправляет все свои отпечатки пальцев, а затем сервер проверяет их?

2 Solutions collect form web for “Проверьте, какие ключи ssh приняты на сервере”

Вы можете использовать что-то вроде:

 #!/bin/bash KEYPATH=~/.ssh/* HOSTS=( localhost hosta hostb ) probekey () { for privkey in $KEYPATH do if [[ "$(file $privkey)" =~ "private" ]] then #echo "Probing key $privkey for host $1" ssh -i "${privkey}" -o "IdentitiesOnly yes" -o "PreferredAuthentications publickey" -o "ControlMaster no" "$1" exit 2>/dev/null if [ "$?" == "0" ] then echo "Key ${privkey} matches for host $1" fi fi done } for HOST in ${HOSTS[@]} do probekey $HOST done 

Обычно этот сценарий выполняет итерацию через массив хостов ( $HOSTS ) и выполняет функцию probekey . Функция выполняет итерацию через список файлов в $KEYPATH , проверяет, является ли тип файла закрытым (для файлов личного ключа RSA или DSA), и если он соответствует ему, он запускает ssh соединение с хостом с использованием этого конкретного ключа. Если соединение было успешным, код возврата равен 0 и печатается сообщение.

Это не точный ответ на вопрос, потому что он выполняет вход в систему на хост (когда совпадает ключ) и выполняет команду exit чтобы снова exit из системы.

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

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

Клиент SSH может выбрать, какой ключ (ы) он пытается отправить на сервер. С помощью OpenSSH это можно настроить с помощью параметра конфигурации IdentityFile ( -i command line option) и путем выбора ключей для загрузки в ssh-agent или указания опции конфигурации IdentitiesOnly . Сервер отправляет вызов (случайно сгенерированную строку) клиенту. Клиент должен ответить на вызов, криптографически подписанный с закрытым ключом, вместе с соответствующим открытым ключом¹. Сервер проверяет, что подпись является действительной сигнатурой вызова с этим ключом, и что комбинация запрошенного имени пользователя и открытого ключа действительна. (Как правило, последняя часть означает, что существует строка с этим открытым ключом в файле ~/.ssh/authorized_keys .) Клиенту разрешено несколько попыток (после того, как несколько серверов откажутся и закроют соединение).

Если вы забыли, какой из ваших ключей действителен для какого сервера, самым простым способом является вход на сервер и проверка файла ~/.ssh/authorized_keys . Если единственный способ, которым вы знаете, чтобы войти на этот сервер, – это попробовать каждый ключ до тех пор, пока вам не удастся добиться успеха, тогда вам придется это сделать (что, конечно же, скажет вам, какой ключ вы можете использовать, поэтому вам не нужно читать ~/.ssh/authorized_keys ). Если вам нужно сделать много попыток в той же учетной записи, будьте готовы к тому, что сервер завершит соединение до того, как вы закончите; подождите несколько секунд и повторите попытку.

Для дальнейшего использования, если у вас много разных ключей, поддерживайте .ssh/config которая имеет правильную директиву IdentityFile для каждого хоста.

¹ Я упрощаю фактический протокол , сохраняя только то, что здесь необходимо.

  • Должен ли я создавать резервные копии моих ключей хоста SSH?
  • Могу ли я отменить SSH (после его использования для просмотра) без выхода из системы?
  • Будучи запрошенным для пароля после уже зарегистрированного открытого ключа На сервере
  • Доступ к Time Capsule Drive из SSH?
  • Как запомнить пароль ssh с помощью lsyncd?
  • соединение шпатлёвки работает, но командная строка ssh отказывается от аутентификации пароля
  • службы тестирования / открытые порты с telnet?
  • piping пароль, расположенный в файле, в команду ssh
  • Выполнять команды bash над SSH во время пребывания в интерактивном режиме
  • ssh частно-открытый ключ для клиента
  • SSH - невозможно получить доступ к локальному переходу с другого хоста
  • Interesting Posts

    Не удалось сделать работу с тачпадом

    Как возможно, что dpkg не требуется для установки пакетов deb?

    Инструменты Linux для удаления резервных копий, когда они становятся слишком старыми?

    Что делает l_i_version в extode inode?

    Можно ли увидеть ошибки при выполнении скрипта внутри скрипта?

    Как я могу сделать readline добавить предварительно введенный текст при запуске терминала?

    Отменить завершение, но только завершение, в zsh

    Глобус с помощью скобок и переменных в zsh

    Присоедините два файла, каждый из которых содержит два столбца, которые имеют несколько столбцов.

    Как удалить USB-накопитель, не беспокоясь о его размонтировании?

    Передайте F10 в приложение в Gnome-terminal

    Печать строк с похожим текстом вместе

    Учебное пособие по отображению ключей в KSH в режиме EMACS

    Команда установки Linux

    Использовать VirtualBox для доступа к сайту на хосте от гостя? хост и гость – linux

    Linux и Unix - лучшая ОС в мире.