Kann ich die SSH-Schlüsselauthentifizierung verwenden, um mich bei einem Remote-System mit einem anderen Benutzernamen anzumelden?

Angenommen, ich habe ein Remote-System mit dem Namen "Remote-System" und ein Benutzerkonto "Foouser" auf diesem System.

Ich weiß, dass ich auf meinem lokalen System ein SSH-Schlüsselpaar als lokaler Benutzer "foouser" generieren kann und den öffentlichen Schlüssel in der Datei "/home/foouser/.ssh/authorized_keys" auf "remotesystem" ablegen kann. Wenn ich als "foouser" von meinem lokalen System zu "remotesystem" eine SSH-Verbindung herstelle, verwendet SSH das Schlüsselpaar, um mich zu authentifizieren.

Aber was ist, wenn mein lokaler Benutzername nicht mit dem Benutzernamen auf dem Remote-System übereinstimmt? Das heißt, was ist, wenn ich als lokaler Benutzer "baruser" zu "remotesystem" SSH wollen? Natürlich muss ich ein Schlüsselpaar für "baruser" generieren und den öffentlichen Schlüssel zu "/home/foouser/.ssh/authorized_keys" hinzufügen. Dann sollte ich in der Lage sein, "ssh foouser @ remotesystem" zu verwenden, während ich lokal als "baruser" angemeldet bin, und SSH wird das Schlüsselpaar zur Authentifizierung verwenden, oder?

Ich frage, weil ich in diesem Szenario erfolglos versuche, die Schlüsselauthentifizierung zum Laufen zu bringen. Ich bin mir nicht sicher, ob dies an der Nichtübereinstimmung des Benutzernamens oder an einem Konfigurationsproblem mit dem SSH-Server auf dem Remote-System liegt.

Ja, Sie können dies so tun, wie Sie es beschrieben haben.

baruser @ here ~ $ ssh-add -l
4096 10: b3: fd: 29: 08: 86: 24: a6: da: 0a: dd: c6: 1e: b0: 66: 6a id_rsa (RSA)
baruser @ here ~ $ ssh foouser @ remotesystem
motd nachricht, etc.
foouser @ remotesystem ~ $

Es ist ein bisschen abseits, aber .....

Wenn Sie für einen Remote-Server immer denselben Benutzernamen verwenden, ist es möglicherweise auch hilfreich, einen Host in Ihre ssh-Konfiguration aufzunehmen:

Host remotesystem
    User baruser

Auf diese Weise müssen Sie sich beim Anmelden nicht mehr an den Benutzernamen erinnern und schließen diesen aus, wenn Sie in Zukunft Probleme mit Schlüsseln haben.

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 in den Bereich des Remote-Benutzers, authorized_keysund es wird funktionieren.

Bei Problemen mit ssh müssen Sie zunächst die Ausführlichkeit des Clients erhöhen:

ssh user @ machine -vvv

Wenn Sie dadurch keinen Einblick in die Fehlerursache erhalten, müssen Sie die Protokollebene auf dem Server ändern und den Dämon neu starten.

LogLevel DEBUG3

Sie sollten die Debug-Ausgabe in /var/log/auth.log finden (oder wo immer ssh konfiguriert ist, um sich anzumelden). Denken Sie daran, das Problem wieder so einzustellen, wie Sie es gefunden haben.

Die Berechtigungen für die .ssh-Verzeichnisse auf beiden Computern sind weitgehend korrekt. Im Allgemeinen bedeutet dies 700 im Verzeichnis .ssh und höchstens 755 im Basisverzeichnis. Zusätzlich zu 600 für alle Dateien in den .ssh-Verzeichnissen.

Wenn der Benutzer auf dem fernen System root ist, stellen Sie sicher, dass root ssh kann. (PermitRootLogin in sshd_config) und dieser öffentliche Schlüssel (PubkeyAuthentication) und ggf. RSA (RSAAuthentication) sind aktiviert.

Wenn Sie SE Linux aktiviert haben, müssen Sie auch Folgendes tun.

Fügen Sie das SELinux-Label hinzu, authorized_keysdamit sshd darauf zugreifen kann.

semanage fcontext -a -t sshd_key_t ~foo/.ssh/authorized_keys
restorecon -Rv ~user/.ssh

Klingt so, als würden Sie alles richtig machen, aber stellen Sie sicher, dass die Berechtigungen für authorized_keys korrekt sind. Sie sollten auf 600 eingestellt sein.