Ich habe vor ein paar Monaten eine kleine Linux-Box eingerichtet und sowohl für meine persönliche Benutzer-ID als auch für eine Dienstkonto-ID eine passwortlose SSH-Anmeldung eingerichtet. Das funktioniert für beides einwandfrei. Ich habe die privaten/öffentlichen Schlüsseldateien für das Dienstkonto am selben Ort gespeichert, an dem ich die Schlüssel für meine persönliche Benutzer-ID gespeichert habe, nämlich auf der Client-Box.
Als grundlegende Anleitung verwende ich Folgendes:http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/.
Heute habe ich eine zweite Box eingerichtet, die ich auf die gleiche Weise konfigurieren wollte. Ich hatte keine Probleme, sie mit meiner persönlichen Benutzer-ID zum Laufen zu bringen. Allerdings funktioniert sie immer noch nicht mit dem Dienstkonto, aber ich verstehe nicht, warum. Wenn ich versuche, mit dem Dienstkonto per SSH auf die zweite Box zuzugreifen, werde ich zur Eingabe des Passworts aufgefordert und kann dann zugreifen.
Ich habe überprüft, dass der öffentliche Schlüssel für das Dienstkonto auf beiden Boxen in die Datei ~/.ssh/authorized_keys eingefügt ist und der Schlüsselwert auf beiden Boxen derselbe ist.
Ich habe überprüft, dass ~/.ssh Berechtigungsstufen von 700 und ~/.ssh/authorized_keys Berechtigungsstufen von 600 hat (ich habe auch mit 640 getestet, was der empfohlene Wert ist, den ich gelesen habe). Ich habe dies auf beiden Boxen im Home-Verzeichnis für das Servicekonto überprüft.
Beachten Sie, dass die numerische Benutzer-ID für das Dienstkonto auf beiden Boxen unterschiedlich ist. Ich würde nicht denken, dass das einen Unterschied macht.
Mir fällt auch auf, dass ich zur Eingabe eines Kennworts aufgefordert werde, wenn ich, nachdem ich mit dem Dienstkonto eine SSH-Verbindung zu einer der Boxen hergestellt habe, anschließend versuche, von dieser Box aus mit dem Dienstkonto eine SSH-Verbindung zu der ANDEREN Box herzustellen.
Muss ich etwas mit „known_hosts“ oder etwas anderes machen?
Aktualisieren:
Wie empfohlen habe ich versucht, SSH mit „-v“ auszuführen und die Ausgabe des SSH-Versuchs zu überprüfen.
Dies ist die Ausgabe (mit einigen Auslassungen):
% ssh -v [email protected]
OpenSSH_7.2p2, OpenSSL 1.0.2h 3 May 2016
debug1: Reading configuration data /home/myuserid/.ssh/config
debug1: /home/myuserid/.ssh/config line 2: Applying options for *
debug1: Connecting to targethost.com [...] port 22.
debug1: Connection established.
debug1: identity file /home/myuserid/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to targethost.com:22 as 'serviceaccountid'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:...
debug1: Host 'targethost.com' is known and matches the ECDSA host key.
debug1: Found key in /home/myuserid/.ssh/known_hosts:18
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
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: /home/myuserid/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/myuserid/.ssh/id_dsa
debug1: Trying private key: /home/myuserid/.ssh/id_ecdsa
debug1: Trying private key: /home/myuserid/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected]'s password:
Ich finde es merkwürdig, dass in den letzten Zeilen nach „Nächste Authentifizierungsmethode: publickey“ die Dateipfadverweise auf „/home/myuserid“ und nicht auf „/home/serviceaccountid“ lauten. Das scheint ein wichtiger Hinweis zu sein.
Antwort1
Ich kann mit meinem Konto keine Kommentare hinzufügen, aber ich versuche nur, mehr zu erfahren, um bei der Fehlerbehebung zu helfen.
Es klingt, als hätten Sie drei Computer, einen lokalen und zwei Remote-Computer. Und jeder von ihnen hat zwei Konten, mit denen Sie arbeiten?
Wenn Sie über ein persönliches und ein Dienstkonto auf dem lokalen Computer verfügen und ssh service@remote-2das Programm von dem persönlichen Konto auf Ihrem lokalen Computer ausführen, werden nur SSH-Schlüssel für Ihr lokales persönliches Konto gefunden, nicht für das Dienstkonto. Dies sollte keine Rolle spielen, wenn Sie den lokalen persönlichen öffentlichen Schlüssel zur Datei mit den autorisierten Schlüsseln des Remote-Dienstkontos hinzugefügt haben.
Ich finde es merkwürdig, dass in den letzten Zeilen nach „Nächste Authentifizierungsmethode: publickey“ die Dateipfadverweise auf „/home/myuserid“ und nicht auf „/home/serviceaccountid“ lauten. Das scheint ein wichtiger Hinweis zu sein.
Das ist SSH, das nach Schlüsseln im lokalen Konto sucht. Es sollte das Home-Verzeichnis des Kontos sein, von dem aus Sie SSH aufrufen. Wenn Sie erwarten, dass dieser Pfad das Home-Verzeichnis eines Dienstkontos ist, müssen Sie sich beim Dienstkonto anmelden undDannFühren Sie SSH aus.