kann ssh pubkey nicht auf DS kopieren, Permission denied

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

wired2051

Benutzer
Registriert
17. März 2010
Beiträge
960
Reaktionspunkte
13
Punkte
44
Ich habe eine DS420+ mit DSM 7.3.2-86009 Update 3.

Auf einem Kubuntu Linux PC habe ich mit
Code:
ssh-keygen
erfolgreich ein Schlüsselpaar erstellt. Beide Dateien liegen in ~/.ssh. Wenn ich das Schlüsselpaar vom PC mit
Code:
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?
 
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.
 
@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?
 
  • Like
Reaktionen: Rotbart
  • Like
Reaktionen: Ronny1978
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.
 
  • Like
Reaktionen: 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.
 
  • Like
Reaktionen: Tommes
Das waren sehr interessante und vor allem wichtige Hinweise von dir @luddi
 
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.
Code:
ssh-copy-id -i ~/.ssh/SSH_KEY.pub -p PORT USER@IP_DER_DS

Danke für die zahlreiche und geduldige Hilfe! (y)

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.
 
Zuletzt bearbeitet:
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.

Bash:
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.
 
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
 
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?
 
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.
 

Additional post fields

 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat