Beiträge von Laurenzis

Oh man, ich hab es gefunden. Das ganze ist eigentlich einfach, man sollte bloß lesen, was im -vvv steht:

[~] # ssh 172.22.111.10 -vvv
debug1: OpenSSH_10.0p2, OpenSSL 3.0.9 30 May 2023
debug3: Running on Linux 5.10.60-qnap #1 SMP Thu Dec 25 04:04:50 CST 2025 x86_64
debug3: Started with: ssh 172.22.111.10 -vvv
debug1: Reading configuration data /usr/etc/ssh_config
debug1: /usr/etc/ssh_config line 7: Applying options for 172.22.111.10

QTS nutzt (wo auch immer das eingestellt wird) nicht per default /root/.ssh/config sondern /usr/etc/ssh_config.

Wenn man den Inhalt meiner config in dieses File kopiert, ist alles in Ordnung und es funktioniert völlig einwandfrei. Wer lesen kann, ist klar im Vorteil...

Danke für Deine Hilfe, hat mich das doch dazu gebracht nochmal genau nachzusehen was da eigentlich grade passiert

Sorry, das war eine veraltete Version der Config. Hier die aktuellen Daten:

Aktuelles Verzeichnis:

[~/.ssh] # ls -l
total 72
-rw------- 1 admin administrators 2602 2026-02-23 12:01 azerothcore
-rw-r--r-- 1 admin administrators  569 2026-02-23 12:01 azerothcore.pub
-rw------- 1 admin administrators  243 2026-02-23 12:03 config
lrwxrwxrwx 1 admin administrators   16 2022-01-25 22:03 id_rsa -> ssh_host_rsa_key
lrwxrwxrwx 1 admin administrators   20 2022-01-25 22:03 id_rsa.pub -> ssh_host_rsa_key.pub
-rw------- 1 admin administrators  932 2026-02-23 12:05 known_hosts
-rw-r--r-- 1 admin administrators   95 2026-02-09 19:53 known_hosts.old
-rw-r--r-- 1 admin administrators  695 2026-02-10 03:27 sshd_config
-rw-r--r-- 1 admin administrators  695 2026-02-10 03:27 sshd_config.tmp
-rw-r--r-- 1 admin administrators   17 2026-02-10 03:27 sshd_user_config
-rw------- 1 admin administrators 1381 2022-01-20 19:13 ssh_host_dsa_key
-rw-r--r-- 1 admin administrators  605 2022-01-20 19:13 ssh_host_dsa_key.pub
-rw------- 1 admin administrators  505 2024-12-09 18:37 ssh_host_ecdsa_key
-rw-r--r-- 1 admin administrators  177 2024-12-09 18:37 ssh_host_ecdsa_key.pub
-rw------- 1 admin administrators  411 2024-12-09 18:37 ssh_host_ed25519_key
-rw-r--r-- 1 admin administrators   97 2024-12-09 18:37 ssh_host_ed25519_key.pub
-rw------- 1 admin administrators 2602 2022-01-20 19:13 ssh_host_rsa_key
-rw-r--r-- 1 admin administrators  569 2022-01-20 19:13 ssh_host_rsa_key.pub
-rw------- 1 admin administrators 3381 2026-02-09 19:32 truenas-backup
-rw-r--r-- 1 admin administrators  741 2026-02-09 19:32 truenas-backup.pub
[~/.ssh] #

Aktuelle Config:

Host 192.168.0.110
Hostname 192.168.0.110
User truenas-backup
PubKeyAuthentication yes
IdentityFile /root/.ssh/truenas-backup
Host 172.22.111.10
Hostname 172.22.111.10
User root
PubKeyAuthentication yes
IdentityFile /root/.ssh/azerothcore

Beide Keyfiles haben exakt 600, das .ssh-Verzeichnis wie vorgeschrieben die 700.

Bei gleicher Konfiguration auf einem beliebigen Linux-Rechner sehe ich bei ssh -vvv dass versucht wird, das entsprechende Keyfile zu lesen. Exakt das passiert unter QTS leider nicht.

Hab ich geändert, leider das Selbe Ergebnis wie vorher. SSH versucht gar nicht erst den in der Config hinterlegten Key zu nutzen...

Ok, ich versuche es nochmal zu erklären.

Auf meinen "normalen" Linux Rechnern bzw. Servern habe ich die Möglichkeit im .ssh Verzeichnis eine Datei namens "config" anzulegen. In dieser Datei kann ich Hosts und Schlüsselnamen hinterlegen. Bedeutet: Sobald ich versuche per SSH auf einen dieser Hosts zuzugreifen, nutzt ssh automatisch den zugewiesenen Schlüssel ohne dass ich diesen angeben muss Sprich: Wenn ich entweder per shell mit ssh oder über eine beliebige Software/GUI auf diesen Host zugreife, funktioniert das. Meine Frage an dieser Stelle ist schlicht: gibt es unter QTS diese Möglichkeit?

Bzgl. dem Link auf die "id_rsa" hier ein ls -l:

[~/.ssh] # ls -l
total 64
-rw-r--r-- 1 admin administrators  125 2026-02-10 02:54 config
lrwxrwxrwx 1 admin administrators   16 2022-01-25 22:03 id_rsa -> ssh_host_rsa_key
lrwxrwxrwx 1 admin administrators   20 2022-01-25 22:03 id_rsa.pub -> ssh_host_rsa_key.pub
-rw------- 1 admin administrators  837 2026-02-10 03:17 known_hosts
-rw-r--r-- 1 admin administrators   95 2026-02-09 19:53 known_hosts.old
-rw-r--r-- 1 admin administrators  695 2026-02-10 03:27 sshd_config
-rw-r--r-- 1 admin administrators  695 2026-02-10 03:27 sshd_config.tmp
-rw-r--r-- 1 admin administrators   17 2026-02-10 03:27 sshd_user_config
-rw------- 1 admin administrators 1381 2022-01-20 19:13 ssh_host_dsa_key
-rw-r--r-- 1 admin administrators  605 2022-01-20 19:13 ssh_host_dsa_key.pub
-rw------- 1 admin administrators  505 2024-12-09 18:37 ssh_host_ecdsa_key
-rw-r--r-- 1 admin administrators  177 2024-12-09 18:37 ssh_host_ecdsa_key.pub
-rw------- 1 admin administrators  411 2024-12-09 18:37 ssh_host_ed25519_key
-rw-r--r-- 1 admin administrators   97 2024-12-09 18:37 ssh_host_ed25519_key.pub
-rw------- 1 admin administrators 2602 2022-01-20 19:13 ssh_host_rsa_key
-rw-r--r-- 1 admin administrators  569 2022-01-20 19:13 ssh_host_rsa_key.pub
-rw------- 1 admin administrators 3381 2026-02-09 19:32 truenas-backup
-rw-r--r-- 1 admin administrators  741 2026-02-09 19:32 truenas-backup.pub
[~/.ssh] #

Die hier vorhandene config-Datei stammt von mir, wird aber leider nicht genutzt. Ob das an einer zusätzlich notwendigen Konfiguration oder am seitens QTS genutzten open-ssh liegt, weiß ich leider nicht.

Hier mal ein Beispiel einer config-Datei auf einem meiner Server:

Host 192.168.0.110
Hostname 192.168.0.110
User truenas-backup
PubKeyAuthentication yes
IdentityFile ~/.ssh/truenas-test

Dies führt dazu, dass dieser Rechner bei SSH-Zugriff auf den Host "192.168.0.110" grundsätzlich den Key "~/.ssh/truenas-test" nutzt. Weitere Hosts (samt individueller Keys) kann ich ohne jedes Problem hinzufügen (es gibt zu dieser config-Datei auch jede Menge Erläuterungen im Netz).

Wäre total nett. Wie gesagt, manuelle Verbindungen sind (natürlich) kein Problem, da ich SSH dann das Keyfile mitgeben kann. Das funktioniert aber leider nicht für Verbindungen über das Web-Frontend...

Gruß,

Lauri

Hallo zusammen,

ich stoße hier grade auf ein Problem, für das ich vorerst keine eigene Lösung gefunden habe.

Problem: Ich habe mehrere Server auf die ich mich von meiner QNAP aus per SSH mit einem Schlüsselpaar verbinden möchte. "normalerweise" ist das ja kein Problem, man generiert seine Schlüsselpaare, legt eine config-Datei an, hinterlegt hier die Hosts samt den zugehörigen private keys, bring die public keys auf den jeweiligen Host, bindet sie ein und alles ist gut. Allerdings will mir das auf meiner NAS nicht gelingen. Egal was ich mache, ich habe folgendes Ergebnis:

- bei jedem Verbindungsversuch bei dem ich nicht explizit den private key angebe, wird automatisch und immer der private key "id_rsa" genutzt (sieht man sehr gut, wenn man ssh mit -vvv ausführt)

- id_rsa ist bei QNAP nur ein link auf die Datei "ssh_host_rsa_key". Diese kann ich nicht ersetzen, da sie bei jedem Reboot wieder überschrieben wird

- ich nutze hier also immer ein Schlüsselwertpaar das ich nicht unter eigener Kontrolle habe!

- ich möchte nicht immer den selben private Key für alle Serververbindungen nutzen - geht mir einer "verloren", sind alle Server kompromitiert

Hat sich schon jemand mit diesem Thema auseinandergesetzt und kann mir Infos geben, wie ich selbsterstellte Keys so nutzen kann, dass sie auch bei Verbindungen über die GUI (z.B. HBS3) funktionieren?

Danke und Gruß,

Lauri

Zitat von Alv

Leider mögen die Intel-Karten nur Intel-Transceiver.

Das kann ich nicht bestätigen. Meine X520-DA2 laufen mit beliebigen Transceivern, sowohl Intel als auch anderen - ich habe sowohl 10 GBe Ethernet-Transceiver als auch LWL-Transceiver (jeweils NICHT Intel) im Einsatz die problemlos funktionieren. Produkt kann ich Dir gerne per PN auf Nachfrage nennen.

Zitat von ChrisErdle

nur weil was nicht dokumentiert ist, heißt es nicht, dass es nicht funktioniert

Das ist absolut korrekt. Was mich nur wundert ist die Tatsache, dass diese Karten bei anderen NAS in der Kompatibilitätsliste sind und ausgerechnet bei Deinem nicht. Ich hatte übrigens mit einer X540-AT2 ein ähnliches Problem, das liess sich allerdings damals über ein Firmware-Update der Karte lösen. Von daher, schau doch mal, ob Du für Deine X520 eins bekommen kannst - möglicherweise lieg es an solch einer einfachen Lösung...

Gruß,

Lauri

Zitat von Alv

Intressant, gilt das auch fürs TS-879U-RP?

Ich habe noch ein paar X520 und X710 rumliegen und ein TS-879 ohne 10G...

Lt. Kompatibilitätsliste Deiner NAS definitiv! Da sind sogar, im Gegensatz zu vielen anderen NAS, die Emulex-Karten aufgeführt... die laufen in meiner z.B. nicht, obwohl ich die da gerne nutzen würde (PCIe 3.0 im Gegensatz zu 2.0 der Intel-Karten).

Gruß,

Lauri

Also, was ich Dir sagen kann:

grundsätzlich läuft eine original Intel x520-DA2 in einer QNAP:

pasted-from-clipboard.png

Allerdings habe ich gesehen, dass Intel-Karten nicht in der Kompatibilitätsliste Deiner NAS stehen. Das bedeutet, dass Deine NAS entweder keine Intel-Netzwerkkarten unterstützt oder, dass Deine Karte keine original-Karte sondern lediglich eine chipkompatible Karte ist (die werden gern in der Bucht oder auf der

bekannten chinesischen Handelsplattform verkauft).

Gruß,

Lauri

Das ganze geht deutlich einfacher.

Nutze DFS, verwalte die NAS-Freigabe per DFS und weise die Freigaben per GroupPolicy den Benutzern zu.

Deine Benutzer brauchen sich dann gar nicht mehr individuell am NAS anzumelden UND sie haben die NAS-Freigaben als eigenständiges Laufwerk nach der Anmeldung zur Verfügung. Das kannst Du dann sogar individuell pro Benutzer einstellen.

Du solltest innerhalb einer Domäne nicht damit anfangen, Rechte und Zuweisung ausserhalb der Domänen-Umgebung zu verwalten. Unabhängig davon, dass das sehr schnell unwartbar wird, reißt Du Dir damit im Zweifel massive Sicherheitslücken.

Gruß,

Lauri

Wie immer bei dieser Netzwerkkarte im Rechner:

Stell bitte mal MagicPaket im GeräteManager für diese Karte auf 9k - dann klappts auch mit dem Transfer... (möglicherweise auch auf der NAS - die Kombi 10GBe im Rechner und 2,5GBe in der NAS hab ich bisher nicht getestet - bei 10/10 muss auf beiden Seiten MagicPaket auf 9k stehen)

pasted-from-clipboard.png

Aber ganz ehrlich? Was ist denn das für ein Dienstleister... zieht in einem Raid ne Platte obwohl er weiß, dass keine Sicherung vorhanden ist. Rebuild lief - da hat er schon extremes Glück gehabt. Dann geht die Platte kaputt (ok, kann bei Neuware durchaus vorkommen) und dann werden wild Platten gezogen? Wieder ohne vorher ne Sicherung zu machen? Jeder vernünftig denkende Dienstleister hätte Dir zumindest angeboten "kauf ne Backupplatte, wir ziehen die Daten und danach machen wir uns ans Raid". Aber 2x Platten ziehen ohne Backup, das ist schon nicht mehr grob fahrlässig, das ist russisches Roulette.

Gruß,

Lauri

Zur Ergänzung:

Wenn Du den Benutzernamen der NAS angibst, dann in der Form [NAS-IP]\Benutzername

Deine Meldung sieht für mich so aus, als wärst Du für die Uni in einem AD. Wenn Du entsprechend "nur" den Benutzernamen angibst, dann sucht er in der Domäne nach den Credentials und wird sie nicht finden. Daher in solchen Fällen IMMER beim Benutzer [NAS-IP]\ mit angeben.

[NAS-IP] ist durch die IP Deiner Nas zu ersetzen.

Gruß,

Lauri

Was wohl eindeutig zeigt: Beim vorherigen Update ist irgendwas gehörig schiefgelaufen. Aber schön, dass jetzt wieder alles funktioniert

Das würde ich in dem Fall definitiv machen. Es wäre nicht das erste Firmware-Update das nicht einwandfrei gelaufen ist und bei Dir hört sich das nach so einam Fall an. Das Update aber bitte nicht direkt auf der NAS sondern manuell mit dem PC herunterladen und dann über den QFinder durchführen...

Zitat von Austro-Diesel

QNAP hat uns mit dieser neuen Option "empfohlene Updates installieren" alle reingelegt

Öhm... nein? Ich mache ein Update meiner NAS. ich schau nach dem Update meine wichtigen Optionen an und finde einen Eintrag von ich nicht weiß, was er macht. Ich habe nun 2 Möglichkeiten:

- ich weiß nicht was das macht und schalte es aus

- ich weiß nicht was das macht, ignoriere es und lasse es an (wird schon nix passieren)

An welcher Stelle QNAP mich jetzt "reingelegt" haben soll, ist mir schleierhaft. Es ist meine NAS - ICH bin dafür verantwortlich. ICH - nicht QNAP, nicht irgendwer, ICH. Wenn ich also eine Einstellung, von der ich nicht weiß was sie eigentlich macht, einfach "eingeschaltet" lasse und mich zusätzlich nicht informiere, dann hat mich da eher niemand reingelegt... Wenn ich natürlich nach dem Update nicht mal schaue ob sich was geändert hat, dann ist auch das sicherlich nicht verschulden von QNAP. Da wurde nix untergeschoben, da wurde nur sichtbar, wieviele % der Anwender es völlig egal ist was da auf dem eigenen Gerät passiert. Und wenn dann QNAP tatsächlich auf die in der NAS gesetzte Einstellung zurückgreift, dann ist natürlich QNAP schuld. Frei nach dem Motto, "wenn der Bäcker nicht schwimmen kann, liegts an der Badehose"...

Gruß,

Lauri

Dass der Cache die VMs beschleunigt ist korrekt und steht ausser Frage. Da ich hier aber ganz bewusst ein 10GBe Netzwerk habe und auch größere Dateien von/auf die Nas übertrage, macht ein Cache hier keinen Sinn: Die Übertragung bricht sowohl lesend als auch schreibend ein. Grade auch auf iSCSI-LUN. Ich hatte, testweise, eine iSCSI-LUN eingerichtet, die kleiner als der NVMe-Cache ist (LUN 1TB, NVMe-Cache 2x 2TB Raid1). Die "Überlegung" dabei war, dass diese LUN komplett in den Cache passen müsste. Aber falsch gedacht, tatsächlich bricht die Übertragungsleistung unter den Wert komplett ohne Cache ein. Daher laufen derzeit meine iSCSI-LUN auf einem 2x 4TB SSD Raid 1 und eine weitere wird demnächst direkt auf dem NVMe-Raid 1 laufen. Von jedweder Form des "Caching" habe ich auf der NAs mittlerweile Abstand genommen. Er bringt mir auch auf den SMB-Verbindungen nicht wirklich einen Gewinn. Es laufen zwar noch ein paar VMs auf der NAS, die liegen aber auf der "Boot-SSD" und werden regelmäßig gesichert - es macht aber auch nix, wenn die im Fall eines Ausfalls der NAS mal ein paar Tage nicht laufen würden. Da diese aber eh auf einer SSD liegen, macht auch hier caching nicht wirklich Sinn. Ich hatte zwar auch die Überlegung evtl. qTier zu testen, aber nach der ein oder anderen Horrormeldung dazu hier im Forum weiß ich nicht, ob ich das wirklich machen möchte...

Gruß,

Lauri

Deine Variante

Zitat von i-production

- Oder wäre es besser SSDs für die Grafikdaten zu verwenden ? => 3x 2TB SSD RAID 5 | und dann 3x 8TB

ist definitiv sinnvoller. Ich hatte in meiner TS-673A 2 NVMe-Laufwerke als Cache, das kannst Du aber vergessen, die Leistung der NAS geht tatsächlich runter anstatt hoch - und das trotz NVMe. Das ganze bringt am Ende des Tages genau garnix, ausser dass es Geld kostet und frustet. Ich habe mittlerweile SSD im Raid als Laufwerke für einen iSCSI-Storage in der NAS und nutze die NVMe demnächst für eine weitere iSCSI-LUN. Das Thema Cache ist für mich leider gestorben - wobei es hier im Forum dazu auch diverse Beiträge gibt, die alle das Selbe (inkl. validen Testmessungen) vermelden: Lass es bleiben, Du ärgerst Dich am Ende nur.

PiHole läuft (zumindest über das Image "Pihole/Pihole") initial ausschließlich über die UID 0. Daher erst mal die Frage, kann es sein, dass Du den Admin-Account deaktiviert hast und das über einen "alternativen" Admin versuchst? Denn dann hast Du exakt das beschriebene Verhalten... Das "standardmäßige" Pihole-Image ist in der Tat etwas "anstrengend"...

Edit:

Ich glaub, das Geschreibsel trifft auf Dich nicht zu, ich habe gerade gesehen, dass Deine NAS eine ARM-CPU hat. Hast Du denn ein PiHole-Image das auf einer ARM-CPU läuft? Das "normale" läuft ausschließlich auf x86 CPU...

Zitat von dr_mike

Du hast ja auch sicherlich über PN (Konversation) angeschrieben.

Öhm, ja? Das steht doch auch in jedem Hinweis, dass man bitte per "PN" Kontakt aufnehmen soll Ist ja auch absolut verständlich, sonst würde der entsprechende Gutscheincode öffentlich auf der Pinnwand stehen und es gäbe massenhaft Beschwerden, dass der Code nicht funktioniert^^

Also ich kann sagen, dass ich in den letzten Wochen mehrfach Kontakt zum Benutzer speicher.de hatte und jedes Mal in max. 2 Tagen geantwortet wurde - in der Regel sogar innerhalb weniger Stunden. Nachvollziehen kann ich das daher von meiner Seite aus nicht.