Kann der ssh-Client nicht alle öffentlichen Schlüssel anbieten, die er finden kann?

32

Wie die meisten Sysadmins verwende ich OpenSh die ganze Zeit. Ich habe ungefähr ein Dutzend SSH-Schlüssel. Ich möchte für jeden Host einen anderen SSH-Schlüssel haben. Dies verursacht jedoch ein Problem, wenn ich zum ersten Mal eine Verbindung zu einem Host herstelle und ich nur ein Kennwort habe. Ich möchte nur mit einem Passwort eine Verbindung zum Host herstellen, in diesem Fall ohne SSH-Schlüssel. Der ssh-Client bietet jedoch alle öffentlichen Schlüssel in meinem an ~/.ssh/(das weiß ich aus der Ausgabe von ssh -v). Da ich so viele habe, werde ich wegen zu vieler Authentifizierungsfehler getrennt.

Gibt es eine Möglichkeit, meinem ssh-Client mitzuteilen, dass er nicht alle ssh-Schlüssel anbieten soll?

ssh public-key private-key

— Rory
quelle

2

Warum möchten Sie für jeden Host einen anderen Schlüssel? Schlüssel können auch von mehreren Hosts innerhalb einer einzigen Verwaltungsdomäne gemeinsam genutzt werden. Natürlich würden Sie einen Schlüssel für Ihre Arbeitsmaschinen und einen anderen für Ihre privaten Maschinen verwenden, aber welche Logik steckt dahinter, wenn Sie für jede Maschine bei der Arbeit einen eigenen Schlüssel verwenden?

— Alex Holst

@AlexHolst Ich benutze viele Schlüssel. Ich habe eine Standardverschlüsselung (für die ich ein Passwort eingeben muss) für die interne Infrastruktur. Ich habe einen anderen Dienst, der nicht verschlüsselt ist (ohne Passwort) und den ich für einen bestimmten Dienst verwende, für den ich keinen Agenten verwenden konnte oder der nicht jede Minute das Passwort eingeben möchte. Ich habe andere für Verbindungen, die nicht Teil unserer internen Infrastruktur sind. Dies ist eine gute Vorgehensweise, da es zwar für jemanden ziemlich schwierig sein sollte, den privaten Schlüssel vom öffentlichen Schlüssel wiederherzustellen, dies jedoch möglich ist. zB der Debian-Eröffnungsfehler vor einigen Jahren ...

— Huygens

@Huygens Ich würde gerne Ihr Risikoanalysedokument sehen, das zu der Schlussfolgerung führte, dass Sie mehrere SSH-Schlüssel verwenden müssen, aber ein Klartextschlüssel ist in Ordnung. Können Sie einen Link posten?

— Alex Holst

@AlexHolst du musst nicht so "direkt" sein. Zunächst ging es bei meiner Antwort um Gründe für mehrere Schlüsselpaare. Ich glaube, ich habe dir mehrere gegeben. Danach müssen wir uns alle mit Macken auseinandersetzen und was nicht. Ich habe ein Testsystem, für das ich keine App verwenden kann, die Daten über SSH tunnelt, ohne ständig zur Eingabe des Schlüsselkennworts aufgefordert zu werden, wodurch die Software nicht verwendet werden kann. Es scheint ein Fehler zu sein, der an der Inkompatibilität von Versionen liegt oder nicht. Ich erhalte eine E-Mail-Benachrichtigung für jede SSH-Anmeldung und bin der einzige, der sich in dieser Box anmeldet. Das Risiko ist also akzeptabel.

— Huygens

31

Dies ist das erwartete Verhalten gemäß der Manpage von ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity is read.  The default is ~/.ssh/identity for protocol
         version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for
         protocol version 2.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

Grundsätzlich werden durch die Angabe von IdentityFiles nur Schlüssel zu einer aktuellen Liste hinzugefügt, die der SSH-Agent dem Client bereits präsentiert hat.

Überschreiben Sie dieses Verhalten mit dem folgenden Befehl am Ende Ihrer .ssh/configDatei:

Host *
  IdentitiesOnly yes

Sie können diese Einstellung auch auf der Host-Ebene überschreiben, z.

Host foo
  User bar
  IdentityFile /path/to/key
  IdentitiesOnly yes

— Mathias Bynens
quelle

4

Sie können auch das verwenden ssh -o "IdentitiesOnly true" -v -A user@host, mit dem ich mich bei einem Computer anmelde, auf dem keiner meiner Schlüssel vorhanden ist, aber ich möchte eine Agentenweiterleitung anbieten, um fortzufahren. ( -vzum ausführlichen Debuggen).

— Eckes

1

@eckes das ist ein netter tipp, sollte es aber nicht sein yes(und auch nicht true)?

— 1.

IdentitiesOnlyMöglicherweise hilft dies nicht immer. Möglicherweise müssen Sie einen Host speziell ausschließen. siehe superuser.com/questions/859661/...

— aexl

38

Obwohl andere dies mit konfigurationsbasierten Lösungen angedeutet haben, ist es wahrscheinlich erwähnenswert, darauf hinzuweisen, dass Sie dies auf einfache Weise einmalig in der Befehlszeile tun können:

ssh -o 'PubkeyAuthentication no' myhostname.mydomain

— Andrew Ferrier
quelle

3

Perfekt .. DIE

— LÖSUNG

1

Korrigieren Sie dies sollte die akzeptierte Antwort gewesen sein.

— JM Becker

11

Nach der Lösung von James Sneeringer möchten Sie möglicherweise eine ssh_config wie folgt festlegen:

Host *.mycompany.com
  IdentityFile .ssh/id_dsa_mycompany_main

Host *.mycustomer.com
  IdentityFile .ssh/id_dsa_mycustomer

Host *
  RSAAuthentication no #this should be up top, avoid ssh1 at all costs
  PubkeyAuthentication no

Wenn Sie mit einem bestimmten Schlüssel eine Verbindung zu mehreren Computern herstellen, die sich nicht in einer gemeinsamen Domäne befinden, sollten Sie ihnen alle CNAMEs in Ihrem eigenen DNS zuweisen. Das mache ich mit allen Kundensystemen.

— Justin Alan Ryan
quelle

2

Ähnlich wie bei der Lösung von user23413 können Sie die Authentifizierung mit öffentlichen Schlüsseln für einen bestimmten Host (oder ein Platzhaltermuster) deaktivieren:

Host *.example.org
RSAAuthentication no        # SSHv1
PubkeyAuthentication no     # SSHv2

— James Sneeringer
quelle

-1

Wenn Sie mit ssh -i / path / to / key auf eine bestimmte Schlüsseldatei verweisen, wird diese nur verwendet, auch wenn andere in den Agenten geladen sind, und Sie werden nicht zur Eingabe des Kennworts aufgefordert. Sie können auch ~ / .ssh / config bearbeiten und so etwas hinzufügen ...

Host foo.example.com
IdentityFile .ssh / id_rsa_foo.example.com

Sie können auch tun ...

Host * .example.org
IdentityFile .ssh / id_rsa_example.org

— ryanc
quelle

Das fügt dem Zielschlüssel nur das Ende der Liste hinzu, wodurch das Problem nicht gelöst wird. IdentitiesOnlynur mit diesem Willen.

— Jo Rhett