Wie konfiguriere ich SSH, damit nicht alle Identitätsdateien automatisch überprüft werden?

Ich habe meine ssh-Identitätsdateien in meinem ~ / .ssh / -Ordner abgelegt. Ich habe wahrscheinlich etwa 30 Dateien dort.

Wenn ich eine Verbindung zu Servern herstelle, gebe ich die zu verwendende Identitätsdatei mit so etwas wie an

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

Wenn ich jedoch keine Identitätsdatei spezifiziere und nur so etwas verwende:

ssh user123@example.com

Ich bekomme den Fehler

Zu viele Authentifizierungsfehler für user123

Ich verstehe das, weil wenn keine Identitätsdatei angegeben ist und ssh Identitätsdateien finden kann, es alle von ihnen versuchen wird.

Ich verstehe auch, dass ich die ~/.ssh/configDatei bearbeiten und Folgendes angeben kann:

Host example.com
PreferredAuthentications tastaturinteraktiv, Passwort

um zu verhindern, dass diese Verbindung bekannte Identitätsdateien versucht.

Ich schätze, ich könnte meine Identitätsdateien aus dem ~/.ssh/Verzeichnis verschieben oder jeden Host, für den ich die Identitätsdateiauthentifizierung deaktivieren möchte, in der Konfigurationsdatei angeben. Es gibt jedoch eine Möglichkeit, SSH anzuweisen, standardmäßig keine Suche zu kaufen Identitätsdateien? Oder um diejenigen anzugeben, nach denen gesucht werden soll?

Sie können die IdentitiesOnly=yesOption zusammen mit IdentityFile(siehe Manpage ssh_config ) verwenden. Auf diese Weise können Sie angeben, nach welchen Dateien gesucht werden soll.

In diesem Beispiel sucht ssh nur in den Identitäten, die in den ssh_config-Dateien angegeben sind, und in den vier in der Befehlszeile aufgelisteten Identitäten (die vom Agenten angegebenen Identitäten werden ignoriert):

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

Die Formen -iund -o IdentityFile=sind austauschbar.

Die kurze Antwort von user76528 ist richtig, aber ich hatte gerade dieses Problem und dachte, eine Ausarbeitung wäre nützlich. Diese Lösung interessiert Sie möglicherweise auch, wenn Sie sich gefragt haben, warum ssh die Konfigurationsoption für meine Identitätsdatei ignoriert.

Erstens verwendet ssh im Gegensatz zu jeder anderen Option in ssh_config nicht die erste IdentityFile, die es findet. Stattdessen IdentityFilefügt die Option diese Datei einer Liste der verwendeten Identitäten hinzu. Sie können mehrere IdentityFileOptionen stapeln , und der ssh-Client probiert sie alle aus, bis der Server eine akzeptiert oder die Verbindung ablehnt.

Zweitens, wenn Sie einen ssh-Agenten 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 Too many authentication failures for userFehler erhalten. Wenn Sie diese IdentitiesOnly yesOption verwenden, wird dieses Verhalten deaktiviert.

Wenn Sie ssh als mehrere Benutzer auf mehreren Systemen verwenden, empfehle ich, IdentitiesOnly yesIhren globalen Abschnitt von ssh_config und jeden IdentityFilein die entsprechenden Host-Unterabschnitte einzufügen .

Ich mache es im Allgemeinen so:

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

Folgende Optionen stehen zur Verfügung:

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

Beispiel

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

Beachten Sie in der obigen Ausgabe, dass sshnur der my_id_rsaprivate Schlüssel über die CLI identifiziert wurde und dass er zum Herstellen einer Verbindung mit einem Server verwendet wird.

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 sich einfach mit diesem Passwort anmelden möchten, gehen Sie wie folgt vor.

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

ssh -o PreferredAuthentications=password user@example.com

Verwenden Sie IdentityFile, aber weiterhin ssh-agent, um Passphrasenaufforderungen zu vermeiden

Die akzeptierte Lösung der Verwendung IdentitiesOnly yesbedeutet, dass Sie ssh-agent nie nutzen können, was zu wiederholten Aufforderungen zur Eingabe Ihrer Passphrase führt, wenn Sie Ihren Schlüssel laden.

ssh-agentVersuchen Sie Folgendes, um die Fehler "Zu viele Authentifizierungsfehler" weiterhin zu verwenden und zu vermeiden:

1. Entfernen Sie alle Startskripte für die interaktive Konsole, in die automatisch Schlüssel geladen werden ssh-agent.

2. Fügen AddKeysToAgent yesSie die SSH-Konfiguration Ihres Clients hinzu. Dadurch werden Sie beim ersten Herstellen einer Verbindung zur Eingabe der Passphrase aufgefordert. Fügen Sie dann den Schlüssel zu Ihrem Agenten hinzu.

3. Verwenden ssh-add -DSie diese Option, wenn zu viele Authentifizierungsfehler auftreten. Dadurch wird der ssh-agent-Cache einfach zurückgesetzt (gelöscht). Versuchen Sie dann erneut, die Verbindung innerhalb derselben Sitzung herzustellen. Sie werden aufgefordert, eine Passphrase einzugeben. Sobald die Passphrase akzeptiert wurde, wird sie Ihrem Agenten hinzugefügt. Da Sie nur einen Schlüssel in Ihrem Agenten haben, können Sie eine Verbindung herstellen. ssh-agent ist dann während derselben Sitzung weiterhin für zukünftige Verbindungen verfügbar, um erneute Eingabeaufforderungen 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 der ssh-agentkommunizieren über einen Unix-Domain-Socket, dessen Name dem Client von der SSH_AUTH_SOCKUmgebungsvariablen (die vom Agenten beim Start festgelegt wurde) angegeben wird.

Um zu verhindern, dass ein einzelner Aufruf des Clients den Agenten abfragt, kann diese Variable explizit auf einen ungültigen Wert wie eine leere Zeichenfolge gesetzt werden.

$ SSH_AUTH_SOCK= ssh user@server

Ein solcher Client-Aufruf kann nicht mit dem Agenten kommunizieren und kann dem Server nur die Identitäten anbieten, die als Dateien in ~/.ssh/oder über die Befehlszeile angegeben sind -i.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

Sie hatten die Antwort die ganze Zeit (fast):

Host *
PreferredAuthentications keyboard-interactive,password

Hat für mich gearbeitet.

Fügen Sie dies am Ende der ~/.ssh/configDatei hinzu, um die Verwendung von Schlüsseln für Nicht-Konfigurationsserver zu verhindern:

Host *
IdentitiesOnly=yes