Як налаштувати SSH, щоб він не перевіряв усі файли посвідчення автоматично?

Я розміщую свої файли посвідчення ssh всередині моєї папки ~ / .ssh /. У мене, мабуть, там близько 30 файлів.

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

ssh -i ~ / .ssh / client1-особистість client1@10.1.1.10

Однак якщо я не вказую файл посвідчення, а просто використовую щось подібне:

ssh user123@example.com

Я отримую помилку

Занадто багато збоїв аутентифікації для користувача123

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

Я також розумію, що я можу редагувати ~/.ssh/configфайл і вказати щось на кшталт:

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

щоб запобігти тому, щоб це з'єднання не намагалося пробувати відомі файли ідентичності.

Отже, я думаю, я міг би перенести свої файли посвідчення за межі ~/.ssh/каталогу, або я міг би вказати кожному хосту, що я хочу відключити автентифікацію файлу ідентичності у конфігураційному файлі, але чи є спосіб сказати SSH купувати за замовчуванням не шукати ідентифікаційні файли? Або вказати ті, які він шукатиме?

Ви можете використовувати IdentitiesOnly=yesпараметр разом із IdentityFile(див. Сторінку man 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 ігнорує параметр конфігурації мого посвідчення особи"?

По-перше, на відміну від усіх інших параметрів у ssh_config, ssh не використовує перше, IdentityFileщо знайде. Замість цього IdentityFileопція додає цей файл до списку використаних ідентичностей. Ви можете укладати кілька IdentityFileваріантів, і ssh-клієнт буде переглядати їх доти, доки сервер не прийме або не відхилить з'єднання.

По-друге, якщо ви використовуєте ssh-агент, ssh автоматично спробує використати ключі в агенті, навіть якщо ви не вказали їх в опції IdentityFile (або -i) ssh_config. Це поширена причина, через яку ви можете отримати 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-агент
• -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).

У сценарії, де у вас багато ключів, ви незмінно зіткнетесь з помилкою "Занадто багато помилок аутентифікації". Якщо у вас є пароль і ви хочете просто використовувати пароль для входу, ось як це зробити.

Щоб використовувати ТОЛЬКУ автентифікацію пароля і НЕ використовувати відкритий ключ, а НЕ використовувати дезактивні "клавіатурно-інтерактивні" (це суперсеть, включаючи пароль), ви можете зробити це з командного рядка:

ssh -o PreferredAuthentications=password user@example.com

Використовуйте IdentityFile, але продовжуйте використовувати ssh-агент, щоб уникнути ретроптів пароля

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

Щоб продовжувати використовувати ssh-agentта уникати помилок "Забагато помилок аутентифікації", спробуйте:

1. Видаліть будь-які сценарії запуску інтерактивної консолі, які автоматично завантажують ключі ssh-agent.

2. додати AddKeysToAgent yesв ssh-конфігурацію свого клієнта. Це сповістить вас про введення парольної фрази при першому підключенні, але потім додайте ключ до свого агента.

3. використовувати, ssh-add -Dколи ви отримуєте "занадто багато помилок аутентифікації". Це просто "скидає" (видаляє) кеш вашого ssh-агента. Потім спробуйте підключити знову протягом того ж сеансу. Вам буде запропоновано ввести парольну фразу, і як тільки вона буде прийнята, вона буде додана вашому агенту. Оскільки у вашого агента буде лише один ключ, вам буде дозволено підключитися. ssh-агент тоді все ще є для майбутніх з'єднань під час того ж сеансу, щоб уникнути репромтів.

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

Ssh-клієнт та 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