[erledigt] - problem mit ssh

[kruemelmonster]

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?

[Patrick M. Hausen]

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.

[kruemelmonster]

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)

[Patrick M. Hausen]

ssh -v ist dein Freund 

[kruemelmonster]

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.

[Patrick M. Hausen]

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ö". 

[kruemelmonster]

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...