Wie konfiguriere ich SSH, damit nicht alle Identitätsdateien automatisch ausprobiert werden?

Die kurze Antwort von User76528 ist korrekt, aber ich hatte gerade dieses Problem und dachte, einige Ausarbeitungen wären nützlich. Sie könnten sich auch für diese Lösung interessieren, wenn Sie sich gefragt haben: "Warum ignoriert ssh meine identityfile-Konfigurationsoption?"

Erstens verwendet ssh im Gegensatz zu jeder anderen Option in ssh_config nicht das erste IdentityFile, das es findet. Stattdessen fügt die Option IdentityFile diese Datei einer Liste der verwendeten Identitäten hinzu. Sie können mehrere IdentityFile Optionen stapeln, und der ssh-Client versucht sie alle, bis der server akzeptiert eine oder lehnt die Verbindung ab.

Wenn Sie einen ssh-Agent verwenden, versucht ssh automatisch, die Schlüssel im Agenten zu verwenden, auch wenn Sie sie nicht mit der Option IdentityFile (oder-i) von ssh_config angegeben haben. Dies ist ein häufiger Grund, warum Sie möglicherweise den Fehler Too many authentication failures for user erhalten. Mit der Option IdentitiesOnly yes wird dieses Verhalten deaktiviert.

Wenn Sie ssh als mehrere Benutzer für mehrere Systeme verwenden, empfehle ich, IdentitiesOnly yes in Ihren globalen Abschnitt von ssh_config zu setzen und jedes IdentityFile in die entsprechenden Host-Unterabschnitte.

Ich mache es im Allgemeinen so:

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

Die Optionen sind wie folgt:

• -o IdentitiesOnly=yes - weist SSH an, nur Schlüssel zu verwenden, die über die CLI bereitgestellt werden, und keine von $HOME/.ssh oder über ssh-agent
• -F /dev/null - deaktiviert die Verwendung von $HOME/.ssh/config
• -i ~/path/to/some_id_rsa - der Schlüssel, den Sie explizit für die Verbindung verwenden möchten

Beispiel

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

Beachten Sie in der obigen Ausgabe, dass ssh nur den privaten Schlüssel my_id_rsa über die CLI identifiziert und verwendet hat so stellen Sie eine Verbindung zu someserver her.

Speziell diese Abschnitte:

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

Und:

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

In dem Szenario, in dem Sie viele Schlüssel haben, wird immer der Fehler "Zu viele Authentifizierungsfehler" angezeigt. Wenn Sie ein Passwort haben, und wollen einfach das Passwort verwenden, um sich anzumelden, hier ist, wie Sie es tun.

Um NUR die Passwortauthentifizierung zu verwenden und KEINEN öffentlichen Schlüssel zu verwenden und NICHT den etwas irreführenden "keyboard-interactive" (der eine Obermenge einschließlich Passwort ist) zu verwenden, können Sie dies über die Befehlszeile tun:

ssh -o PreferredAuthentications=password [email protected]

Verwenden Sie IdentityFile, verwenden Sie jedoch weiterhin ssh-agent, um Passphrase-Reprompts zu vermeiden

Die akzeptierte Lösung für die Verwendung von IdentitiesOnly yes bedeutet, dass Sie ssh-agent niemals nutzen können, was zu wiederholten Eingabeaufforderungen für Ihre Passphrase beim Laden Ihres Schlüssels führt.

Um weiterhin ssh-agent zu verwenden und die Fehler "Zu viele Authentifizierungsfehler" zu vermeiden, versuchen Sie Folgendes:

1. Entfernen Sie alle interaktiven Konsolenstartskripte, die Schlüssel automatisch in ssh-agent laden.

2. Hinzufügen AddKeysToAgent yes zur SSH-Konfiguration Ihres Clients. Dadurch werden Sie bei der ersten Verbindung zur Passphrase aufgefordert, aber fügen Sie dann den Schlüssel zu Ihrem Agenten hinzu.

3. Verwenden Sie ssh-add -D, wenn Sie "Zu viele Authentifizierungsfehler" erhalten. Dadurch wird Ihr SSH-Agent-Cache einfach "zurückgesetzt" (gelöscht). Versuchen Sie dann die Verbindung innerhalb derselben Sitzung erneut. Sie werden zur Eingabe einer Passphrase aufgefordert und nach der Annahme zu Ihrem Agenten hinzugefügt. Da Sie nur einen Schlüssel in Ihrem Agenten haben, können Sie eine Verbindung herstellen. ssh-agent ist dann immer noch für zukünftige Verbindungen während derselben Sitzung da, um Reprompts zu vermeiden.

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

Der ssh-Client und ssh-agent kommunizieren über einen Unix-Domänensocket, dessen Name dem Client durch die Umgebungsvariable SSH_AUTH_SOCK (vom Agenten beim Start festgelegt) angegeben wird.

Um zu verhindern, dass ein einzelner Aufruf des Clients den Agenten abfragt, kann diese Variable explizit auf etwas Ungültiges gesetzt werden, z. B. eine leere Zeichenfolge.

$ SSH_AUTH_SOCK= ssh user@server

Ein Clientaufruf wie dieser schlägt fehl, mit dem Agenten zu kommunizieren, und kann nur die Identitäten anbieten, die als verfügbar sind dateien in ~/.ssh/ oder in der Befehlszeile mit -i angegebenen Dateien an den Server.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

Fügen Sie dies am Ende der Datei ~/.ssh/config hinzu, um die Verwendung von Schlüsseln für nichtkonfigurierte Server zu verhindern:

Host *
IdentitiesOnly=yes

Sie hatten die Antwort die ganze Zeit (fast):

Host *
PreferredAuthentications keyboard-interactive,password

Arbeitete für mich.