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

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

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

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

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

ssh user123@example.com

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

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

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

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

Хост example.com
PreferredAuthentications клавиатура-интерактив, пароль

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

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

Вы можете использовать эту 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=взаимозаменяемы.

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

Во-первых, в отличие от любого другого параметра в 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.

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

$ 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 и что он использует его для подключения к какому-либо серверу.

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

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

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

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

ssh -o PreferredAuthentications=password user@example.com

Используйте 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
   

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

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

$ SSH_AUTH_SOCK= ssh user@server

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

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

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

Host *
PreferredAuthentications keyboard-interactive,password

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

добавьте это в конец ~/.ssh/configфайла, чтобы не использовать ключи для неконфигурационных серверов:

Host *
IdentitiesOnly=yes