☰

Gibt es eine Möglichkeit, SSH automatisch mehrere Schlüssel zum Anmelden anbieten zu lassen?

tag-icon • tag-icon ssh login
Gibt es eine Möglichkeit, SSH automatisch mehrere Schlüssel zum Anmelden anbieten zu lassen?

Ich habe aus unzähligen Online-Quellen gelernt, dass man sich (ungefähr) wie folgt bei einem Remote-Server ohne Passwort anmelden kann: einen SSH-Schlüssel generieren, die öffentliche Version in authorized_keys auf dem Remote-System ablegen, die private Version in das lokale Verzeichnis ~/.ssh/ legen, sie mit chmod auf 0600 ändern und zack, schon ist man drin. Obwohl das größtenteils richtig ist, muss der Schlüssel (das Schlüsselpaar) meiner Meinung nach id_rsa (id_rsa.pub) oder id_dsa (id_dsa.pub) heißen, damit SSH ihn Remote-Servern anbieten kann.

Lassen Sie mich ein wenig zurückgehen. Ich habe einen Login SurnameGauf meinem lokalen Mac. Ich habe ein SurnameG-Konto auf einem Remote-System, einem anderen Server.

Ich habe den Inhalt in ~/.ssh/surnameg.pub/home/surnameg/.ssh/authorized_keys dieses Systems kopiert. Ich habe die -iOption zum SSH-Einloggen von meinem Mac aus getestet und es funktioniert einwandfrei.

Ich habe eine ~/.ssh/id_rsa(die ich für die Verwendung mit generiert habegithub.com).

Und natürlich habe ich ~/.ssh/surnamegauch noch ein paar andere Schlüssel dort, die nicht "ausprobiert" werden, wenn ich versuche, mich folgendermaßen einzuloggenandererserver.com:

ssh 1.2.3.4

Hier versuche ich, SurnameG(den aktuell lokal angemeldeten Benutzer) zu verwenden, um mich bei meinem SurnameGKonto anzumelden aufandererServer. Ich möchte, dass OpenSSH ~/.ssh/surnamegbei seinem Verbindungsversuch Folgendes anbietet, aber es tut es nicht. Sehen wir uns das mit der Option „Ausführlich“ genauer an:

BOX:~ SurnameG$ ssh -v 1.2.3.4
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/SurnameG/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to 1.2.3.4 [50.112.132.124] port 22.
debug1: Connection established.
debug1: identity file /Users/SurnameG/.ssh/id_rsa type 1
debug1: identity file /Users/SurnameG/.ssh/id_rsa-cert type -1
debug1: identity file /Users/SurnameG/.ssh/id_dsa type -1
debug1: identity file /Users/SurnameG/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
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 ax:64:3e:4a:e3:2c:e4:30:dd:36:a4:a0:9x:fa:ba:6b
debug1: Host '1.2.3.4' is known and matches the RSA host key.
debug1: Found key in /Users/SurnameG/.ssh/known_hosts:88
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
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/SurnameG/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /Users/SurnameG/.ssh/id_dsa
debug1: No more authentication methods to try.

Merkwürdigerweise bietet OpenSSH nur ~/.ssh/id_rsa an, aber das ist nicht alles. Es „versucht“ auch ~/.ssh/id_dsa? Ich bin mir nicht sicher, was der Unterschied zwischen den beiden ist (anbieten versus versuchen). Wie auch immer, wenn ich das richtig lese, probiert OpenSSH nie einen meiner anderen privaten Schlüssel in ~/.ssh/*.

Okay, ich weiß, ich kann jeden Server explizit beschreiben ~/.ssh/configmit etwas wie

Host otherserver
   HostName 1.2.3.4
   User surnameg
   IdentityFile ~/.ssh/surnameg

und melden Sie sich dann an mit

ssh otherserver

und das ist schön und gut und funktioniert super. Aber meine ~/.ssh/config wird langsam unhandlich. Leider war das cd ~/.ssh && git initvor langer Zeit noch nicht der Fall. Aber ich schweife ab.

Meine Frage ist folgende: Gibt es eine einfachere, schnellere und automatisiertere Möglichkeit, SSH dazu zu bringen, bei Anmeldeversuchen dynamisch mehrere Schlüssel im Verzeichnis ~/.ssh auszuprobieren, oder ist das Bearbeiten Ihrer ~/.ssh/config für jeden Server, mit dem Sie eine Verbindung herstellen müssen, die einzige Möglichkeit, SSH zu konfigurieren? Habe ich oben etwas darüber, wie SSH funktionieren soll, falsch verstanden?

Antwort1

Wenn Sie allen Hosts die gleichen Schlüssel anbieten möchten, laden Sie sie mit in einen SSH-Agenten ssh-add. Viele Linux-Distributionen starten einen solchen automatisch – versuchen Sie ssh-add -lzu überprüfen, ob er läuft, und laden Sie dann Ihre Schlüssel:

ssh-add ~/.ssh/id_rsa ~/.ssh/surnameg etc.

Wenn der Agent nicht automatisch gestartet wird, geben Sie Folgendes in Ihre ein ~/.profile:

agent_running() {
    [ "$SSH_AUTH_SOCK" ] && { ssh-add -l >/dev/null 2>&1 || [ $? -eq 1 ]; }
}

env=~/.ssh/agent.env
if ! agent_running && [ -s "$env" ]; then
    . "$env" >/dev/null
fi
if ! agent_running; then
    ssh-agent >"$env"
    . "$env" >/dev/null
    ssh-add ~/.ssh/id_*
fi    
unset env

Antwort2

Es gibt noch einen anderen möglichen Ansatz. Sie können Platzhalter in der IdentityFileOption in verwenden ssh_config. Gemäßman ssh_config:

  • %d– Home-Verzeichnis des lokalen Benutzers
  • %u—lokaler Benutzername
  • %l—lokaler Hostname
  • %h— Remote-Hostname
  • %r— Remote-Benutzername

Ich verwende es folgendermaßen (in der globalen ssh_configDatei):

IdentityFile ~/.ssh/%r@%h

Dies bedeutet, dass meine privaten Schlüsseldateien wie folgt benannt sind [email protected]:

verwandte Informationen