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

Question

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

Когда я подключаюсь к серверам, я указываю файл идентификации для использования с чем-то вроде

ssh -i ~/.ssh/client1-identity client1@10.1.1.10

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

ssh user123@example.com

Я получаю ошибку

Too many authentication failures for user123

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

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

Host example.com
PreferredAuthentications keyboard-interactive,password

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

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

Answer 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 \
    user123@example.com

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

Answer 2

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

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

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

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

Answer 3

Я вообще так делаю так:

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa root@server.mydom.com

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

• -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 root@someserver.mydom.com
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 no-more-sessions@openssh.com
debug1: Entering interactive session.
Last login: Tue Dec  8 19:03:24 2015 from 153.65.219.15
someserver$

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

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

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).

Answer 4

В сценарии, где у вас много ключей, вы всегда будете сталкиваться с ошибкой "Too many Authentication Failures". Если у вас есть пароль, и вы хотите просто использовать пароль для входа в систему, вот как вы это делаете.

Чтобы использовать ТОЛЬКО аутентификацию по паролю, НЕ использовать открытый ключ и НЕ использовать вводящее в заблуждение «клавиатурно-интерактивный» (который является надмножеством, включающим пароль), вы можете сделать это из командной строки:

ssh -o PreferredAuthentications=password user@example.com

Answer 5

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

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

Чтобы продолжать использовать ssh-agent и избежать ошибок «Too many failures failures», попробуйте следующее:

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
   

Answer 6

Клиент ssh и агент ssh обмениваются данными через сокет домена Unix, имя которого указывается клиенту переменной среды SSH_AUTH_SOCK (устанавливается агентом при запуске).

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

$ SSH_AUTH_SOCK= ssh user@server

Подобный вызов клиента не сможет установить связь с агентом и сможет предложить серверу только идентификаторы, доступные в виде файлов в ~/.ssh/или любых, указанных в командной строке с помощью -i.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

Answer 7

У вас был ответ все время (почти):

Host *
PreferredAuthentications keyboard-interactive,password

Работал на меня.