SSH mit eigenen/mehreren Schlüsselpaaren

Hinweis: Nach dem 31.12.2025 ist eine Registrierung nicht mehr möglich, nutze die verbleibenden Tage!
    • Neu

    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

    • Neu

    Hi,

    müsste ich mir auch mal ansehen.

    Ich hatte das auf einem NAS mit eigenen Keys mal eingerichtet, aber nur von einen Host und Nutzer.


    Gruss

    • Neu

    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

    • Neu

    Ah, über die GUI? Das habe ich nur per SSH gemacht, aber ob das auch über die GUI geht!?

    Mir war gar nicht bewußt, daß dann auch auf das Key-File zugegriffen wird. :huh:

    Da muss ich wahrscheinlich passen, ich dachte wir reden nur von SSH Zugriffen.


    Gruss

    • Neu
    Zitat von Laurenzis

    - bei jedem Verbindungsversuch bei dem ich nicht explizit den private key angebe, wird automatisch und immer der private key "id_rsa" genutzt

    Das ist auch der Default bei ssh.

    Zitat von Laurenzis

    - id_rsa ist bei QNAP nur ein link auf die Datei "ssh_host_rsa_key".

    Bei mir nicht. Ich habe ohne Probleme eigene Dateien dort ablegen können, und ich erinnere mich nicht, etwas Spezielles gemacht zu haben. Zeig mal ein ls -l auf den Link, so dass der Pfad sichtbar wird, um sicher zu gehen, dass wir über dieselbe Datei reden.


    Dann ist mir nicht klar, wie du per ssh auf die GUI zugreifst. Bei mir funktioniert das über einen ssh-Tunnel, den ich aber manuell aufbaue.

    Oder meinst du einen ssh-Zugriff in HBS3, den HBS3 automatisch aufbaut (also nicht über die GUI), der aber über die GUI konfiguriert wird?

    • Neu

    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:

    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:

    Code
    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).

    2 Mal editiert, zuletzt von Laurenzis ()

    • Neu

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

    • Neu

    Die Datei truenas-test gibt es in deinem ssh-Verzeichnis nicht. Und wenn es sie gibt, muss sie auch die Dateirechte 600 besitzen.

    ssh ist mit den Dateirechten sehr kleinlich. Und wenn da was nicht stimmt, gibt es keine Fehlermeldung, sondern die Datei oder der Schlüssel wird einfach nicht benutzt.

    • Neu

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

    Aktuelles Verzeichnis:

    Aktuelle Config:

    Code
    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.

    Einmal editiert, zuletzt von Laurenzis ()

    • Neu

    Ich habe es aus Neugier einmal bei mir ausprobiert.

    Sowohl bei Linux als auch bei qts beschwert er sich über die IP-Adresse im Eintrag Hostname, davon abgesehen wird bei beiden Systemen, also auch bei qts, die config-Datei verwendet. Mit anderen Worten: Es liegt kein qts-Problem vor, sondern prinzipiell funktioniert es bei qts auch.

    Damit ist die Frage, was bei dir anders als bei mir ist. Kommentiere mal für einen Test mit einem # die Zeilen Host und Hostname aus, damit die Konfigurationsdatei bei jedem Host gezogen wird und ein falsch geschriebener Hostname als Fehlerursache ausgeschlossen wird.

    Zitat von Laurenzis

    sehe ich bei ssh -vvv

    Den Parameter -vvv brauchst du übrigens nicht. Bei der Abfrage der Passphrase zeigt ssh an, für welchen Key, und damit siehst du, ob der Eintrag in der config-Datei seine Wirkung zeigt.

    • Neu

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


    Code
    [~] # 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 ;)