SFTP Zugang mittels SSH Keys

[myrztA]

Hi,

nach einem halben Tag herumprobieren und endlos Anleitungen lesen, zweifle ich inzwischen ein bisschen an mir.

Mein Backup Tool hat ein SFTP Backend welches ich gerne mit meiner DiskStation (DSM 7.1.1) nutzen möchte und das klappt auch solange ich mein Passwort nach Aufforderung angebe. Jetzt hätte ich das gerne auf SSH Keys umgestellt aber hier komme ich einfach nicht weiter.

Für meinen admin Account habe ich es hinbekommen, den SSH/SFTP Zugang mittels Schlüsseltausch ohne Passworteingabe hinzubekommen. Aber für andere Nutzer klappt das einfach nicht.

Ich stelle mir jetzt die Frage: Ist das eine allgemeine Beschränkung bei Synology/DSM, dass nur der admin SSH/SFTP Zugang hat? Irgendwelche andere Ideen wie ich das noch Debuggen könnte?

Rein prinzipiell liegt im "~nutzer/.ssh/authorized_keys" der id_rsa.pub vom lokalen Nutzer und ich hatte mittels Adminzugang per SSH "chmod 700 ~nutzer/.ssh" ausgeführt. Muss die Datei eventuell noch einen speziellen Owner/Group haben? Mehr geben die üblichen Anleitungen eigentlich alle nicht her was man machen sollte.

Vielen Dank schonmal für alle Anregungen!

 

[Hagen2000]

Ist das eine allgemeine Beschränkung bei Synology/DSM, dass nur der admin SSH/SFTP Zugang hat?

Ja - nur Benutzer der Gruppe "administrators" dürfen diese Dienste nutzen.
Edit: Die Aussage gilt für SSH und Telnet, nicht für SFTP, siehe #4.

 

[myrztA]

Das war mir schon mal neu, vielen Dank! Ich hab den Nutzer jetzt auch mal in der Weboberfläche in die Gruppe hinzugefügt, aber das scheint nichts am Problem geändert zu haben.

$ id backup
uid=1029(backup) gid=100(users) groups=100(users),101(administrators)

admin funktioniert weiterhin reibungslos.

  /sudo:root@IP:/volume1/homes/backup/.ssh:
  -rwx------ 1 root users 725 authorized_keys

 

[Hagen2000]

Ich möchte mich korrigieren: Die Beschränkung auf die Gruppe "administrators" gilt nur für SSH und Telnet, SFTP kann auch für normale Benutzer erlaubt und verwendet werden, habe ich gerade getestet.

 

[Hagen2000]

Schau mal bei Benutzern unter "Anwendungen", ob dort die Einstellungen für SFTP stimmen.
Außerdem solltest Du den Eigentümer vom Verzeichnis .ssh sowie der darin enthaltenen Dateien auf den entsprechenden Benutzer und dessen Gruppe stellen.
Edit: Und Zugriffsrechte sollten auf "-rw" stehen: chmod 600 /volume1/homes/backup/.ssh/authorized_keys
Edit 2: Bei Dir müsste das so passen: chmod -R backup:users /volume1/homes/backup/.ssh

 

[Benares]

Schau mal bei den Benutzereinstellungen unter "Anwendungen", ob backup SFTP darf.
Bei mir gehört SFTP zu den Anwendungen, die fast jeder darf (Systemsteuerung, Anwendungsberechtigungen)

Edit: @Hagen2000 war schneller.

 

[myrztA]

Ja, das Häckchen bei SFTP ist gesetzt. Ich hab auch nochmal die Ownership angepasst: backup users (das hatte ich vorher auch schon mal probiert). Leider alles beim Alten.

Edit: Gibt es vielleicht auf DSM Seite irgendwo einen aussagekräftigen Log wo man den Grund finden könnte warum das authorized_keys nicht genutzt wird oder so?

 

[Hagen2000]

Habe gerade mal mit einem normalen Benutzer den SFTP-Zugang mit Public-Key-Verfahren getestet: Funktioniert bei mir.

 

[Hagen2000]

Kritisch sind eigentlich die Zugriffsrechte auf den .ssh-Ordner auf der Client-Seite sowie Eigentümer und Zugriffsrechte des privaten Schlüssels. Einige ssh-Clients prüfen die Rechte besonders genau und verwenden den privaten Schlüssel nur, falls er genügend geschützt ist.
Vielleicht hilft Dir ein auf der Kommandozeile gestarteter sftp-Client mit Option -v weiter.

 

[myrztA]

Mit Client-Seite meinst du die Diskstation? Ich bin mir eigentlich ziemlich sicher, dass ich da inzwischen so ziemlich alle möglichen Permutationen an Zugriffsrechten und Eigentümern durchhabe, aber vielleicht schaue ich dann später nochmal rein.

Ich teste das gerade mit ssh -vvvv (...) -s sftp. Die Ausgabe war da bisher nicht sehr aufschlussreich.

(...)
debug2: pubkey_prepare: done
debug1: Offering public key: /home/<nutzer>/.ssh/id_rsa RSA SHA256:<SHA>
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
(...)

Sieht für mich als ob der lokale pub key erfolgreich angeboten wird (macht ja auch Sinn nachdem es mit admin klappt), aber das scheint von der Diskstation abgelehnt zu werden.[/CODE]

 

[Hagen2000]

Nein, mit „Client“ meine ich die Seite, auf der dein Backup-Tool läuft. Die DiskStation hat ja den öffentlichen Schlüssel, der ist ja ohnehin nicht geheim.

Edit: Ein bisschen merkwürdig ist die Zeile
debug1: Offering public key: /home/..., an der entsprechenden Stelle steht bei mir Folgendes:
debug1: Trying private key: /Users/<user>/.ssh/id_rsa, was irgendwie mehr Sinn macht, aber das liegt vielleicht nur am ssh-Client (hier macOS).

 

[myrztA]

Es hat geklappt!

Ich hab jetzt nochmal nachgeforscht und bin über diesen interessanten Blogbeitrag gestolpert: https://blog.aaronlenoir.com/2018/05/06/ssh-into-synology-nas-with-ssh-key/

Das hat mir wirklich weitergeholfen, insbesondere der Tipp einen ein SSH Instanz auf der DS zu starten zum Debuggen:

sudo /bin/sshd -d -p 1234

Dann lokal mit sftp -P 1234 backup@<IP> verbinden und den Fehlerbericht studieren, und siehe da:

debug1: trying public key file /var/services/homes/backup/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /volume1/homes/backup

Das Problem war wohl, dass ich stets versucht habe die Zugriffsrechte auf ".ssh" und "authorized_keys" anzupassen, aber nie von homes/backup. Einmal darauf chmod 755 <nutzer> ausgeführt und schon ging es...

Vielen Dank für die Mithilfe, trotzdem!

 

[Benares]

Das Problem war wohl, dass ich stets versucht habe die Zugriffsrechte auf ".ssh" und "authorized_keys" anzupassen, aber nie von homes/backup. Einmal darauf chmod 755 <nutzer> ausgeführt und schon ging es...

Es ist aber immer gefährlich, innerhalb der Rechtestruktur von homes mit chmod rumzupfuschen, Die verwaltet eigentlich der Benutzer-Home-Dienst und setzt dabei auf ACLs. Die ist recht eigen und man muss sie verstanden haben. Leg dir lieber einen eigenen "Freigegeben Ordner" für deine Backups an.

 

[myrztA]

Es ist aber immer gefährlich, innerhalb der Rechtestruktur von homes mit chmod rumzupfuschen, Die verwaltet eigentlich der Benutzer-Home-Dienst und setzt dabei auf ACLs. Die ist recht eigen und man muss sie verstanden haben.

Ich hab gerade nochmal nachgeschaut und außer admin scheinen alle anderen Nutzer die volle Pallette an Zugriffsrechten zu gewähren. Ich schätze mal, da war - wie auch immer - früheren Experimenten etwas schief gelaufen bei "backup". Ich hab das jetzt mal bei backup noch angeglichen und hoffe auf das Beste

Leg dir lieber einen eigenen "Freigegeben Ordner" für deine Backups an.

Wie meinst du das? Auf den würde ich ja wieder nicht ohne SFTP Zugang kommen?

 

[Benares]

Ich meinte eigentlich nur einen eigenen "Freigegeben Order" "backups" z.B., außerhalb des homes-Bereiches. An dessen Rechten kannst du dann nach Herzenslust herumpfuschen, ohne die Rechte-Struktur des homes-Bereiches zu beeinflussen. Auch darauf kommst du mit SFTP drauf, wieso nicht?

 

[Hagen2000]

Schöne Fehlersuche!

Auf meinem NAS haben alle Benutzerordner die Rechte 711, wenn ich sie als root (sudo …) betrachte. Betrachtet man die Benutzerordner ohne Root-Rechte, so werden hier wohl die Gruppenrechte über die ACLs verrechnet und es sieht so aus, als ob alle Verzeichnisse auf 777 stehen würden. Ein ls -le liefert mehr Details, aber so tief bin ich in der Materie auch nicht drin.

Alle meine Benutzer wurden übrigens über die Benutzerverwaltung vom NAS selbst angelegt. Wie hattest Du denn deinen Benutzer backup erstellt?

 

[Benares]

Mein Backup-Ordner sieht mit "ls -als" z.B. so aus:

     0 drwxrwx---+  1 root           root                 114 May  8  2024 backup

Das + sagt mir, dass es neben den Linux-Rechten noch ACL-Rechte (Access Control List) gibt, alle Rechte sieht man dann mit

root@DS1522:/volume1# synoacltool -get /volume1/backup
ACL version: 1
Archive: has_ACL,is_support_ACL
Owner: [root(user)]
---------------------
         [0] system::allow:rwxp--aARWc--:fd-- (level:0)
         [1] user:ActiveBackup:allow:rwxpdDaARWc--:fd-- (level:0)
         [2] group:boxusers:allow:r-x---a-R-c--:fd-- (level:0)
         [3] group:boxadmins:allow:rwxpdDaARWc--:fd-- (level:0)
         [4] group:administrators:allow:rwxpdDaARWc--:fd-- (level:0)

An Ordnern mit ACL-Rechten sollte man nicht mit chmod rumpfuschen, das zerstört die ACL.

Edit: @Hagen2000, stimmt "ls -le" zeigt das auch, das kannte ich nicht. Again what learned