Qnap 251+ ssh Key

    Hallo liebe Qnap Gemeinde,


    ich versuche seit Tagen den SSH Key zu aktivieren, damit ein Key und ein Passwort abgefragt wird. Ich hab gefühlt das komplette Internet durchforstet und komme einfach nicht weiter.


    Ich habe folgende Anleitung benutzt:

    [Howto] - SSH-Login via PuTTY ohne Passwort


    Die einzelnen Dateien haben die richtigen Schreibrechte



    Code: etc/ssh
    [/etc/ssh] # ls -al
total 20
drwxr-xr-x 2 admin administrators 140 2022-04-24 18:48 ./
drwxr-xr-x 40 admin administrators 3700 2022-04-24 18:47 ../
-rw-r--r-- 1 admin administrators 3058 2022-04-24 18:48 sshd_config
-rw------- 1 admin administrators 1385 2022-04-22 22:48 ssh_host_dsa_key
-rw-r--r-- 1 admin administrators 604 2022-04-22 22:48 ssh_host_dsa_key.pub
-rw------- 1 admin administrators 2655 2022-04-23 14:34 ssh_host_rsa_key
-rw-r--r-- 1 admin administrators 568 2022-04-22 22:48 ssh_host_rsa_key.pub

    und anliegend meine sshd_config



    Selbst wenn ich die Autorun.sh deaktiviere und meine Einstellungen mit # setze komme ich auch nicht mehr per shell drauf. Ich verwende gerade Telnet..


    Hat jemand einen Rat für mich? Bin am verzweifeln..


    Danke im Voraus.

    Einmal editiert, zuletzt von Nils-86 ()

    Die verlinkte Anleitung ist 10 Jahre alt!

    Außerdem haben sich mittlerweile auch die Verzeichnisse geändert, ein /share/MDx_DATA gibt es nicht mehr.

    Ich bin gerade nicht am NAS, aber SSH Anmeldung per Key geht bei mir problemlos.


    Kann aber erst morgen nachsehen.


    Gruss


    P.S. /share/Public ist aber definitiv nicht der richtige Ort für die sshd_config!

    Hallo FSC,


    vielen Dank.


    die Datei liegt in share/public/ damit die beim reboot bestehen bleibt:


    Code
    #sshd_config auch nach Restart
cp /share/HDA_DATA/Public/sshd_config /etc/ssh/sshd_config


    Problem ist aber, das eine ganz andere config geladen wird?


    Code
    [/etc/ssh] # ps aux | grep ssh
12024 admin      3420 T   find / -name ssh
18961 admin      2184 S   grep ssh
24885 admin      4948 S   /usr/sbin/sshd -f /etc/config/ssh/sshd_config -p 22


    und dieser Inhalt ist:


    Code
    Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
PermitRootLogin yes
UseDNS no
Subsystem sftp /usr/libexec/sftp-server
AllowTcpForwarding no
AllowUsers admin



    Ich weiß, dass ich am Anfang als ich diesen Nas gefunden habe, Root Access via Shell aktiviert habe, aber ich weiß nicht mehr warum ich diese Datei nicht mehr überschreiben kann, da sie nach einem Reboot wieder hergestellt wird.

    Ich habe nachgesehen.

    Die sshd_config liegt in /etc/ssh.

    Der Inhalt ist folgender (alle Kommentarzeilen entfernt):


    Code
    Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys
UseDNS no
Subsystem       sftp    /usr/libexec/sftp-server
AllowUsers admin


    In /etc/ssh ist auch die Datei authorized_keys mit den Keys, die auf dem Client erstellt wurden.


    Und so sieht das dann von einem raspBerry Pi aus aus_


    Code
    pi@pi64:~ $ ssh -l admin 192.168.0.104 uname -a
Linux CELVIN-Q902-3 3.4.6 #1 SMP Tue Apr 23 14:56:51 CST 2019 x86_64 GNU/Linux
pi@pi64:~ $


    Mehr ist eigentlich nicht. SSH muss in der GUI natürlich aktiviert sein.


    Gruss

    Die funktioniert aber bei mir nicht, egal was ich da auch reinschreibe, sie wird beim nächsten daemon restart wieder umgeschrieben


    Edit:

    Kann mich jetzt wieder über SSH einloggen:


    Hab jede einzelne Key Datei gelöscht, aus allen bekannten Verzeichnissen gelöscht:

    https://forum.qnap.com/viewtopic.php?f=50&t=142129


    Code
    rm -i /etc/config/ssh/ssh_host_dsa_key
rm -i /etc/config/ssh/ssh_host_dsa_key.pub
rm -i /etc/config/ssh/ssh_host_rsa_key
rm -i /etc/config/ssh/ssh_host_rsa_key.pub

    Jetzt warte ich noch auf eine step by step Anleitung, wie ich nun die passenden Keys generiere und ich es auch diesmal zum laufen kriege.


    Ich hoffe ihr könnt mir helfen.



    Meine Anleitung wäre nun:

    ssh-keygen -t rsa

    cat /root/.ssh/id_rsa.pub >> /etc/ssh/authorized_keys

    chmod 600 /etc/ssh/authorized_keys




    Code: sshd_config in etc/ssh/
    Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys
UseDNS no
Subsystem       sftp    /usr/libexec/sftp-server
AllowUsers admin



    cat /etc/ssh/id_rsa


    Key kopieren -> .txt File speichern -> in Puttygen hinzufügen und als .ppk speichern


    /etc/init.d/login.sh restart - Fertig???

    3 Mal editiert, zuletzt von Nils-86 ()

    Ein Reboot ist nicht notwendig.

    Die sshd_config habe ich oben schon gepostet, aber die Zeilen

    Zitat von FSC830
    Code
    RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys
UseDNS no

    sind tatsächlich überflüssig bzw. können kommentiert bleiben!


    Die aktuelle Datei sieht wie folgt aus:


    Code
    Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UseDNS no
Subsystem       sftp    /usr/libexec/sftp-server
AllowUsers admin

    Die authorized_keys für den admin liegt unter /etc/config/ssh, die für andere Benutzer unter /share/homes/BENUTZERNAME/.ssh.

    Das ist bei mir alles bootresistent.


    Gruss

    Die Authorized_keys für den admin liegt bei mir im Verzeichnis /share/homes/admin/.ssh


    Wichtig ist, dass die Rechte der Dateien stimmen, sonst funktioniert es nicht. authorized_keys und der private Schlüssel id_rsa müssen 600 haben, der öffentliche Schlüssel id_rsa.pub bekommt 644.


    Deine Erzeugung des RSA-Schlüssels ist mir suspekt. Der Schlüssel muss auf dem Clienten, also deinem PC, erzeugt werden, und der private Schlüssel darf den Rechner nie verlassen. Die Authorized_keys hingegen liegt nur auf dem Server, also dem NAS vor, und dort wird der öffentliche Schlüssel, den du auf dem PC erzeugt hat, eingetragen. Du hingegen scheinst den Schlüssel auf dem Server zu erzeugen. Das mag funktionieren, ist aber sicherheitstechnisch nicht sauber, da der geheime private Schlüssel dann auf einem Gerät liegt, wo er nichts verloren hat, und von unberechtigten Personen (wenn außer dir noch jemand das Admin-Kennwort kennt) abgegriffen werden kann.


    Zitat von Nils-86

    Problem ist aber, das eine ganz andere config geladen wird?

    Ja.


    Wenn die Standard-Konfig passt, ist das kein Problem.


    Wenn du eine eigene Konfiguration brauchst (z. B. weil du ssh-Anmeldungen über das Passwort verbieten und ausschließlich ssh-Schlüssel zur Anmeldung zulassen willst; ist bei mir nötig, da der ssh-Zugang per Portweiterleitung von außen erreichbar ist), dann ist es an der Zeit, über den Qnap-Bootmechanismus zu fluchen.


    Beim Systemstart werden viele Systemdateien neu aufgebaut. Dazu gehört auch die Datei /etc/daemon_mgr.conf, welche die Aufrufparameter für viele (alle?) Dämonen enthält. Wenn ein Dämon mit anderen Parametern gestartet werden soll, dann muss während des Bootvorgangs diese Datei editiert werden. Dies kann im dir vermutlich bekannten Skript autorun.sh geschehen mit

    Code
    # sshd Server mit sicherer Konfiguration
cp -p /etc/daemon_mgr.conf /etc/daemon_mgr.conf.bak
sed '/^DAEMON[0-9]* = sshd,.*$/s/-f  *[^ ][^ ]* /-f \/mnt\/HDA_ROOT\/boot\/sshd_config /' /etc/daemon_mgr.conf.bak >/etc/daemon_mgr.conf
killall sshd

    Nach dem Kill-Aufruf wird der sshd-Server automatisch mit den geänderten Parametern gestartet, ohne dass der Start im Skript angegeben wird.


    Der Erfolg kann überprüft werden:

    Code
    $ ps -eaf | grep sshd                 
 9253 admin      4176 S   /usr/sbin/sshd -f /mnt/HDA_ROOT/boot/sshd_config -p 22

    Statt /mnt/HDA_ROOT/boot/sshd_config kann auch ein anderer Name gewählt werden, aber das Verzeichnis hat den Vorteil, auch schon früh im Systemstart verfügbar zu sein.

    Interessant, so sieht es bei mir aus: QTScloud 5.0.1.1998, aber auch auf dem "echten" QTS 5.0 und 4.3.4 genauso:


    Deutlich zu sehen: /share/homes/admin/.ssh ist leer, in /root ist ein Symlink auf /etc/config/ssh und dort liegen auch die Dateien.


    Gruss

    Hab das ganze jetzt nochmal von vorne gemacht.


    Die beiden Keys habe ich wie von Anthracite erstellt, der Login klappt auch mit dem Key und dem Schlüssel. Jedoch kann ich trotzdem noch ohne den hinterlegten Key mich in die Shell einloggen.


    Ich will aber ausschließlich den Zugang mit Key akzeptieren. Welche Datei muss ich denn nun ändern um diese Änderung wirksam zu machen?

    Ich weiß nicht, ob das bei einem QNAP NAS sinnvoll ist...


    Auf eigene Gefahr kannst Du den SSH-Login mittels Passwort verhindern, in dem Du in die sshd_config die folgende Zeile aktivierst:

    PasswordAuthentication no


    Normal muss mann dann noch den sshd restarten, und dann war es das, wenn man keinen Key zur Authentifizierung hat.

    Nun ich wollte halt einfach nur etwas mehr Sicherheit... Ich habe diese Zeile versucht einzufügen, jedoch hat es keine Auswirkung.


    Beziehungsweise will ich die Passwortabfrage nicht wegnehmen, sondern beides als minimum setzen (Key+Passwort).


    Edit: Also egal in welche Datei ich auch etwas mache, es ändert sich nichts.


    Normalerweise sollte dies in die sshd_config reingeschrieben werden:


    Code
    AuthenticationMethods "publickey,password"

    Einmal editiert, zuletzt von Nils-86 ()

    Wenn man das Ganze herumkopieren in der Datei authorized_keys nicht möchte, dann kann man auch ganz einfach von dem entfernten Rechner aus ssh-copy-id benutzen.

    Das funktioniert jedenfalls vom Mac und vom Pi (mit Raspberry Pi OS) aus problemlos.

    Zitat von Barungar

    Auf eigene Gefahr kannst Du den SSH-Login mittels Passwort verhindern, in dem Du in die sshd_config die folgende Zeile aktivierst:

    PasswordAuthentication no


    Normal muss mann dann noch den sshd restarten, und dann war es das, wenn man keinen Key zur Authentifizierung hat.

    Das überlebt keinen Reboot des NAS. Damit das reboot-fest wird, siehe meinen vorangegangenen Beitrag.


    Eine Gefahr besteht nicht.

    Ein funktionierender Telnet-Zugang ist als Fallback hilfreich.

    Notfalls hilft der 3-Sekunden-Reset (autorun.sh wird deaktiviert) und folgender Reboot (sshd-config wird neu aufgebaut).


    Zitat von Nils-86

    Nun ich wollte halt einfach nur etwas mehr Sicherheit... Ich habe diese Zeile versucht einzufügen, jedoch hat es keine Auswirkung.

    Wird bei dem Login. also dem, der nicht mehr sollte sein und trotzdem funktioniert, ein Passwort angefragt?


    Wenn nein: Dann ist dein öffentlicher ssh-Schlüssel noch in der passenden Authorized_keys auf dem NAS eingetragen.


    Wenn ja: Du hast die falsche Konfigurationsdatei geändert,

    oder deine Änderung ist fehlerhaft,

    oder du hast den sshd-Server falsch neu gestartet (Wenn du den sshd-Server nur mit killall abschießt, so dass er sich automatisch neu startet, dann wird beim automatischen Neustart die sshd-config neu aufgebaut, wenn ich mich recht erinnere, womit deine Änderung wieder weg ist. killall funktioniert nur nach Änderung von /etc/daemon_mgr.conf, siehe meinen Beitrag, wie gewünscht.)

    Mod: Zitat ohne Quellenangabe ... korrigiert! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    Zitat von Anthracite

    Wird bei dem Login. also dem, der nicht mehr sollte sein und trotzdem funktioniert, ein Passwort angefragt?

    Es wird immer ein Passwort abgefragt, auch wenn ich den SSH Key nicht hinterlegt habe und dieser Zugang sollte ja auch nur mit Key funktionieren.


    Ich starte den Daemon mit /etc/init.d/login.sh restart neu, aber muss es per Webinterface (SSH aus und an) wieder anstellen, damit ich mich wieder verbinden kann. die sshd_config editiere ich in /etc/ssh/ und meine Änderungen (ganz am Ende) bleiben auch in dieser Datei stehen, aber hab das Gefühl das er die nicht lädt.


    Ich habe die gleichen Einstellungen bzw. den Weg aufn Raspi ausprobiert und da funktioniert alles einwandfrei, so wie ich es wollte.

    Ich habe es heute nur überflogen, aber die /etc/init.d/login.sh schreibt die sshd_config offenbar immer neu. Es gibt auch noch eine sshd_default_config.

    Ich habe auch mehrfach versucht irgendwo ein PasswordAuthentication no einzubauen, aber bisher ohne Erfolg. Die Anmeldung per Key dagegen ist problemlos möglich.


    Gruss

    Code
    Qnap

[~] # ssh -v localhost
OpenSSH_8.0p1, OpenSSL 1.1.1l  24 Aug 2021
    Code
    Raspberry
root@raspberrypi:/var/www/html# ssh -v localhost
OpenSSH_8.4p1 Raspbian-5+b1, OpenSSL 1.1.1n  15 Mar 2022


    Eventuell liegt es auch an den verschiedenen Versionen. Ich kann momentan den Qnap nicht updaten da qnapclub.eu down ist.

    Was hat das mit qnapclub.eu zu tun? Die Firmware kann man normal auf qnap.com laden und ein Update durchführen.

    Das ist sowieso der empfohlene Weg. Vor dem Update auch noch einen Reboot machen, dann sollte das problemlos durchlaufen.


    Gruss

    Die neue OpenSSH Version lässt sich irgendwie nicht updaten. Ich habe es manuell per Datei probiert, aber er aktualisiert Sie nicht, sondern installiert OpenSSH neu. Wieso muss das alles immer so kompliziert sein. :(

    Zitat von Nils-86

    Es wird immer ein Passwort abgefragt, auch wenn ich den SSH Key nicht hinterlegt habe und dieser Zugang sollte ja auch nur mit Key funktionieren.

    Wenn Authentifizierung sowohl über Passwort als auch über ssh-Keys möglich ist, dann wird immer zuerst ein Login über ssh-Keys versucht. Nur wenn dieser nicht geht, wird nach dem Passwort gefragt.


    Dass in deinem Falle die Passwortabfrage kommt, wird daran liegen, dass lokal der private Schlüssel id_rsa fehlt, dass der Eintrag in Authorized_keys fehlt (Datei im falschen Verzeichnis editiert?) oder dass eine der beiden Dateien oder das .ssh Verzeichnis andere Rechte als 600 haben.

    Zitat von Nils-86

    aber hab das Gefühl das er die nicht lädt

    Tut er auch nicht, weil du die falsche Datei editiert hast. Die richtige Datei ist /etc/config/ssh/sshd_config. ps | grep sshd hätte dir das auch verraten.


    Allerdings würde dir das Editieren der richtigen Datei auch nicht helfen, weil diese, wie FSC830 schon geschrieben hat, bei Neustart des sshd-Dämons neu aufgebaut wird und damit deine Änderungen weg sind.


    Was nötig ist, ist dem sshd-Dämon eine andere Konfigurationsdatei unterzuschieben. Dies geht, indem /etc/daemon_mgr.conf geändert wird und dort auf eine Kopie der Konfiguration, welche du nach Belieben ändern kannst, verwiesen wird (Parameter -f). Wenn das Ganze dann auch Reboot-fest sein soll, siehe Beitrag #7.

    Zitat von FSC830

    Ich habe auch mehrfach versucht irgendwo ein PasswordAuthentication no einzubauen, aber bisher ohne Erfolg.

    Es geht aber, siehe über dem Zitat und Beitrag #7. Die Lösung funktioniert bei mir stabil und zuverlässig und hat sogar alle qts-Updates überlebt.

    Zitat von Nils-86

    Eventuell liegt es auch an den verschiedenen Versionen.

    Nein. Das hat mit der Version nichts zu tun. Das Verhalten ist bei beiden Versionen dasselbe, und Fehler an dieser Stelle, also Fehler im Programm, gibt es nicht.