Wenn mit ssh-copy-id nicht funktioniert, kannst Du den Public-Key (meist id_rsa.pub) auch manuell am Zielserver einpflegen (nicht ersetzen!). Das ist üblicherweise:
/homepfad/.ssh/authorized_keys
Wie das mit GUI gemacht wird, kenn ich mich noch nicht aus. Bei QuTS Hero kann man den Public-Key für Benutzer Einpflegen, wie das bei QTS ist, weiß ich leider nicht.
Anthracite ist doch ein Crack was SSH Keys etc. angeht... hast Du eine Idee?
postschlumpf: wenn es um CLI (also über SSH) geht, habe ich Dir ja bereits Information geliefert. Nur den genauen Pfad kenne ich nicht und müsstest Du mal nachschauen. Mögliche befehle sind: find, grep, vi, tee, ... 
Anders gefragt, weil bis jetzt nicht ersichtlich ist: Bist Du fit in Linux/CLI oder brauchst Du genaue Befehle von uns vorgekaut?
Oder ist es eine Frage an Anthracite?
Jop... wenn sie eine Idee hat wird sie sich schon melden... und wenn nicht bestimmt auch
Hilft Dir das weiter?
https://wiki.qnap.com/wiki/SSH…To_Set_Up_Authorized_Keys
Bin grad nicht bei QNAP um das zu überprüfen, kann gerne heute Abend nachschauen.
Ich greife über ssh auf das NAS zu. Es wäre daher gut, wenn jemand den Terminal-Befehl kennen würde.
Klar gibt es die Befehle. vi oder echo zum Beispiel .
Vorgehen:
Du loggst dich per ssh auf deinem Backup-Server ein mit dem User, der dort für das Backup genutzt wird.
Wenn noch nicht vorhanden, legst du im Home des Users das Verzeichnis .ssh mit mkdir an.
ll -d .ssh
drwx------ 2 Anthracite administrators 4.0K 2021-05-12 21:45 .ssh/Wichtig:
Die Rechte müssen rwx------ sein (mit chmod 700 .ssh setzen) und der Eigentümer muss derjenige sein, um dessen Home-Verzeichnis (gegebenenfalls mit chown ändern) es sich handelt. ssh ist sehr pingelig, was diese Rechte betrifft. Stimmen sie nicht, funktioniert der Login über ssh-Keys nicht.
Jetzt hängst du deinen öffentlichen Schlüssel mit echo an die Datei authorized_keys an, z. B.
echo "ssh-rsa AAAA...== xxxx@nas" >> .ssh/authorized_keys
ll .ssh/authorized_keys
-rw------- 1 Anthracite everyone 5.1K 2021-05-12 21:45 .ssh/authorized_keysWichtig sind auch hier Rechte (diesmal 600) und Eigentümer der Datei.
Ein Nachteil der Lösung ist, dass so weit ich weiß HBS die SSH-Passphrase für deinen privaten Schlüssel nicht speichert. Daher funktioniert das nur, wenn dein privater Schlüssel keine (bzw. eine leere) Passphrase hat. Das heißt aber, dass ein Angreifer, der auf deinem Ursprungs-NAS (also das NAS, von dem aus das Backup gestartet wird) hat einbrechen können, ohne weiteres Passwort auch auf den entfernten Server kommt.
Das Problem kannst du lösen, indem du
1) in authorized_keys vor dem Schlüssel des entfernten Servers ein Kommando angibst, z. B.
command="rsync --server --daemon ." ssh-rsa AAAA...(wobei ich mittlerweile als Kommando immer ein Skript nehmen würde, in dem die Variable $SSH_ORIGINAL_COMMAND ausgewertet wird, die erlaubten Kommandos ausgeführt und alles andere in einer Datei protokolliert).
und
2) einen weiteren ssh-Schlüssel in einer anderen Schlüsseldatei anlegst, diesen
ebenfalls in die authorized_keys des fernen Servers schreibst, aber ohne Einschränkung auf ein Kommando, und den nutzt du, indem du dich mit ssh -i einloggst.
Wenn du dann zusätzlich den SSH-Login sicherer machen willst, indem du Anmeldungen am entfernten Server ausschließlich über ssh-Keys zusässt, dann hast du dir aber noch was vorgenommen (so der entfernte Server von Qnap ist). 
Es geht aber, und einmal eingerichtet läuft es stabil.
Ist der entfernte Server hingegen nicht von Qnap, ist das leicht einzurichten.
