Lösung 1:
Ja, Sie können dies tun, so wie Sie es beschrieben haben.
[email protected] ~$ ssh-add -l 4096 10:b3:fd:29:08:86:24:a6:da:0a:dd:c6:1e:b0:66:6a id_rsa (RSA) [email protected] ~$ ssh [email protected] motd message, etc. [email protected] ~$
Lösung 2:
Es ist ein bisschen nebensächlich, aber.....
Wenn Sie immer denselben Benutzernamen für einen Remote-Server verwenden, finden Sie es möglicherweise auch nützlich, einen Host in Ihre ssh-Konfiguration aufzunehmen:
Host remotesystem
User baruser
Auf diese Weise müssen Sie beim Anmelden nicht daran denken, einen Benutzernamen anzugeben, und Sie schließen dies aus, wenn Sie in Zukunft Probleme mit Schlüsseln haben.
Lösung 3:
Ihr lokaler Benutzername spielt keine Rolle (abgesehen davon, dass sich der private Schlüssel im Home-Verzeichnis Ihres lokalen Benutzers befinden muss). Kopieren Sie einfach den Schlüssel auf authorized_keys des entfernten Benutzers Abschnitt und es wird funktionieren.
Lösung 4:
Bei allen ssh-bezogenen Problemen ist das erste, was zu tun ist, die Ausführlichkeit des Clients zu erhöhen:
ssh [email protected] -vvv
Wenn dies Ihnen keinen Einblick in den Fehler gibt, müssen Sie die Protokollebene auf dem Server ändern und den Daemon neu starten.
LogLevel DEBUG3
Sie sollten die Debug-Ausgabe in /var/log/auth.log finden (oder wo auch immer ssh für die Anmeldung konfiguriert ist). Wenn Sie das Problem gefunden haben, denken Sie daran, es wieder auf den ursprünglichen Zustand zurückzusetzen.
Lösung 5:
Die Berechtigungen für die .ssh-Verzeichnisse auf beiden Maschinen sind wahrscheinlich korrekt. Im Allgemeinen bedeutet dies 700 im .ssh-Verzeichnis und höchstens 755 im Home-Verzeichnis. Zusätzlich zu 600 für alle Dateien in den .ssh-Verzeichnissen.
Wenn der Benutzer auf dem Remote-System root ist, stellen Sie sicher, dass root ssh kann. (PermitRootLogin in sshd_config) und dass der öffentliche Schlüssel (PubkeyAuthentication) und ggf. RSA (RSAAuthentication) aktiviert sind.