Ich habe gestern versucht, mittels mittels ssh und ssh-Schlüssel von der OpnSense aus eine ssh-Verbindung zu meinem TrueNAS (Linux) aufzubauen.
Jedes mal wird nach dem Passwort gefragt.
Sinngemäß "Passwort für opnsense @nas.domain.tld"
Das ssh-Schlüssel habe ich auf der OpnSense ohne Passwort generiert (ssh-keygen -a 100 -t ed25519 -f opnsense @nas.domain.tld). Und das der Kennung auf dem TrueNAS ist es anscheinend auch nicht. An TrueNAS kann es m. E. nicht liegen, dort tun es weitere ssh-Kennungen von meinen anderen Linuxsysteme aus absolut klaglos.
Gibt es da evtl. Besonderheiten auf der Sense bzw. seitens BSD?
Wenn du den Schlüssel mit `-f` an einer anderen Stelle als dem Default speicherst, gibst du beim Versuch, SSH zu benutzen, dann auch diese Datei mit `-i` an?
Im Normalfall lässt du das `-f` komplett weg und `ssh-keygen` speichert den Schlüssel im Homeverzeichnis des Benutzers in `.ssh/id_ed25519` und `.ssh/id_ed25519.pub` - dann wird er beim Aufbau einer Verbindung von der OPNsense aus auch automatisch benutzt.
Quote from: Patrick M. Hausen on October 09, 2024, 02:04:05 PM
Wenn du den Schlüssel mit `-f` an einer anderen Stelle als dem Default speicherst, gibst du beim Versuch, SSH zu benutzen, dann auch diese Datei mit `-i` an?
Im Normalfall lässt du das `-f` komplett weg und `ssh-keygen` speichert den Schlüssel im Homeverzeichnis des Benutzers in `.ssh/id_ed25519` und `.ssh/id_ed25519.pub` - dann wird er beim Aufbau einer Verbindung von der OPNsense aus auch automatisch benutzt.
genau das mache ich "ssh -i opnsense@nas.domain.tld opnsense@nas.domain.tld" (aus ~/.ssh heraus, wo die Schlüssel ordnungsgemäß abgelegt sind)
ssh -v ist dein Freund ;)
Quote from: Patrick M. Hausen on October 09, 2024, 02:15:32 PM
ssh -v ist dein Freund ;)
...und der hat etwas "ausgespuckt":
Ich habe parallel mal in 2 Konsolen ssh -v -i ... aufgerufen.
In beiden Fällen:
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Will attempt key: blakeks@...
ABER: bei der bereits benutzten Kennung:
Authenticated to nas1.bla.kes ([192.168.8.180]:22) using "publickey".
debug1: Server accepts key: >> danach normale ssh-Sitzung
bei der neu angelegten:
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password >> Passwortabfrage
Scheint doch am NAS zu liegen? Die Schlüssel habe ich entsprechend eingetragen, die sind auch in der authorized_keys vorhanden.
Evtl. weiter oben was, dass die lokale SSH auf der Sense den Key nicht benutzen mag? Wenn der Directory-Pfad bis zum Key an irgendeiner Stelle schreibbar und/oder der Key für irgend jemanden außer dem User selbst lesbar sein sollten, sagt die OpenSSH "nö".
Quote from: Patrick M. Hausen on October 09, 2024, 05:46:30 PM
Evtl. weiter oben was, dass die lokale SSH auf der Sense den Key nicht benutzen mag? Wenn der Directory-Pfad bis zum Key an irgendeiner Stelle schreibbar und/oder der Key für irgend jemanden außer dem User selbst lesbar sein sollten, sagt die OpenSSH "nö".
Danke für die Hinweise. Aber es liegt letztlich doch an meinem TrueNAS-System. Das sagt seit gestern zu allen ssh-Benutzern außer dem Admin "nö" >:(
Ich werde daher mit dem Problem im TrueNAS-Forum vorstellig werden...