Seit DSM 6.2.2 haben wir als Nicht-Administrator Probleme, uns über SSH mit einem Synology NAS zu verbinden. Zuvor war dies möglich, indem man einfach die Login-Shell /etc/passwdvon /sbin/nologinin änderte /bin/sh. Dies scheint nicht mehr zu funktionieren.
Ich habe zusätzlich versucht, /etc/ssh/sshd_confexplizit zu bearbeiten AllowUsers, aber ohne Erfolg. Es scheint, dass der Client eine erfolgreiche Authentifizierung durchführt, aber dann beendet irgendein PAM-Modul(?) die Verbindung wieder.
Funktioniert bei irgendjemandem SSH als Nicht-Administrator unter der neuesten Version von DSM?
Dies ist die Protokollausgabe:
2019-05-23T21:55:36+02:00 hostname sshd[13551]: pam_unix(sshd:session): session opened for user test by (uid=0)
2019-05-23T21:55:36+02:00 hostname sshd[13551]: pam_unix(sshd:session): session closed for user test
Antwort1
Auf DiskStations mit Docker fand ich es am einfachsten, einen OpenSSH-Container zu verwenden. Ich habe mich für entschieden linuxserver/openssh-server. Auf diese Weise kann ich nur die relevanten Daten in den Container mounten und muss mich nicht mit den Konfigurationen von Synology herumschlagen.
Antwort2
Dies ist eine Lösung für das Problem, dass Sie sich nicht über SSH bei Synology NAS anmelden können, es sei denn, Sie sind Mitglied der Administratorengruppe. Aus mehreren Online-Beiträgen zu diesem Thema geht hervor, dass dieses Problem in DSM 6.2.x vorhanden ist.
Es gibt viele gute Gründe, warum einem Benutzer SSH-Zugriff gewährt werden könnte. Gleichzeitig benötigt nicht jeder Benutzer Administratorzugriff. Daher scheint Synology Inc. eine schlechte Entscheidung getroffen zu haben, diese Regel durchzusetzen. Ich habe keine Möglichkeit gefunden, dies mit dem Standard-SSHD zu beheben, also habe ich mein eigenes SSHD kompiliert.
Ich übernehme keine Verantwortung, wenn Sie Ihren Kaffee verschütten, auf Ihrem Stuhl stolpern und auf Ihre Katze fallen oder durch diese Anleitung anderweitig Schaden nehmen. Seit Oktober 2019 ist jedoch alles in meinem Labor auf Funktionsfähigkeit getestet.
Lasst uns beginnen.
System, auf dem dies getestet wurde:
Synology DS418j with DSM 6.2.2-24922 Update 3, Linux hostname 4.4.59+
#24922 aarch64 GNU/Linux synology_rtd1296_ds418j
Qubes release 4.0 (R4.0) with an App-VM running Fedora release 30 (Thirty)
Voraussetzungen:
- Auf ein Synology NAS können Sie mit einem bestehenden Benutzer, der zur Administratorgruppe gehört, per SSH zugreifen.
- Eine Linux-Umgebung könnte virtualisiert werden. Auf einem Mac sollte ein Systemterminal genügen. Um meinem Beispiel wörtlich zu folgen, installieren Sie Fedora 30. Wenn Sie Ubuntu verwenden, müssen Sie zumindest apt-get statt dnf verwenden, es kann auch andere distributionsspezifische Elemente geben.
Achtung, wenn Sie es gewohnt sind, bei der Installation von Linux-Software „make install“ zu verwenden. Tun Sie dies nicht, wenn Sie dieser Anleitung folgen, es sei denn, Sie wissen, was Sie tun, und weichen von der Anleitung ab. Wenn Sie dies tun, könnte Ihr System beschädigt werden. Außerdem müssen Sie aus Sicht des kompilierenden Hosts beim Arbeiten an dieser Anleitung nur ein gewöhnlicher Benutzer sein. Nur gelegentlich ist sudo erforderlich.
Wenn Sie aus irgendeinem Grund Ihren SSH-Daemon beschädigen, können Sie außerdem immer Telnet über die DSM-Web-Benutzeroberfläche aktivieren und sich über Telnet mit der Synology-Befehlszeilenschnittstelle verbinden, um Ihren Fehler zu beheben. Außerdem ist es ratsam, sich alles zu notieren, was Sie tun, und alle Dateien, die Sie ersetzen und ändern, vorher zu sichern. Beachten Sie: Wenn Sie diese Anleitung befolgen, mit einem entfernten Synology-Server arbeiten und sich nicht ganz sicher sind, was Sie tun, besteht die Gefahr, dass Sie sich selbst aus dem Server aussperren. Stellen Sie zumindest sicher, dass Sie einen Ausgang haben, z. B. einen Administrator vor Ort, der Ihnen den Zugriff wiederherstellen könnte.
Im weiteren Verlauf des Handbuchs werden die Begriffe Synology und DS (Disk Station) synonym verwendet.
Da Synology Inc. anscheinend die ursprüngliche SSHD-Binärdatei geändert hat, erfahren Sie in diesem Handbuch, wie Sie eine SSHD-Binärdatei hinzufügen, die Benutzern außerhalb der Administratorgruppe SSH-Zugriff auf die Synology-Box gewährt.
Interessanterweise ist eine sogenannte Cross-Kompilierung möglich. Das bedeutet, dass Sie Software auf einer Plattform kompilieren können, die auf einer anderen Plattform ausgeführt werden kann.
Der Quellcode für OpenSSH ist verfügbar, ebenso wie seine Abhängigkeiten. Das bedeutet, dass wir ihn auf einem Linux-System kompilieren und auf einer Synology mit einer ARM-CPU ausführen können.
Verschaffen Sie sich zunächst Zugriff auf eine Linux-Maschine. Wenn Sie Linux nicht installiert haben, laden Sie Virtualisierungssoftware wie VMware oder Virtualbox herunter und installieren oder laden Sie eine virtuelle Linux-Maschine. Möglicherweise funktioniert es auch mit Cygwin als Subsystem in Windows. Lesen Sie hierzu die entsprechende Dokumentation.
Bitte beachten Sie, dass bestimmte Elemente dieser Anleitung möglicherweise nicht zu Ihren individuellen Umständen passen. Passen Sie Ihre Vorgehensweise in dieser Anleitung entsprechend an. Diese Anleitung sollte Ihnen einige Hinweise zur Behebung des SSH-Problems geben, auch wenn Sie nicht genau dasselbe Setup wie ich haben.
Finden Sie zunächst heraus, welchen Prozessor Ihr DS hat.
Finden Sie hier Ihr spezifisches Synology-Modell:https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Compatibility_Peripherals/What_kind_of_CPU_does_my_NAS_have
Überprüfen Sie auch eine SSH-Sitzung auf Ihrem Synology-Terminal, uname -a sollte Ihnen einige Hinweise geben.
In meinem Fall zeigen sowohl der Link zum Synology Support Center als auch die Ausgabe von uname -a, dass ich eine Realtek RTD1293 CPU habe. Es handelt sich um einen ARM-Prozessor. Weitere interessante Informationen finden Sie unterhttps://en.wikichip.org/wiki/arm/aarch64
Also müssen wir die Quellen besorgen und sie auf dem Linux-Laptop plattformübergreifend kompilieren, damit wir die Binärdatei per SCP an Synology senden und die Anmeldebeschränkung umgehen können.
Bevor Sie fortfahren, überprüfen Sie, ob Sie per SSH auf Ihre Synology zugreifen können. Wenn Ihr SSH-Fu stark ist, haben Sie möglicherweise einen Eintrag in Ihrer ~/.ssh/config eingerichtet, der wie folgt aussieht:
#My synology
Host DS
Port 22
Hostname 192.168.10.100
User localuser
IdentityFile /home/localuser/.ssh/id_ed25519
Ersetzen Sie Variablen durch alles, was Ihre lokale Situation erfordert.
Zumindest sollten Sie sich bei Ihrer Synology anmelden können, indem Sie einen Befehl wie ssh ausführen.[email geschützt]. Wenn Sie eine nicht standardmäßige Identitätsdatei oder einen nicht standardmäßigen Port haben, fügen Sie diese Parameter hinzu. Die Konfiguration von passwortlosem SSH geht über den Rahmen dieses Handbuchs hinaus. Beachten Sie, dass Synology auch bei den Berechtigungen für alle Dateien und Verzeichnisse eines Benutzers sehr pingelig ist, bevor die SSH-Anmeldung zugelassen wird. Es gibt viele Beiträge online dazu. Sie können jedoch auch mit der Anmeldung per Passwort fortfahren, aber wenn Sie sich in einem lokalen Netzwerk befinden und private Endverbrauchergeräte verwenden, ist es bequemer, SSH-Schlüssel für die Anmeldung bei SSH zu verwenden. Sie können auch Passphrasen für Ihre privaten Schlüssel verwenden. Überprüfen Sie auch, ob Sie „sudo whoami“ ausführen können, wenn Sie mit Ihrem bestehenden Benutzer angemeldet sind. Dies sollte Sie zur Eingabe Ihres Sudo-Passworts auffordern, es sei denn, Sie haben Sudo so konfiguriert, dass kein Passwort für Ihren Benutzer erforderlich ist, und nach dem Drücken der Eingabetaste wird „root“ angezeigt.
Jetzt kommt der spaßige Teil!!
Melden Sie sich bei Ihrer Linux-Instanz (Fedora?) an, starten Sie ein Terminal, erstellen Sie ein Projektverzeichnis und geben Sie es ein.
mkdir ~/crosscompile ; cd ~/crosscompile
Verwenden Sie einen Webbrowser in Ihrer Linux-Instanz und gehen Sie zuhttps://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/, die neueste Version finden Sie unten. Pr. Okt. 2019, das ist openssh-8.1p1.
Gehen Sie zurück zum Linux-Terminal und laden Sie es herunter. Ich verwende 8.1p1, aber verwenden Sie bitte die neuere Version, wenn Sie diese Anleitung sehen, wenn eine neue Version veröffentlicht wurde.
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz.asc
Die zweite Zeile erhält die PGP-Signatur der Datei.
Installieren Sie jetzt pgpdump, sofern es noch nicht installiert ist:
sudo dnf install pgpdump
Fortfahren mit
pgpdump openssh-8.1p1.tar.gz.asc
Beispielausgabe:
Old: Signature Packet(tag 2)(451 bytes)
Ver 4 - new
Sig type - Signature of a binary document(0x00).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA512(hash 10)
Hashed Sub: issuer fingerprint(sub 33)(21 bytes)
v4 - Fingerprint - 59 c2 11 8e d2 06 d9 27 e6 67 eb e3 d3 e5 f5 6b 6d 92 0d 30
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Wed Oct 9 02:39:36 CEST 2019
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0xD3E5F56B6D920D30
Hash left 2 bytes - 1c 52
RSA m^d mod n(3195 bits) - ...
-> PKCS-1
Notieren Sie sich die Schlüssel-ID 0xD3E5F56B6D920D30 (bei einer neueren Version kann sie anders sein). Notieren Sie sich auch den Fingerabdruck, wir kommen darauf zurück.
Installieren Sie jetzt gpg2, falls es nicht installiert ist.
sudo dnf install gpg2.
Holen Sie sich den PGP-Schlüssel vom Releaser:
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/DJM-GPG-KEY.asc
Importieren:
gpg2 --import DJM-GPG-KEY.asc
Holen Sie sich den Release-Schlüssel und importieren Sie ihn:
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc
gpg2 --import RELEASE_KEY.asc
Überprüfen Sie nun den Download:
gpg2 --verify openssh-8.1p1.tar.gz.asc openssh-8.1p1.tar.gz
Ergebnis:
gpg: Signature made Wed Oct 9 02:39:36 2019 CEST
gpg: using RSA key 59C2118ED206D927E667EBE3D3E5F56B6D920D30
gpg: Good signature from "Damien Miller <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30
Beachten Sie, dass der Fingerabdruck mit dem übereinstimmt, was pgpdump uns anhand der PGP-Signatur mitgeteilt hat. Alles sieht gut aus. Wenn Sie befürchten, dass der Schlüssel durch eine Signatur nicht als vertrauenswürdig eingestuft wird, müssen Sie die Vertrauenswürdigkeit des Schlüssels entweder selbst bearbeiten oder jemanden damit beauftragen. Wenn Sie eine sehr kritische Installation haben, können Sie Damien Miller kontaktieren und ihn den Fingerabdruck auslesen lassen. Dafür sollten Sie ihn wahrscheinlich entschädigen!
Um sicherzustellen, dass der Download so sicher wie möglich ist, sollten Sie ihn trotzdem bei mehreren Quellen überprüfen. Versuchen wir es also.
Eine schnelle Suche zeigt, dass es sich offenbar um Millers Blog handelt. Und dieser Beitrag enthält weitere Einzelheiten:
http://blog.djm.net.au/2013/12/pgp-keys-rotated.html
Kopieren Sie nun den gesamten Schlüssel-Blob in eine Datei auf der Festplatte und führen Sie dann einen „pgpdump filename“ darauf aus.
Sie sollten eine Ausgabe wie diese erhalten:
pgpdump keyblob | grep 0D30 | grep fin
Key fingerprint = 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30
Wenn Sie neugierig sind, kopieren Sie die gesamte Ausgabe des Befehls in einen Texteditor und suchen Sie nach „0xD3E5F56B6D920D30“, wie weiter oben im Handbuch beschrieben. Sie werden dann sehen, dass der Release-Schlüssel ein Unterschlüssel von Millers persönlichem Schlüssel ist.
Ok, an diesem Punkt gehen wir davon aus, dass der OpenSSH-Download fehlerfrei war.
OpenSSH entpacken:
tar xvzf openssh-8.1p1.tar.gz
Sie müssen bestimmen, welche Toolchain Sie benötigen:https://originhelp.synology.com/developer-guide/compile_applications/download_dsm_tool_chain.html
In meinem Fall habe ich die benötigte Version mit diesem Befehl heruntergeladen:
wget https://sourceforge.net/projects/dsgpl/files/DSM%206.2.2%20Tool%20Chains/Realtek%20RTD129x%20Linux%204.4.59/rtd1296-gcc494_glibc220_armv8-GPL.txz/download -O rtd1296-gcc494_glibc220_armv8-GPL.txz
Soweit ich weiß, gibt es keine Möglichkeit, den Download zu verifizieren. Ich habe ihn auf Virustotal hochgeladen und es wurden keine Engines gefunden.
Extrahieren Sie die Toolchain:
sudo tar Jxvf rtd1296-gcc494_glibc220_armv8-GPL.txz -C /usr/local
Zusätzlich benötigen wir zlib und openssl.
wget https://zlib.net/zlib-1.2.11.tar.gz
wget https://zlib.net/zlib-1.2.11.tar.gz.asc
(Auch hier nach neuerer Version suchen)
pgpdump zlib-1.2.11.tar.gz.asc | grep ID
gibt Schlüssel-ID - 0x783FCD8E58BCAFBA
Holen und importieren Sie es:
wget http://pgp.key-server.io/download/0x783FCD8E58BCAFBA
gpg2 --import 0x783FCD8E58BCAFBA
Überprüfen Sie den Download:
gpg2 --verify zlib-1.2.11.tar.gz.asc zlib-1.2.11.tar.gz
Dies dürfte eine gelungene Signatur von Mark Adler ergeben[email geschützt]
An diesem Punkt können Sie den Fingerabdruck oder den DSA-Schlüssel verwenden, um zu versuchen, an anderen Stellen im Web Referenzen zu finden, wenn Sie eine weitere Überprüfung benötigen.
Extract zlib: tar xvzf zlib-1.2.11.tar.gz
Wir brauchen auch OpenSSL:
wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz
wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256
wget https://www.openssl.org/source/openssl-1.1.1d.tar.gz.asc
sha256sum openssl-1.1.1d.tar.gz gives 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2
cat openssl-1.1.1d.tar.gz.sha256 gives 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2
Wir haben nun die Integrität der Datei überprüft. Lassen Sie uns auch die Signatur überprüfen.
pgpdump openssl-1.1.1d.tar.gz.asc | grep -E "Fin|ID"
Ergebnisse:
v4 - Fingerprint - 86 57 ab b2 60 f0 56 b1 e5 19 08 39 d9 c4 d2 6d 0e 60 44 91
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0xD9C4D26D0E604491
Holen wir uns den Schlüssel und importieren ihn in den Schlüsselbund:
wget http://pgp.key-server.io/download/0xD9C4D26D0E604491
gpg2 --import 0xD9C4D26D0E604491
Ergebnis:
gpg: key D9C4D26D0E604491: public key "Matt Caswell <[email protected]>" imported
Wir überprüfen nun den Download:
gpg2 --verify openssl-1.1.1d.tar.gz.asc openssl-1.1.1d.tar.gz
gpg: Signature made Tue Sep 10 15:13:14 2019 CEST
gpg: using RSA key 8657ABB260F056B1E5190839D9C4D26D0E604491
gpg: Good signature from "Matt Caswell <[email protected]>" [unknown]
gpg: aka "Matt Caswell <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8657 ABB2 60F0 56B1 E519 0839 D9C4 D26D 0E60 4491
Die Fingerabdrücke stimmen überein. Ein Verweis auf denselben Fingerabdruck ist auch hier zu finden:https://wiki.freebsd.org/OpenSSL/Base/Update111
Wir müssen an diesem Punkt davon ausgehen, dass die gesamte heruntergeladene Software überprüft und in Ordnung ist. Erstellen wir jetzt die ARM-SSHD-Binärdatei!
cd zlib-1.2.11
Lassen Sie uns zlib konfigurieren:
CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc LD=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ld CFLAGS+=-I/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot/usr/include LDFLAGS+=-L/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/lib ./configure
Dann mach es:
make
Lassen Sie uns Folgendes überprüfen:
ls -l libz*
sollte jetzt ungefähr Folgendes anzeigen:
-rw-rw-r-- 1 user user 155378 Oct 20 04:45 libz.a
lrwxrwxrwx 1 user user 14 Oct 20 04:45 libz.so -> libz.so.1.2.11
lrwxrwxrwx 1 user user 14 Oct 20 04:45 libz.so.1 -> libz.so.1.2.11
-rwxrwxr-x 1 user user 133664 Oct 20 04:45 libz.so.1.2.11
Guter Synology-Benutzer! Lassen Sie uns OpenSSL kompilieren!
Lassen Sie uns es extrahieren und in das Arbeitsverzeichnis wechseln:
cd .. && tar xvzf openssl-1.1.1d.tar.gz && cd openssl-1.1.1d
Dann konfigurieren wir es:
CFLAGS+=-I/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot/usr/include LDFLAGS+=-L/usr/local/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/lib ./Configure linux-generic64 shared -DL_ENDIAN --prefix=/home/user0/opensslArm --openssldir=/home/user/opensslArm CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc RANLIB=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ranlib AR=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ar LD=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ld MAKEDEPPROG=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc PROCESSOR=ARM
Nun machen wir es:
make
Dies dauert eine Weile, also haben Sie Geduld.
Lassen Sie es uns überprüfen:
ls lib*so*
Sollte geben
libcrypto.so libcrypto.so.1.1 libssl.so libssl.so.1.1
Herzlichen Glückwunsch, Sie kommen Ihrem Ziel, dies Wirklichkeit werden zu lassen, immer näher!
Lassen Sie uns OpenSSH kompilieren!
Zuerst müssen wir es konfigurieren:
./configure --host=arm-linux --with-libs --with-zlib=/home/user/crosscompile/zlib-1.2.11 --with-ssl-dir=/home/user/crosscompile/openssl/openssl-1.1.1d --disable-etc-default-login CC=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc AR=/usr/local/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-ar
Und jetzt machen Sie es:
make
Mehrere ausführbare Binärdateien werden jetzt in ~/crosscompile/openssh-8.1p1 erstellt
Mal sehen, ob wir uns mit einem normalen Benutzer über SSH bei DS anmelden können, indem wir die neue SSHD-Binärdatei verwenden, die wir erstellt haben. Inzwischen sollten Sie sich mit einem vorhandenen Benutzer aus der Administratorgruppe passwortlos bei DS anmelden können.
Kopieren wir das neue SSHD und Libcrypto auf den DS:
scp ~/crosscompile/openssh-8.1p1/sshd DS:~/newsshd
scp ~/crosscompile/openssl-1.1.1d/libcrypto.so.1.1 DS:~
Lassen Sie uns dann auf normale Weise per SSH auf DS zugreifen:
ssh DS
Dann erstellen wir eine Kopie von sshd_config:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_new
Bearbeiten Sie die neue Konfigurationsdatei:
vim /etc/ssh/sshd_config_new
Ändern Sie „UsePAM yes“ in „#UsePAM yes“.
Entfernen Sie das Kommentarzeichen vom HostKey /etc/ssh/ssh_host_ed25519_key
Speichern und schließen.
Eigentümer des neuen SSHD ändern:
sudo chown root:root newsshd
Wir müssen nun einige Dateien geringfügig bearbeiten. Sichern Sie zunächst die Dateien, die wir bearbeiten möchten:
sudo cp /etc/passwd /etc/passwd.org && sudo cp /etc/group /etc/group.org
Fügen Sie diese Zeile am Ende von /etc/passwd ein:
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
Fügen Sie außerdem diese Zeile am Ende von /etc/group ein:
/etc/group:sshd:*:27:
Wenn Sie die oben genannten Änderungen nicht vornehmen, erhalten Sie beim Ausführen der gerade übertragenen SSHD-Binärdatei die Meldung „Privilege Separation User SSHD existiert nicht“.
Lassen Sie uns jetzt einen Verbindungstest durchführen!
Auf DS:
sudo LD_LIBRARY_PATH="/absolutepathtohomedir:$LD_LIBRARY_PATH" /absolutepathtohomedir/newsshd -p 444 -f /etc/ssh/sshd_config_new -h /etc/ssh/ssh_host_ed25519_key -d
Dadurch wird die neue SSHD-Binärdatei im Debugmodus gestartet.
Sie können sich nun von Ihrer Linux-Instanz aus wie gewohnt mit
ssh -p 444 user@DS
ENDLICH - DER GROSSE ERSATZ.
Notieren Sie sich alles, was Sie tun, und bewahren Sie es zusammen mit den Dateien, die Sie haben, irgendwo auf. Synology Inc. ist dafür bekannt, dass bei Aktualisierungen manchmal Änderungen und Dateien ersetzt werden. In diesem Fall müssen Sie Telnet über DSM aktivieren und sich über Telnet im lokalen Netzwerk anmelden, um die Einstellungen wiederherzustellen. Möglicherweise können Sie einen Cronjob einrichten, um das System zu überwachen und alle Änderungen, die mit einer Aktualisierung einhergehen, automatisch rückgängig zu machen. Abhängig von Ihrer Konfiguration müssen Sie DSM möglicherweise nicht sehr oft aktualisieren, wenn Sie sich bereits in einem sehr sicheren und segmentierten Netzwerk befinden.
Die relevanten Binärdateien, die wir für die ARM-Architektur kompiliert haben, befinden sich in ~/crosscompile/openssh-8.1p1:
- ./ssh-agent (Authentifizierungsagent)
- ./sftp-server (SFTP-Server-Subsystem)
- ./ssh (OpenSSH SSH-Client (Remote-Login-Programm))
- ./ssh-keyscan (öffentliche SSH-Schlüssel sammeln)
- ./ssh-keygen (Generierung, Verwaltung und Konvertierung von Authentifizierungsschlüsseln)
- ./sftp (sicheres Dateiübertragungsprogramm)
- ./ssh-keysign (standardmäßig deaktiviert)
- ./ssh-add (fügt dem Authentifizierungsagenten RSA- oder DSA-Identitäten hinzu)
- ./scp (Sicheres Kopieren (Remote-Dateikopierprogramm))
- ./ssh-pkcs11-helper (ssh-agent (Hilfsprogramm für PKCS#11-Unterstützung)
- ./sshd (OpenSSH SSH-Daemon)
Sie müssen entscheiden, was Sie davon benötigen. Wenn Sie nur sshd und scp verwenden möchten, reicht es möglicherweise aus, diese Binärdateien zu ersetzen.
Bearbeiten Sie zunächst die ursprüngliche Datei /etc/ssh/sshd_config, kommentieren Sie „UsePAM yes“ zu „#UsePAM yes“ und heben Sie dann die Kommentierung von „HostKey /etc/ssh/ssh_host_ed25519_key“ auf.
Sie sollten wirklich nur ed25519-Schlüssel verwenden. Wenn Sie andere Arten von Schlüsseln verwenden, heben Sie die entsprechende Kommentierung auf.
Stellen wir sicher, dass OpenSSL-Unterstützung verfügbar ist.
Auf meinem DS überschreibt dies nichts, Ihre Erfahrung kann variieren. Prüfen Sie, ob das Ziel bereits vorhanden ist. Ich habe es auf diese Weise gemacht, da es eine einfache Methode ist, dies zum Laufen zu bringen. Möglicherweise könnte die gemeinsam genutzte Objektdatei in einen benutzerdefinierten Pfad eingefügt und dem Suchpfad für gemeinsam genutzte Objektdateien hinzugefügt werden.
sudo mv ~/libcrypto.so.1.1 /usr/lib/
Suchen Sie den Speicherort der Dateien, die Sie ersetzen möchten:
which sshd ; which scp
Ergebnis:
/bin/sshd
/bin/scp
Sichern Sie diese beiden Dateien.
sudo cp /bin/sshd /bin/sshd.DS.orginal
sudo cp /bin/scp /bin/scp.DS.orginal
Beenden Sie die Linux-Instanz und kopieren Sie die neu erstellte SCP-Datei:
scp scp DS:~
Stellen Sie per SSH eine Verbindung zum DS her, verschieben Sie die SCP-Datei und legen Sie den richtigen Eigentümer fest:
sudo mv ~/scp /bin
sudo chown root:root /bin/scp
Da /bin/sshd aktiv ist, kann es nicht überschrieben werden, also müssen wir es beenden. Aber vorher müssen wir unser neu erstelltes SSHD starten, damit wir einen alternativen Pfad zum DS haben.
Starten Sie ein neues Terminal auf Ihrer Linux-Instanz und stellen Sie auf dem üblichen Weg eine SSH-Verbindung zu DS her:
ssh DS
Erstellen Sie dann eine Instanz Ihres neuen SSHD-Servers:
sudo /absolutepathtohomedir/newsshd -p 777 -f /etc/ssh/sshd_config_new -h /etc/ssh/ssh_host_ed25519_key
Beenden Sie die SSH-Sitzung und versuchen Sie, sich bei einer Sitzung anzumelden, die von der neu erstellten SSH-Binärdatei gesteuert wird:
ssh -p 777 user@DS
Beenden Sie jetzt den ursprünglichen SSH-Server auf Port 22.
sudo su
dann bearbeiten Sie die SSH-Konfiguration
vim /etc/init/sshd.conf
Kommentieren Sie die Respawn-Zeilen aus, sodass sie wie folgt aussehen:
#respawn
#respawn limit 5 10
Dann:
netstat -ap | grep ssh
Die Prozess-ID finden Sie rechts
Die Zeile sollte folgendermaßen aussehen:
tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN 9508/sshd
SSH-Shell stoppen
synoservice --hard-stop ssh-shell
Beenden Sie den SSHD-Prozess.
kill -9 9508
Überprüfen Sie, ob der Prozess beendet ist und nichts auf Port 22 lauscht:
netstat -tpa | grep 22
Möglicherweise müssen Sie andere SSHD-Instanzen herunterfahren, wenn Sie während dieser Anleitung mit verschiedenen Ports experimentiert haben.
Wenn alles fehlschlägt, können Sie SSH über DSM deaktivieren.
Endlich:
cp /fullhomepath/newsshd /bin/sshd && chown root:root /bin/sshd
Kehren Sie die zuvor in /etc/init/sshd.conf vorgenommenen Respawn-Kommentare um
Erstellen Sie diesen Symlink, da der neue SSHD beschwert, dass die lokale SSHD_Config-Datei nicht existiert
ln -s /etc/ssh/sshd_config /usr/local/etc/sshd_config
SSHD erneut aktivieren:
synoservice --hard-enable ssh-shell
Überprüfen Sie nun, ob die kopierten Dateien mit den kompilierten Dateien übereinstimmen:
Auf DS:
sha256sum /bin/sshd /bin/scp
Auf der Linux-Instanz:
sha256sum ~/crosscompile/openssh-8.1p1/sshd ~/crosscompile/openssh-8.1p1/scp
Die Hashes für die jeweiligen Binärdateien sollten zwischen den Systemen übereinstimmen.
Wir können auch die Version der neuen im Vergleich zu den alten Dateien überprüfen:
ash-4.3# /bin/sshd.DS.orginal --version ; /bin/scp.DS.orginal --version
unknown option -- - OpenSSH_7.4p1, OpenSSL 1.0.2r-fips 26 Feb 2019 usage: sshd [-46DdeiqTt] [-C connection_spec] [-c
host_cert_file]
[-E log_file] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-o option] [-p port] [-u len] unknown
option -- - usage: scp [-12346BCpqrv] [-c cipher] [-F ssh_config] [-i
identity_file]
[-l limit] [-o ssh_option] [-P port] [-S program]
[[user@]host1:]file1 ... [[user@]host2:]file2
ash-4.3# /bin/sshd --version ; /bin/scp --version
unknown option -- -
OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
usage: sshd [-46DdeiqTt] [-C connection_spec] [-c host_cert_file]
[-E log_file] [-f config_file] [-g login_grace_time]
[-h host_key_file] [-o option] [-p port] [-u len]
unknown option -- -
usage: scp [-346BCpqrTv] [-c cipher] [-F ssh_config] [-i identity_file]
[-J destination] [-l limit] [-o ssh_option] [-P port]
[-S program] source ... target
Du könntest nun versuchen, dich erneut normal mit der Synology zu verbinden:
ssh DS
Sie werden nun mit etwas wie „WARNUNG: DIE IDENTIFIZIERUNG DES REMOTE-HOSTS HAT SICH GEÄNDERT!“ begrüßt.
Dies ist zu erwarten. Beheben Sie das Problem manuell, indem Sie /home/user/.ssh/known_hosts bearbeiten. Es sollte ausreichen, alte Schlüssel zu entfernen, die Verbindung wiederherzustellen und dann den neuen Schlüssel zu akzeptieren.
Um abschließend zu prüfen, ob sich durch einen Neustart etwas geändert hat, können Sie optional den DS neu starten.
Um sicherzustellen, dass die benutzerdefinierten Zeilen in /etc/passwd und /etc/group erhalten bleiben, verwenden Sie das folgende Skript, speichern Sie es in /usr/local/bin/pwdgroupfixer.sh und denken Sie daran, es mit chmod +x ausführbar zu machen.
Machen Sie einen Eintrag in der Root-Crontab:
*/5 * * * * root /bin/sh /usr/local/bin/pwdgroupfixer.sh
Beachten Sie, dass Synology sehr genau auf die Formatierung seiner Crontab achtet. Verwenden Sie Tabulatoren statt Leerzeichen. Ein guter Tipp ist, einen vorhandenen Eintrag zu verwenden, ihn in eine neue Zeile zu kopieren und zu ändern.
Starten Sie abschließend den Crontab-Dienst neu:
sudo synoservice -restart crond
#!/bin/sh
#pwdgroupfixer.sh
#Entries to support sshd
PASSWORDFILE=/etc/passwd
USERLINE="sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin"
GROUPFILE=/etc/group
GROUPLINE="/etc/group:sshd:*:27:"
itemcheck(){
FILE=$1
ITEM=$2
DATE=`/bin/date +%Y-%m-%d`
TEMPFILE=/tmp/$DATE
/bin/echo '0' > $TEMPFILE
FOUND=0
/bin/sed '/^[ \t\r\n]*$/d' $FILE | while read LINE; do
if [[ ${LINE:0:1} != "#" ]]; then
if [ "$LINE" == "$ITEM" ];
then
let FOUND++
/bin/echo $FOUND > $TEMPFILE
fi
fi
done
FOUND=`/bin/cat $TEMPFILE`
if [ "$FOUND" -eq "0" ]; then
/bin/cp $FILE $FILE.`/bin/date +%Y-%m-%d`
/bin/echo $ITEM >> $FILE
fi
}
itemcheck $PASSWORDFILE "$USERLINE"
itemcheck $GROUPFILE $GROUPLINE
#end pwdgroupfixer.sh
Antwort3
Ich habe den folgenden Ansatz ausprobiert, bei dem weder zusätzliche Software installiert noch Benutzern, die diese nicht erhalten sollten, erhöhte Berechtigungen erteilt werden. Ich habe jedoch noch nicht bestätigt, dass diese Lösung tatsächlich funktioniert. Ich vermute, dass ich das NAS am Ende des Vorgangs ein zweites Mal neu starten muss. Ich werde hier Updates veröffentlichen, sobald ich mehr weiß. Wenn jemand es bis zum zweiten Neustart versucht, hinterlassen Sie bitte einen Kommentar!
Mir wurde klar, dass ich das Spiel von Synology spielen und die Benutzergruppe „Administratoren“ auf eine Gruppe reduzieren könnte, die einem lediglich SSH-Berechtigungen erteilt.
Ich habe eine zweite Gruppe erstellt und ihr dieselben Berechtigungen wie der Standardgruppe „Administratoren“ gegeben. Nehmen wir an, Sie nennen diese Gruppe „realadmin“. Alle Benutzer, die eigentlich Administratorrechte haben sollen, sollten dieser Gruppe hinzugefügt werden (um sicherzugehen, lassen Sie sie auch in den ursprünglichen „Administratoren“). Nachdem Sie diese Gruppe erstellt und alle Benutzer hinzugefügt haben, die Administratorrechte haben sollen, melden Sie sich mit einem Administratorkonto per SSH beim NAS an und sudo vi /etc/sudoers. Ersetzen Sie %administratorsdurch %realadmin(achten Sie unbedingt darauf, dass Sie dies richtig eingeben, vielleicht kopieren und fügen Sie es zur Sicherheit aus dem DSM-Admin-Panel ein) und speichern und schließen Sie, indem Sie eingeben wq!. Starten Sie das NAS neu, damit diese Änderung wirksam wird (Sie verlieren Ihren Sudo-Zugriff, bis Sie das NAS neu gestartet haben). Entfernen Sie abschließend alle Berechtigungen aus der Gruppe „Administratoren“ mit Ausnahme derjenigen, die Sie wahrscheinlich mit SSH verwenden, wie z. B. rsync. Aktualisieren Sie die Beschreibung, um zu zeigen, dass „Administratoren“ jetzt im Wesentlichen die SSH-Benutzergruppe ist. Fügen Sie alle Benutzer hinzu, denen Sie SSH-Zugriff gewähren möchten; sie sollten jetzt keine Administratorrechte mehr erhalten, weil sie „Administratoren“ sind. Stellen Sie sicher, dass Sie /bin/shfür jeden dieser Benutzer die Shell auf zurücksetzen /etc/passwdund in ihren Home-Verzeichnissen eine Datei mit den öffentlichen Schlüsseln erstellen .ssh/authorized_keys, mit denen sie sich authentifizieren können sollen.
Ich habe die oben genannten Schritte ausgeführt und dann versucht, mich per SSH mit einem Nicht-Real-Admin-Konto, das ich zur Gruppe „Administratoren“ hinzugefügt hatte, beim NAS anzumelden. Trotzdem habe ich permission denied (publickey). Ich bin mir nicht sicher, was an dieser Stelle fehlt. Vielleicht muss ich das NAS erneut neu starten, damit die Hinzufügung des Benutzers zu „Administratoren“ wirksam wird. Ich habe kurz versucht, denselben Benutzer auch zu „Realadmin“ hinzuzufügen, aber der Benutzer konnte SSH immer noch nicht verwenden, zumindest nicht ohne Neustart des NAS. Ich habe das NAS noch nicht ein zweites Mal neu gestartet, weil ich Prozesse laufen habe, die ich nicht zu oft unterbrechen möchte, und weil ich eine andere, schnelle und einfache Problemumgehung gefunden habe, die mein spezielles Problem vorerst löst.
Ich habe diese (theoretische) Lösung ursprünglich im Synology-Community-Forum beschrieben und dazu einige Erläuterungen gegeben:https://community.synology.com/enu/forum/1/post/125859?page=2(16. Antwort, aktuellste zum Zeitpunkt des Schreibens).
Antwort4
Ich bin keineswegs ein NAS-Experte, aber wenn ich den Benutzerzugriff erlaube, wird die git_reposShell aktiviert (damit sie in die Kategorie passt). Wenn ich das ändere, wird SSH-Zugriff gewährt./etc/passwd/var/packages/Git/target/bin/git-shellDSM 6.2.4-25556 Update 5DSM 6.2.x/bin/sh