☰

Как настроить SSH, чтобы он не пробовал все файлы идентификации автоматически?

tag-icon • tag-icon linux ssh unix authentication private-key
Как настроить SSH, чтобы он не пробовал все файлы идентификации автоматически?

Я поместил свои файлы идентификации ssh в свою ~/.ssh/папку. У меня там, наверное, около 30 файлов.

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

ssh -i ~/.ssh/client1-identity[email protected]

Однако, если я не укажу файл идентификации, а просто использую что-то вроде этого:

сш[email protected]

Я получаю сообщение об ошибке

Слишком много неудачных попыток аутентификации для пользователя 123

Я понимаю, что это происходит потому, что если файл идентификации не указан, а ssh может его найти, то он попробует их все.

Я также понимаю, что могу редактировать ~/.ssh/configфайл и указывать что-то вроде:

Хост example.com
Предпочтительные аутентификации клавиатура-интерактивная,пароль

чтобы предотвратить попытки этого соединения использовать известные файлы идентификации.

Итак, я думаю, что я мог бы переместить свои файлы идентификации за пределы каталога ~/.ssh/, или я мог бы указать каждый хост, для которого я хочу отключить аутентификацию по файлам идентификации в файле конфигурации, но есть ли способ указать SSH по умолчанию не искать файлы идентификации? Или указать те, которые он будет искать?

решение1

Вы можете использовать IdentitiesOnly=yesопцию вместе с IdentityFile(см.Страница руководства ssh_config). Таким образом, вы можете указать, какие файлы следует искать.

В этом примере ssh будеттолькопросмотрите идентификаторы, указанные в файлах ssh_config, а также 4 идентификатора, перечисленных в командной строке (идентификаторы, предоставленные агентом, будут проигнорированы):

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    [email protected]

Формы -iи -o IdentityFile=взаимозаменяемы.

В .ssh/config, вы можете включить конфигурацию следующим образом:

Host example
User user123
Hostname example.com
IdentityFile ~/.ssh/id_rsa_example
IdentityFile ~/.ssh/id_rsa_example2
IdentitiesOnly yes

решение2

краткий ответ пользователя 76528верно, но у меня просто возникла эта проблема, и я подумал, что некоторые пояснения будут полезны. Вам также может быть интересно это решение, если вы задавались вопросом "Почему ssh игнорирует мой параметр конфигурации identityfile"?

Во-первых, в отличие от всех остальных опций в ssh_config, ssh не использует первую IdentityFileнайденную. Вместо этого IdentityFileопция добавляет этот файл в список используемых идентификаторов. Вы можете сложить несколько IdentityFileопций, и клиент ssh будет пробовать их все, пока сервер не примет одну или не отклонит соединение.

Во-вторых, если вы используете ssh-agent, ssh автоматически попытается использовать ключи в агенте, даже если вы не указали их с помощью опции in ssh_config's IdentityFile(или -i). Это распространенная причина, по которой вы можете получить Too many authentication failures for userошибку. Использование IdentitiesOnly yesопции отключит это поведение.

Если вы подключаетесь по ssh как несколько пользователей к нескольким системам, я рекомендую IdentitiesOnly yesвам включить глобальный раздел ssh_configи поместить каждый из них IdentityFileв соответствующие подразделы Host.

решение3

Я обычно делаю это так:

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa [email protected]

Возможны следующие варианты:

  • -o IdentitiesOnly=yes- сообщает SSH, что нужно использовать только ключи, предоставленные через CLI, а не ключи из $HOME/.sshили через ssh-agent
  • -F /dev/null- отключает использование$HOME/.ssh/config
  • -i ~/path/to/some_id_rsa- ключ, который вы явно хотите использовать для соединения

Пример

$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa [email protected]
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /dev/null
debug1: Connecting to someserver.mydom.com [10.128.12.124] port 22.
debug1: Connection established.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA f5:60:30:71:8c:a3:da:a3:fe:b1:6d:0b:20:87:23:e1
debug1: Host 'someserver' is known and matches the RSA host key.
debug1: Found key in /Users/sammingolelli/.ssh/known_hosts:103
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to someserver.mydom.com ([10.128.12.124]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
Last login: Tue Dec  8 19:03:24 2015 from 153.65.219.15
someserver$

Обратите внимание, что в приведенном выше выводе закрытый ключ sshбыл идентифицирован только my_id_rsaчерез CLI и используется для подключения к некоторому серверу.

Конкретно эти разделы:

debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1

и:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

решение4

Используйте IdentityFile, но продолжайте использовать ssh-agent, чтобы избежать повторных запросов на ввод пароля

Принятое решение с использованием IdentitiesOnly yesозначает, что вы никогда не сможете воспользоваться ssh-agent, что приведет к повторным запросам на ввод парольной фразы при загрузке ключа.

Чтобы продолжить использование ssh-agentи избежать ошибок «Слишком много ошибок аутентификации», попробуйте сделать следующее:

  1. Удалите все интерактивные скрипты запуска консоли, которые автоматически загружают ключи в ssh-agent.

  2. добавить AddKeysToAgent yesв конфигурацию ssh вашего клиента. Это запросит у вас парольную фразу при первом подключении, но затем добавит ключ к вашему агенту.

  3. используйте ssh-add -D, когда вы получаете «слишком много ошибок аутентификации». Это просто «сбрасывает» (удаляет) ваш кэш ssh-agent. Затем попробуйте подключиться снова в том же сеансе. Вам будет предложено ввести парольную фразу, и после ее принятия она будет добавлена ​​к вашему агенту. Поскольку у вас будет только один ключ в вашем агенте, вам будет разрешено подключиться. ssh-agent затем останется там для будущих подключений в том же сеансе, чтобы избежать повторных запросов.

    Host ex example.com
   User joe
   HostName example.com
   PreferredAuthentications publickey,password
   IdentityFile /path/to/id_rsa
   AddKeysToAgent yes

Связанный контент