Jak skonfigurować SSH, aby nie próbował automatycznie wszystkich plików tożsamości?

Umieszczam pliki tożsamości ssh w folderze ~ / .ssh /. Mam tam prawdopodobnie około 30 plików.

Kiedy połączę się z serwerami, określę plik tożsamości, który będzie używany, z czymś takim

ssh -i ~ / .ssh / client1-tożsamość klient1@10.1.1.10

Jeśli jednak nie podam pliku tożsamości, wystarczy użyć czegoś takiego:

ssh użytkownik123@example.com

Dostaję błąd

Zbyt wiele błędów uwierzytelnienia dla użytkownika123

Rozumiem, że dlatego, że jeśli nie określono pliku tożsamości, a ssh może znaleźć pliki tożsamości, spróbuje je wszystkie.

Rozumiem również, że mogę edytować ~/.ssh/configplik i określić coś takiego:

Host example.com
Preferowane uwierzytelnienia: klawiatura interaktywna, hasło

aby uniemożliwić temu połączeniu próbowanie znanych plików tożsamości.

Wydaje mi się, że mógłbym przenieść moje pliki tożsamości poza ~/.ssh/katalog lub też określić w pliku konfiguracyjnym każdego hosta, dla którego chcę wyłączyć uwierzytelnianie pliku tożsamości, ale czy istnieje sposób, aby powiedzieć SSH, aby kupił domyślnie, aby nie szukał pliki tożsamości? Lub określić te, których będzie szukać?

Możesz użyć tej IdentitiesOnly=yesopcji razem z IdentityFile(patrz strona podręcznika ssh_config ). W ten sposób możesz określić, którego pliku (plików) powinien szukać.

W tym przykładzie ssh będzie szukał tylko tożsamości podanych w plikach ssh_config + 4 wymienione w wierszu poleceń (tożsamości podane przez agenta zostaną zignorowane):

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    user123@example.com

Formularze -ii -o IdentityFile=są wymienne.

Krótka odpowiedź użytkownika user76528 jest poprawna, ale właśnie miałem ten problem i pomyślałem, że przydałoby się jakieś rozwinięcie. Możesz również zainteresować się tym rozwiązaniem, jeśli zastanawiasz się „Dlaczego ssh ignoruje moją opcję konfiguracji pliku tożsamości”?

Po pierwsze, w przeciwieństwie do wszystkich innych opcji w ssh_config, ssh nie używa pierwszej IdentityFile, którą znajdzie. Zamiast tego IdentityFileopcja dodaje ten plik do listy używanych tożsamości. Możesz układać w stos wiele IdentityFileopcji, a klient ssh wypróbuje je wszystkie, dopóki serwer nie zaakceptuje jednej lub odrzuci połączenie.

Po drugie, jeśli użyjesz agenta ssh, ssh automatycznie spróbuje użyć kluczy w agencie, nawet jeśli nie określiłeś ich za pomocą opcji IdentityFile (lub -i) ssh_config. Jest to częsty powód Too many authentication failures for userbłędu. Użycie tej IdentitiesOnly yesopcji spowoduje wyłączenie tego zachowania.

Jeśli używasz ssh jako wielu użytkowników w wielu systemach, zalecam umieszczenie IdentitiesOnly yesglobalnej sekcji ssh_config i umieszczenie każdego z nich IdentityFilew odpowiednich podsekcjach Hosta.

Generalnie robię to tak:

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

Dostępne są następujące opcje:

• -o IdentitiesOnly=yes- informuje SSH, aby używał tylko kluczy dostarczonych przez CLI i żadnych z $HOME/.sshlub za pośrednictwem ssh-agent
• -F /dev/null - wyłącza użycie $HOME/.ssh/config
• -i ~/path/to/some_id_rsa - klucz, którego wyraźnie chcesz użyć do połączenia

Przykład

$ 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$

Zwróć uwagę na powyższe dane wyjściowe, które sshzidentyfikowały my_id_rsaklucz prywatny tylko za pomocą interfejsu CLI i używa go do łączenia się z jakimś serwerem.

W szczególności te sekcje:

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

i:

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

W scenariuszu, w którym masz wiele kluczy, niezmiennie napotykasz błąd „Zbyt wiele niepowodzeń uwierzytelniania”. Jeśli masz hasło i chcesz po prostu użyć hasła, aby się zalogować, oto jak to zrobić.

Aby użyć TYLKO uwierzytelnienia hasłem i NIE używać klucza publicznego, a NIE używać nieco wprowadzającej w błąd „interaktywnej klawiatury” (która jest nadzbiorem zawierającym hasło), możesz to zrobić z wiersza poleceń:

ssh -o PreferredAuthentications=password user@example.com

Użyj IdentityFile, ale nadal używaj ssh-agent, aby uniknąć powtórzeń hasła

Akceptowane rozwiązanie używania IdentitiesOnly yesoznacza, że ​​nigdy nie będziesz w stanie skorzystać z ssh-agent, co spowoduje powtarzanie monitów o podanie hasła podczas ładowania klucza.

Aby nadal używać ssh-agenti unikać błędów „Zbyt wiele niepowodzeń uwierzytelniania”, spróbuj wykonać następujące czynności:

1. Usuń wszystkie skrypty uruchamiania interaktywnej konsoli, które automatycznie ładują klucze ssh-agent.

2. dodaj AddKeysToAgent yesdo konfiguracji ssh swojego klienta. Spowoduje to wyświetlenie monitu o podanie hasła przy pierwszym połączeniu, ale następnie dodaj klucz do agenta.

3. używaj, ssh-add -Dgdy pojawi się błąd „zbyt wiele uwierzytelnień”. To po prostu „resetuje” (usuwa) pamięć podręczną agenta ssh. Następnie spróbuj ponownie nawiązać połączenie w tej samej sesji. Zostaniesz poproszony o hasło, a po zaakceptowaniu zostanie dodane do Twojego agenta. Ponieważ będziesz mieć tylko jeden klucz w swoim agencie, będziesz mógł się połączyć. Następnie ssh-agent jest nadal dostępny dla przyszłych połączeń podczas tej samej sesji, aby uniknąć ponownych monitów.

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

Klient ssh i ssh-agentkomunikuje się przez gniazdo domeny Unix, którego nazwę określa klient za pomocą SSH_AUTH_SOCKzmiennej środowiskowej (ustawionej przez agenta podczas jego uruchamiania).

Zatem, aby zapobiec pojedynczemu wywołaniu klienta w celu wysłania zapytania do agenta, zmienna ta może zostać jawnie ustawiona na coś niepoprawnego, na przykład pusty ciąg znaków;

$ SSH_AUTH_SOCK= ssh user@server

Takie wywołanie klienta nie powiedzie się w komunikacji z agentem i będzie w stanie zaoferować serwerowi tylko tożsamości dostępne w postaci plików ~/.ssh/lub dowolne określone w wierszu komend -i.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

Odpowiedź była przez cały czas (prawie):

Host *
PreferredAuthentications keyboard-interactive,password

Pracował dla mnie.

dodaj to na końcu ~/.ssh/configpliku, aby zapobiec użyciu kluczy dla serwerów innych niż konfiguracyjne:

Host *
IdentitiesOnly=yes