kann ssh pubkey nicht auf DS kopieren, Permission denied

[wired2051]

Ich habe eine DS420+ mit DSM 7.3.2-86009 Update 3.

Auf einem Kubuntu Linux PC habe ich mit

ssh-keygen

erfolgreich ein Schlüsselpaar erstellt. Beide Dateien liegen in ~/.ssh. Wenn ich das Schlüsselpaar vom PC mit

ssh-copy-id -i ~/.ssh/id_ed25519.pub USER@IP_DER_DS

auf die DS kopieren will, kommt nach der Passwortabfrage die Meldung Permission denied, please try again. Das gleiche Passwort funktioniert mit ssh -p PORT USER@IP_DER_DS problemlos.

In den Systemeinstellungen der DS420+ ist unter Terminal der ssh-Dienst mit Port PORT aktiviert. Telnet ist deaktiviert. USER ist auf der DS in Gruppe administrators.

Was mache ich falsch?

 

[Fusion]

Vielleicht ist das gesperrt.
Kannst mal probieren den Inhalt vom öffentlichen Schlüssel in ~/.ssh/authorized_keys einzufügen, ob du dich dann mit Schlüssel einloggen kannst.

 

[Ronny1978]

@wired2051 Ich gehe anhand deines Textes davon aus, dass der SSH Port nicht bei 22 liegt. Das soll dann aber auch in den ssh-copy-id Befehl, oder?

 

[luddi]

Man kann dem Befehl auch den Port mitgeben mit -p [PORT].

ABER:
Soweit ich mich erinnern kann ist ssh-copy-id nicht Bestandteil des im Synology integrierten OpenSSH Pakets.
Für weitere Details siehe auch die Tutorials von @Tommes und seine Anmerkungen speziell hierzu.
https://github.com/toafez/Tutorials...chkeit-die-verwendung-des-befehls-ssh-copy-id

 

[Tommes]

Wobei @wired2051 den ssh-copy-id Befehl ja von seinem Kubuntu Linux PC in Richtung DS abfeuert. Daher sollte das eigentlich keine Rolle spielen, da meines Wissens nach der ssh-copy-id Befehl nicht auf beiden Systemen vorhanden sein muss.

 

[luddi]

@Tommes du hast recht, ich habe es gerade einmal ausprobiert und es funktioniert.

@wired2051 Wichtig ist, dass es sich bei dem Benutzer um einen Administrator handelt und dass beim Befehl der richtige SSH Port angegeben werden muss falls nicht der Standardport 22 verwendet wird.
Ein "normaler" Benutzer der nicht Teil der Administatorengruppe ist kann sich per Login-Shell nicht via SSH anmelden.

 

[Tommes]

Das waren sehr interessante und vor allem wichtige Hinweise von dir @luddi

 

[wired2051]

In den Systemeinstellungen der DS420+ ist unter Terminal der ssh-Dienst mit Port PORT aktiviert. USER ist auf der DS in Gruppe administrators.

Ich gehe anhand deines Textes davon aus, dass der SSH Port nicht bei 22 liegt. Das soll dann aber auch in den ssh-copy-id Befehl, oder?

Das war's.

ssh-copy-id -i ~/.ssh/SSH_KEY.pub -p PORT USER@IP_DER_DS

Danke für die zahlreiche und geduldige Hilfe!

Zusatzfrage:

Bei der Erstellung mit ssh-keygen habe ich die passphrase leer gelassen. War das ein Fehler? Sollte ich ein neues Schlüsselpaar mit passphrase erstellen?

EDIT:

Back in Time versucht den öffentlichen SSH-Schlüssel zum entfernten Rechner zu kopieren. Warum? Wie kann ich überprüfen, ob ssh-copy-id wirklich erfolgreich war? Der Test mit ssh -i /home/USER/.ssh/id_ed25519 -p PORT 'USERR@IP_DES_NAS' zeigt:

Using terminal commands to modify system configs, execute external binary
files, add files, or install unauthorized third-party apps may lead to system
damages or unexpected behavior, or cause data loss. Make sure you are aware of
the consequences of each command and proceed at your own risk.

Warning: Data should only be stored in shared folders. Data stored elsewhere
may be deleted when the system is updated/restarted.

 

[luddi]

Damit ssh -i /home/USER/.ssh/id_ed25519 -p PORT 'USERR@IP_DES_NAS hast du dich erfolgreich per SSH anmelden können und bist jetzt in der Shell des DSM.

Die Warnung die du siehst ist von Synology so gewählt, gerade deshalb damit man mit dem SSH Login aufpassen soll welche Befehle man ausführt um nicht ausversehen etwas zu zerstören. Sie geben damit die Verantwortung an dich ab und leisten kein Support wenn du hier selbstverschuldet dein System lahmlegen solltest.

Zu deiner Zusatzfrage ob es nun falsch sei eine Schlüsseldatei ohne Passwort zu verwenden ist in meinen Augen eher vergleichbar welcher Religion man angehört. Jeder glaubt eben an andere Dinge und das ist auch gut so. Man sollte niemandem etwas vorschreiben wie er was zu machen hat.

Aber zurück zu deiner Frage die ich gerne auch aus technischer Sicht beantworte.
Die Sicherheitsstufe erhöht sich mit zusätzlichem Passwort zum alleinigen Schlüssel. Wenn du den Schlüssel nicht verlierst oder niemand weiß wo dieser Schlüssel hinzugehört ist das Risiko aus meiner Sicht auch gering.
Es gibt Szenarien da is ein zusätliches Passwort eher hinderlich, gerade dann wenn man z.B. automatisierte Aufgaben ausführt die auf einen entfernten Server zugreifen müssen wie es bei einem Backup der Fall ist.

Ich persönlich rate selbst immer zu höchster Sicherheitsstufe wenn möglich, anderenfalls für automatisierte Tasks muss man eben diese Ausnahmen hinnehmen.

Da du den Public Key bereits hochgeladen hast bist du aber nicht gezwungen ein neues Schlüsselpaar zu erzeugen denn allein der private Schlüssel kann mit einem Passwort versehen werden. Dies kann auch nachträglich immer wieder geändert werden.
Lass den Public Key so wie er ist auf dem NAS und aktualisiere den privaten Schlüssel auf deinem Host und vergib ein Passwort.

ssh-keygen -p -f /home/USER/.ssh/id_ed25519

• -p Requests changing the passphrase of a private key file instead of creating a new private key. The program will prompt for
  the file containing the private key, for the old passphrase, and twice for the new passphrase.
  
  
• -f filename
  Specifies the filename of the key file.

 

[Ronny1978]

Eine Alternative wäre, weiß aber nicht genau, ob das auch bei Synology funktioniert, einen SSH Key mittels Yubikey zu erstellen. Den SSH Key habe ich in meinem KeepassXC und der stellt diesen dann dem SSH Agent zur Verfügung. Beim Einloggen mit Public Key auf meinen Ubuntu und Debian Server brauche ich zwingend den Yubikey. Ein Passwort ist in der SSH config nicht mehr erlaubt. Damit ist der Key nicht mehr auf meinen Rechner, sondern nur noch im Passwortmanager. Dann braucht es auch keine Passphrase, weil ich immer noch den Yubikey "befummeln" muss, bevor der Login funktioniert.

https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html

 

[wired2051]

Lass den Public Key so wie er ist auf dem NAS und aktualisiere den privaten Schlüssel auf deinem Host und vergib ein Passwort.

Danke!

Noch eine grundsätzliche Frage: lieber ein langes Passworet mit 20+ zufälligen Zeichen (mit Passwort Manager) oder ein kürzeres, dass man sich merken kann? Oder ist das auch eine Glaubensfrage?

 

[luddi]

Ich würde immer zu Passwörtern mit hoher Entropie raten. Länge vor “Sonderzeichen-Akrobatik”. Ein langes Passwort mit 20+ Zeichen ohne Sonderzeichen ist oft besser als ein Passwort mit 8 Zeichen und Sonderzeichen.
Und wenn du bereits ein Passwort Manager verwendest rate ich ohnehin gewürfelte lange Passwörter zu verwenden.

 

[Ronny1978]

langes Passworet mit 20+ zufälligen Zeichen

Hier stimme ich @luddi zu. Hier gilt mal: "Es kommt auf die Länge an". Und vielleicht dennoch einmal über Yubikey informieren. Der SSH Login mittels Yubikey halte ich für sehr sicher, weil ja auch der physische Stick am Rechner, von dem man sich einloggen möchte, dran sein muss. Und wenn der Public Key dann noch aus dem Passwortmanager kommt, geht es meiner Meinung nach, nicht viel sicherer, oder was meinen die anderen?

Für die, die dennoch nicht zufrieden sind, lässt sich auch bei einem SSH Key mittels Yubikey eine Passphrase erstellen. Aber hier zielt man, meiner Meinung schon mit 3 Panzern auf einen Spatz.

 

[Tommes]

Wobei man hier auch immer die Verhältnismäßigkeit betrachten sollte. Mir persönlich reicht in meinem lokalen Netzwerk ohne Verbindung von außen bzw. nur über VPN ein RSA-Key ohne Passphrase vollkommen aus. Auch lasse ich regelmäßig ein automatisiertes „rsync over SSH“ Skript laufen um eine Sicherung von bzw. auf einem Remoteserver durchzuführen.

Anderseits wollte ich mir schon immer mal so einen bzw. Yubikeys kaufen, hab das bisher aber immer auf die lange Bank geschoben.

 

[Ronny1978]

Hallo Tommes,

danke für deine Rückinfo.

hab das bisher aber immer auf die lange Bank geschoben

, ja preiswert sind die nicht. Aber ich habe mittlerweile für meine Familie (Frau, 2 Jungs und ich) jeweils 2 Stück von 5er Serie (jeweils 1x USB-A und 1x USB-C). Wir nutzen die Dinger mittlerweile für fast alles:

- Absicherung der KeepassXC Hauptdatenbank (Pflege der Datenbank durch mich)
- als Passkey, wo es nur geht (Google, Microsoft, Amazon, Github, Paypal usw.)
- als Security Key (DS918, diverse Foren, usw.)
- als 2FA Generator für alles mögliche (Home Assistant, Web.de, Anydesk, Crowdsec, Deutsche Bank, Dropbox, Ebay, und diverse Spieleportale, EA, Ubisoft usw.)

automatisiertes „rsync over SSH“ Skript

Hier wird der Yubikey natürlich nicht funktioniert. Aber für den SSH Login für meine 2 VM Server (Ubuntu und Debian auf Proxmox) funktioniert das wunderbar. Ich musste etwas probieren, bin aber begeistert. Den P-Key habe ich selbst nur im KeepassXC. Beim SSH Login muss die Datenbank entsperrt sein und übergibt den Public Key an den SSH Agent (muss aber als Dienst OpenSSH in Windows gestartet sein - ist kein Standard) weiter. Da muss der Yubikey noch berührt werden. Passwort beim SSH Login ist keines mehr erlaubt. Also ich halte das für sehr sicher - musste aber, wie gesagt, etwas probieren, bis die Lösung funktioniert hat bzw. bis ich wusste wo ich was eingeben muss. Wenn man dann noch eine Passphrase festlegt, ist das Ding kaum noch knackbar, oder?

Also ich kann es nur empfehlen. Es gibt mittlerweile auch andere Stick, aber von der Bedienung (USB, App für PC/Smartphone und NFC) und vom Funktionsumfang, halte ich die Yubikey für fast unschlagbar.