Öhm, was ist denn dieses *c<irgendwas>u.de"? Das Update dafür müsstest du natürlich dort machen, nicht bei ipv64.net
Edit: Google mal nach "acme.sh". Das ist LE-Variante ohne NPM als Docker-Script, was vermutlich auch der NPM im Hintergrund nutzt. Dort wirst du auch eine Liste der unterstützten DNS-Provider finden.
Edit: Hier noch ein Link: https://github.com/acmesh-officia…e/master/dnsapi
Posts by Benares
-
-
Ich habe meine Haupt-Domain bei Netcup, nennen wir sie mal meinedomain.com. Der NPM hat ja eine Zertifikats-Verwaltung eingebaut, die die LE-Zertifikate 30 Tage vor Ablauf automatisch verlängert. Normalerweise sind die nur 90 Tage gültig.
Für den dafür erforderlichen "DNS-Challenge" (beweise, dass die Domain dir gehört) braucht es einen Anbieter mit unterstützter DNS-API. Das bietet Netcup und auch ipv64.net.Der Vorgang läuft in etwa so ab: LE sagt, "leg bitte einen TXT-Record mit folgendem Wert an, ich überprüfe in ein paar Minuten, ob der existiert. Dann glaub ich dir, dass die Domain dir gehört, und du bekommst dein neues Zertifikat" Über die DSN-API des Anbieters wird der TXT-Record temporär angelegt und danach wieder gelöscht.
-
Ich verwende auf meiner DXP4800plus den ddns-ipv64-Updater um meine Domain bei ipv64.net auf Stand zu halten. In meiner eigentlichen Domain verwende ich statische CNAMEs auf ipv64.net. Als Reverse-Proxy verwende ich den NPM. Beides läuft unter Docker.
-
Ich finde auch, 10 Minuten sind zu kurz, 30-60 Minuten sind besser.
Ich gehe in solchen Fälle immer mit der Konsole drauf und suche z.B. mit " find /volume2 -cmin -15" was denn da in den z.B. letzten 15 Minuten geändert wurde. Das liefert Hinweise auf den Verursacher. -
ds106 Da siehst du mal, dass ich immer älter und vergesslicher werde 😔
-
Stimmt, die 3 vorhandenen .conf-Dateien unter sshd_config.d werden bei einem Reboot wohl auch überschrieben. Aber meine eigene, zusätzliche überlebte seit 07/2025 alles.
Edit: Die Templates liegen vermutlich unter /rom/etc/ssh und/oder /rootfs/base/etc/ssh, weiß aber nicht, wo das physisch liegt. -
Jetzt musste ich doch mal schauen, wieso das bei mir auch einem Reboot immer noch funktioniert. Also hab ich die DXP4800plus eben mal neu gestartet. Ergebnis: Es funktioniert immer noch.
Recherche:
Ja, die /etc/ssh/sshd_config wird bei jedem Reboot wieder mit einem Template überschrieben. Darin steht dann wieder "PermitRootLogin no" und "PubkeyAcceptedAlgorithms +ssh-rsa" fehlt. Ich hatte wohl aber bei meinen ersten Versuchen 2025 auch eine Datei "root_key.conf" in /etc/ssh/sshd_config.d angelegt mit
als Inhalt.Obwohl die /etc/ssh/sshd_config.d/*.conf Dateien noch vor dem "PermitRootLogin no" includiert werden, überschreibt dies die Angaben aus der root_key.conf wohl nicht, wie
Coderoot@DXP4800PLUS:/etc/ssh/sshd_config.d# sshd -T | grep permitrootlogin permitrootlogin yes root@DXP4800PLUS:/etc/ssh/sshd_config.d# sshd -T | grep pubkeyacceptedalgorithms pubkeyacceptedalgorithms ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
zeigt.
Der Weg über eine zusätzliche .conf-Datei in sshd_config.d ist also der richtige. -
Komisch, also bei mir wird da bei einem Reboot nichts überschrieben, höchstens mal nach einem Update. Aber das ist ja schnell wieder geändert.
Den Weg über eine .conf-Datei in /etc/ssh/sshd_config.d/ kann man natürlich auch gehen, ist vielleicht sogar besser und übersteht vielleicht auch ein Update. Was mir nur nicht klar ist: In der sshd_config wird sshd_config.d/*.conf ja ziemlich am Anfang "Included", "PermitRootLogin" folgt aber erst danach. Was gilt denn nun am Ende? Oder war das initial auskommentiert?
Edit: Ah, hab was gefunden, "sshd -T" zeigt, mit welchen Einstellungen der sshd momentan läuft -
Uffbasse, unter /etc/ssh gibt es ssh_config- und sshd_config-Dateien/-Verzeichnisse.
Ich denke, du bist da in der falschen Datei gelandet. Achte auf das d. /etc/ssh/sshd_config ist die wichtige.
Edit: Seh deine Ergänzung jetzt erst. Lass das mit den Ergänzungen in /etc/ssh/ssh_config.d- und /etc/sshd_config.d-Verzeichnissen, die jeweils includiert werden. Einfach nur die /etc/ssh/sshd_config anpassen -
Ja, geht auch ohne putty
Warum also erst über einen anderen Benutzer gehen?
Weiß aber nicht, warum das auch geht, .ssh/ known_hosts?
Bei putty gefällt mir, dass man recht leicht zwischen den Fenstern kopieren/einfügen kann.
Einfaches markieren legt's in die Zwischenablage, Rechts-Klick im anderen Fenster (oder dem gleichen) fügt's ein. -
Und wie findet dann die APP die neue IDX? Klappt die Anzeige der bisherigen Bilder wenigstens?
-
Andy Hoffentlich nicht mit "" jeweils drumrum. Die "" waren nur für mich in meiner Doku.
Auch die Rechte sind wichtig.Coderoot@DXP4800PLUS:~# ls -als .ssh total 20 4 drwx------ 2 root root 4096 Apr 14 09:42 . 4 drwxr-xr-x 1 root root 4096 Jul 16 15:08 .. 4 -rw------- 1 root root 1474 Apr 14 09:44 authorized_keys 4 -rw-r--r-- 1 root root 142 Aug 25 2025 known_hosts
.ssh sollte auf 700 sitzen und authorized_keys auf 600.
Einen kompletten Neustart braucht es nicht, ein "service ssh restart" (<- ohne die "") reicht. -
Ja, solltest du vielleicht, das sudo-Geraffel erspare ich mir lieber. Wenn ich auf meine NASe oder Sonstwohin per ssh gehe, geht es immer darum etwas zu administrieren. Die Anmeldung sieht dann einfach so aus:
This image is exclusive to our members!
Please log in or register for free to view graphics and attachments. -
karl-heinz-lnx Guter Einwand. Ich hab mir bei der Einrichtung meiner DXP4800plus damals folgendes notiert
-
Sorry, weiß ich leider auch nicht. Wie ist denn der aktuelle Zustand? Hat die IDX durch den Umzug nun die IP der DXP? Ist die DXP noch an?
Wenn der Name sich geändert hat, vermute ich mal, dass man der APP noch sagen muss. -
-
Dieses Ugreen-Zertifikat, das beim Aufruf über https://namedesnas auftaucht, verstehe ich übrigens überhaupt nicht. Es ist nicht richtig signiert, noch gilt es für irgendwelche Namen.
This image is exclusive to our members!
Please log in or register for free to view graphics and attachments.
This image is exclusive to our members!
Please log in or register for free to view graphics and attachments. -
Muss es denn gleich https sein? Probier's mal über http://dxp2800:9999, oder wie deine DXP heißt. Auch ganz ohne eine Port-Angabe sollte es gehen.
-
Welcher Treiber ist das, der hier?
GitHub - bb-qq/r8152: Synology DSM driver for Realtek RTL8152/RTL8153/RTL8156 based adaptersSynology DSM driver for Realtek RTL8152/RTL8153/RTL8156 based adapters - bb-qq/r8152github.com
Ich hab in meiner DS415+ noch die Version 2.20.1-1 am laufen, ist aber auch noch DSM7.1.1. Ja, bei DSM 7.3 scheint da beim Treiber Schluss zu sein - Schade -
Dein RAM ist der Schreibcache, Lesecache ist Kaffeesatzleserei.
Aber Lesecache ist er auch, wenn was wiederholt gelesen wird.
Auch ich halte nicht viel von NVME-Cache - lieber mehr RAM.
Ich weiß nicht, ob man das bei UGOS auch so schön sieht wie bei Synology ("cat /proc/meminfo" vielleicht?). "Zwischengespeichert" ist der RAM-Cache und wird vom freien RAM, je nach nach Bedarf, dynamisch abgezweigt. Nur freier Speicher ist unnützer Speicher.
This image is exclusive to our members!
Please log in or register for free to view graphics and attachments.