it-swarm.com.de

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 [email protected] 

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

 ssh [email protected] 

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/config-Datei bearbeiten und etwas wie Folgendes angeben kann:

 Host example.com 
 PreferredAuthentications keyboard-interactive, password 

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

Ich schätze, ich könnte meine Identitätsdateien aus dem Verzeichnis ~/.ssh/ 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, die Standardsuche nicht zu kaufen für Identitätsdateien? Oder um diejenigen anzugeben, nach denen gesucht werden soll?

95
cwd

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

In diesem Beispiel wird ssh only in den in den ssh_config-Dateien angegebenen Identitäten + den 4 in der Befehlszeile aufgeführten Identitäten suchen (die vom Agenten bereitgestellten Identitäten werden ignoriert):

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    [email protected]

Die Formulare -i und -o IdentityFile= sind austauschbar.

92
user76528

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 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 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 möglicherweise der Fehler Too many authentication failures for user auftritt. Die Verwendung der Option IdentitiesOnly yes deaktiviert dieses Verhalten.

Wenn Sie als mehrere Benutzer auf mehreren Systemen sshen, empfehle ich, IdentitiesOnly yes in Ihren globalen Abschnitt von ssh_config und jede IdentityFile in die entsprechenden Host-Unterabschnitte zu setzen.

77
chrishiestand

Ich tue es in der Regel wie folgt:

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

Folgende Optionen stehen zur Verfügung:

  • -o IdentitiesOnly=yes - sagt SSH nur mit den Tasten, die über die CLI und keine von der $HOME/.ssh oder via ssh-agent zur Verfügung gestellt werden
  • -F /dev/null - deaktiviert die Verwendung von $HOME/.ssh/config
  • -i ~/path/to/some_id_rsa - der 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 [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 hat und ihn zum Herstellen einer Verbindung mit einem Server verwendet.

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

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-interactive" (der eine Obermenge einschließlich des Kennworts ist) zu verwenden, können Sie dies über die Befehlszeile tun:

ssh -o PreferredAuthentications=password [email protected]
9
Greg Rundlett

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

Die akzeptierte Lösung für die Verwendung von IdentitiesOnly yes bedeutet, dass Sie den ssh-agent niemals nutzen können, was zu wiederholten Aufforderungen zur Eingabe Ihrer Passphrase führt, wenn Sie Ihren Schlüssel laden.

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

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

  2. füge AddKeysToAgent yes zur ssh Konfiguration deines 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 Sie ssh-add -D, 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
    
6
AndrewD

Der ssh-Client und der ssh-Agent kommunizieren über einen Unix-Domain-Socket, dessen Name dem Client von der Umgebungsvariablen SSH_AUTH_SOCK (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 [email protected]

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 in der Befehlszeile mit -i angegeben sind.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused
1
mikini

Sie hatten die Antwort die ganze Zeit (fast):

Host *
PreferredAuthentications keyboard-interactive,password

Hat für mich gearbeitet.

0
Henry Grebler