rsync per ssh einer QNAP-NAS von Ubuntu-Server aus

[Nordlicht000]

Ich versuche gerade ein Backup mit rsync über ssh einzurichten.
Quelle: ein QNAP-NAS
Ziel: ein Selbstbau-NAS mit Ubuntu-Server 20.04 LTS
Da HBS3 nicht auf andere Laufwerke sichern kann außer auf externe USB-Laufwerk und andere QNAP-NAS, soll/muß das Backup vom Ubuntuserver aus starten.
Meine ersten Fehlversuche sind ab hier zu finden. Das das nun nichts mehr mit dem ursprünglichen Thema des Threads zu tun hat, mache ich hier einen neuen Tread auf.

Das Problem liegt offenbar erstmal hauptsächlich am Einloggen auf die QNAP per SSH-Key. Habe diese Anleitung versucht (dabei "All HAL-based Intel and AMD NAS" verwendet, weil mein NAS-Modell TS-453B" dort nirgends auftauchte), was aber bisher noch nicht funktioniert hat.
Inzwischen habe ich es geschafft, diese autostart.sh zu erstellen und wollte nun wie in dem HowTo beschrieben den auszuführenden Befehl dort eintragen, was auch geklappt hat. Der Inhalt der autostart.sh ist in QNAP unter "Hardware/Allgemein" zu sehen und das Häkchen ist bei "Benutzerdefinierte Prozesse beim Start ausführen" gesetzt. Ich wollte einfach eine im Home-Verzeichnis abgelegte authorized_keys_backup kopieren nach /root/.ssh/authorized_keys wie im HowTo erwähnt, aber leider verschwindet beim Neustart der QNAP nicht nur die authorized_keys, sondern auch die authorized_keys_backup, d.h. das Home-Verzeichnis wird bei jedem Neustart geleert.
Habe die authorized_keys_backup nun in einen Freigabeordner gelegt und den Pfad in der autostart.sh entsprechend angepaßt. Hatte mich dabei noch beim Pfad vertippt, was ich aber erst nach den Neustart gemerkt habe. Also nochmal von vorne... und dabei fast das umount vergessen... Kommandozeile ist
Die authorized_keys wird jetzt zwar beim Neustart der NAS nach /root/.ssh kopiert, aber beim Einlogversuch mit Putty mit dem Privat-Key kommt immernoch die Fehlermeldung "Server refused our key". Was fehlt da denn jetzt noch?
In der sshd_config ist der Eintrag "PubkeyAuthentication yes" auskommentiert, aber laut der Anleitung ist "Yes" die Voreinstellung bei QNAP. Kann sich natürlich inzwischen geändert haben, da die Anleitung sich ja auf eine ältere QNAP-Version bezieht. Aber wo stellt man das ein, damit das beim Neustart nicht wieder verschwindet so wie in der Anleitung erwähnt?

 

[Tommes]

Hi!

Bevor ich überhaupt anfange, tief Luft zu holen, ein paar Fragen. Du schreibst…

Quelle: ein QNAP-NAS
Ziel: ein Selbstbau-NAS mit Ubuntu-Server 20.04 LTS
Da HBS3 nicht auf andere Laufwerke sichern kann außer auf externe USB-Laufwerk und andere QNAP-NAS, soll/muß das Backup vom Ubuntuserver aus starten.

Du möchtest dich von deinem Ubuntu Server aus, auf dein QNAP NAS per SSH verbinden, um Daten per rsync von deiner QNAP NAS auf deinen Ubuntu Server abzulegen. Richtig?

Somit wird die SSH Verbindung von deinem Ubuntu Server aus, in Richtung QNAP NAS aufgebaut. Richtig?

Wenn du auf diese Weise Daten per rsync von deiner QNAP abholen möchtest, reden wir von einem Pull Backup. Pull deshalb, weil du die Daten von deiner QNAP auf deinen Ubuntu Server ziehst. Richtig?

Verwendest du für SSH den Standardport 22 oder hast du einen abweichenden Port gewählt?

Warum frage ich das alles? Weil du dann auf deinem Ununtu Server für den entsprechenden Benutzer im Unterordner /.ssh einen privaten- wie auch einen öffentlichen Schlüssel (Key) erstellen musst und du den öffentlichen Schlüssel in die authorized_keys deiner QNAP einfügen musst. Auf deiner QNAP muss das ebenfalls in dem entsprechenden Benutzerordner unter /.ssh erfolgen. Auch müssen bzw. sollten die Dateirechte noch angepasst werden. Aber dazu kommen wir wohl noch.

Da du ein Pull-Backup ausführen möchtest, ist die Schreibweise von rsync eine andere als bei einem Push-Backup. Aber auch hierzu später mehr.

Und nur fürs Protokoll. Ich hab für sowas ein Programm geschrieben, welches aber nur auf einer Synology NAS läuft, daher kann ich noch nicht abschätzen, ob wir hier zu einem Ergebnis kommen werden. Anderseits kochen die alle nur mit Wasser. Schauen wir mal.

Tommes

 

[Nordlicht000]

Du möchtest dich von deinem Ubuntu Server aus, auf dein QNAP NAS per SSH verbinden, um Daten per rsync von deiner QNAP NAS auf deinen Ubuntu Server abzulegen. Richtig?

Richtig.

Somit wird die SSH Verbindung von deinem Ubuntu Server aus, in Richtung QNAP NAS aufgebaut. Richtig?

Später mal: ja

Aber um erstmal auzutesten, ob das einloggen per SSH mit diesen Keys statt Username/Paßwort überhaupt funktioniert, habe ich das erstmal vom Windows-Rechner aus mit putty ausprobiert (ich habs nicht so mit der Kommandozeile ) und wenn das funktioniert brauche ich ja bloß den Key auf den Ubuntu-Server zu kopieren (hoffe ich jedenfalls mal) und dann kann ich mich anschließend um rsync kümmern. Ich wollte halt nicht alles auf einmal machen, sondern Schritt für Schritt, damit ich weiß ob es am SSH-Login hängt oder am rsync. Aber ich bekomme das SSH-Login per Key schon nicht hin (SSH-Login auf die QNAP per User/Paßwort funktioniert einwandfrei).

Einen ersten einfachen Test mit rsync auf dem Ubuntu-Server hatte ich schon gemacht (einfach nur ein eigens erstelltes kleines Testverzeichnis auf dem UbuntuServer mit rsync kopiert auf eine Backup-Partition des gleichen Servers. Das hat schonmal funktioniert. War aber nur eine simple Synchronisation. Mit den ganzen Einstellungen für rsync beschäftige ich mich erst später. Erstmal möchte ich diesen SSH-Login mit Keys auf die QNAP hinbekommen.

Wenn du auf diese Weise Daten per rsync von deiner QNAP abholen möchtest, reden wir von einem Pull Backup. Pull deshalb, weil du die Daten von deiner QNAP auf deinen Ubuntu Server ziehst. Richtig?

Richtig.

Verwendest du für SSH den Standardport 22

Richtig.

Weil du dann auf deinem Ununtu Server für den entsprechenden Benutzer im Unterordner /.ssh einen privaten- wie auch einen öffentlichen Schlüssel (Key) erstellen musst und du den öffentlichen Schlüssel in die authorized_keys deiner QNAP einfügen musst.

Genau das versuche ich ja die ganze Zeit, nur eben erstmal vom Windows-Rechner aus (bevor ich am Ubuntu-Server was herummurkse) mit putty. Die Schlüssel habe ich mit puttygen erzeugt und für den öffentlichen Schlüssel eine authorized_keys im root/.ssh-Verzeichnis auf der QNAP erstellt. Was ein ziemliches gefummel, daß der nach einem Neustart der QNAP überhaupt noch vorhanden war, da alles im Home-Verzeichnis nach dem Neustart verschwindet. Habe dann eine autostart.sh erstellt, die mir die authorized_kesy wieder in das root/.ssh-Verzeichnis kopiert beim Start der QNAP (nach dieser Anleitung).

Auf deiner QNAP muss das ebenfalls in dem entsprechenden Benutzerordner unter /.ssh erfolgen.

Tja, das ist jetzt die spannende Frage. Laut der Anleitung soll man die authorized_keys in den root/.ssh-Ordner kopieren. Anmelden tut man sich aber mit dem Administrativen User "admin". Einen root-User gibt es nicht. Laut der Info im QNAP- Controlpanel bei "Netzerk/SSH" kann man sich nur mit dem Adminkonto per SSH auf die QNAP einloggen und das ist bei QNAP der User "admin". Müßte die authorized_keys dann nicht eher im Home-Verzeichnis des admin-Accounts gespeichert werden? Wobei der Ordner .ssh im Root-Verzeichnis lediglich ein Link ist zu /etc/config/ssh ist.

Auch müssen bzw. sollten die Dateirechte noch angepasst werden.

So sieht das .ssh-Verzeichnis im root-Verzeichnis auf der QNAP aus:

lrwxrwxrwx  1 admin administrators   15 2022-04-15 17:36 .ssh -> /etc/config/ssh

 

[the other]

Moinsen,
hier auch noch ein paar links dazu generell. Mit etwas Abstraktion solltest du das gut für dein setting umsetzen können, also wenn du zukünftig das vorhast

selbstbau-nas > per ssh mit pubkey-auth > qnap

dann meldest du dich per ssh auf deinem selbstbau an, erstellst dort das Schlüsselpaar, parkst den privaten Teil auf deinem selbstbau, schickst den öffentlichen an qnap.
Kannst du ja vorher erst durchspielen mit
pc (hier Schlüsselpaar erstellen), den privaten auf dem pc belassen, den öffentlichen aufs selbstbau-nas packen, dann klappt auch dorthin die pubkey-auth für ssh (und du sammelst Praxis).

Hier die links:
Ssh mit Zertifikaten absichern – Synology Wiki
RESOLVED: Logging into Synology SSH using a key instead of a password | Synology Community
OpenSSH Public Key Authentifizierung unter Ubuntu – Thomas-Krenn-Wiki
SSH Login mit Public-/Private-Key Authentifizierung - techgrube.de
Putty: Anmeldung über Public-Key-Authentifizierung | WindowsPro

 

[blurrrr]

Btw Du kannst Dir auch nochmal luckyBackup anschauen (ist mir grade noch über den Weg gelaufen)

Was Dein eigentliches Problem angeht... Leg auf der Ubuntu-Kiste mal folgende Datei an:

~/.ssh/config

Da packste dann mal diesen Inhalt rein:

Host qnap
HostName qnap-ip
User admin
IdentityFile ~/.ssh/qnap.key

Den Client-Key zum Login auf der QNAP legst Du dann auch noch in das Verzeichnis auf der Ubuntu-Kiste ("~/.ssh/qnap.key", oder wo auch immer Du willst, aber in der config muss der Pfad stimmen).

Generell gelten die "globalen" SSH-Einstellungen (ssh_config), mit der config-Datei (~/.ssh/config) kannst Du aber Verbindungen von Deinem aktuellen User zu bestimmten Hosts gezielt konfigurieren. Du verbindest Dich dann via admin@qnap-ip und anhand der config-Datei wird dann auch der passende Key bei einer Verbindung zur hinterlegten Host-IP (hier "qnap-ip") hergestellt.

In der von Dir verlinkten Anleitung ist die Rede davon, dass die Leute bzgl. des Keys auf der QNAP hingehen und sich dort eine Sonderlösung via "autorun.sh" erarbeitet haben. Insofern ist erstmal davon auszugehen, dass der Key auf der QNAP einen Neustart wohl eher nicht überlebt. Da solltest Du ggf. nochmal genauer schauen... Primär erstmal mit einem anderen Client wie putty o.ä. testen kann man sicherlich machen, ich persönlich finde es direkt über die Shell einfacher (Cursor hoch, letzten Befehl wiederholen). Wäre ja tendentiell auch nur ein "ssh admin@qnap-ip".

Wenn Du die SSH-Config auf der QNAP geändert hast, müsste auch nochmal der SSH-Dienst neugestartet werden. Danach unbedingt überprüfen, ob die Änderung den Neustart des Dienstes überlebt hat. Mitunter auch einfach nochmal prüfen, ob der Eintrag nach einem Reboot des QNAP-NAS auch noch vorhanden ist. Falls das alles nicht passt, wird es wohl auf - in der Anleitung erwähnten - autorun.sh-Lösung hinauslaufen. Dazu kann ich aber nicht viel sagen, da ich mit QNAP eigentlich so ziemlich genau garnichts an der Mütze habe.

Bin mal gespannt, wie es weiter geht hier...

 

[Tommes]

Nun gut. Am Ende möchtest du doch eine SSH Verbindung von deinem Ubuntu Server in Richtung QNAP aufbauen, daher spielt PuTTYgen erstmal gar keine Rolle. Du nutzt PuTTY ja, um dich sowohl auf deinen Ubuntu Server, als auch auf deine QNAP aufzuschalten, richtig? Und wenn du in PuTTY einen Key mit PuTTYgen generiert hast und du diesen in die authorized_keys deines Ubuntu Servers und deiner QNAP implementierst, dann kannst du zwar eine passwortlose Verbindung von PuTTY auf den jeweiligen Server aufbauen, nicht aber zwischen deinen Servern. Um deine beiden Server miteinander zu verbinden, musst du zwischen diesen beiden einen Schlüssel austauschen. PuTTY ist hierbei nur das Tool, worüber du das alles bewerkstelligen kannst. Ansonsten hat PuTTY mit der ganzen Sache überhaupt nichts zu tun.

Du musst also auf deinem Ubuntu Server eine SSH-Ordnerstruktur aufbauen, einen privaten sowie öffentlichen Key erzeugen und den öffentlichen Key dann in deine QNAP fummeln. Dann kann’s du dich von deinem Ubuntu Server aus auf die QNAP aufschalten um den rsync abzufeuern. Wie man das alles einrichtet, kann ich gerne erklären, jedoch musst du schauen, ob das für dich so passt, da ich zwar ein Ubuntu habe, jedoch keine QNAP.

Zum Thema root bzw. admin. Ich kenne das so, das man die SSH-Ordnerstruktur immer im Benutzer-Home-Ordner des Benutzers erstellt, von dem man aus bzw. mit dem man sich verbinden will. Der Benutzer-Home-Ordner des Systembenutzers root liegt i.d.R. unter /root wohingegen alle anderen inkl. admin unter /home/admin etc. liegen sollten. Bei Synology liegen diese Ordner ganz woanders, aber das ist jetzt nicht wichtig.

Ob QNAP eine SSH-Ordnerstruktur für root erlaubt oder nicht, kann ich nicht sagen. Scheinbar wird das aber nach einen Neustart zurückgesetzt, wenn ich dich richtig verstanden habe. Eine passwortlose SSH Verbindung mit root einzugehen, sollte man sich zu dem auch wirklich gut überlegen. Vielleicht solltest du es einfach mal als admin, oder einem anderen Benutzer mit administrativen Rechten versuchen.

Aber ich breche hier mal ab, da hier grad zu viele Beiträge aufpoppen. Wir sollten also aufpassen, das wir hier nicht durcheinander kommen.

 

[the other]

Moinsen,
mal von allem abgesehen:
ich mag mir irgendwie nicht recht vorstellen, dass es keine Möglichkeit gibt, dass der key abgelegt wird und einen Neustart nicht überlebt.
Zumindest bei Synology war das damals kein Problem, einmalig den Key hinterlegt und die von @blurrrr genannte sshd_config angefasst...hält bis heute (trotz Neustart, Update, großem Update usw.)...

Einziges "Problem" war, dass sich nur ein user mit Adminrechten über ssh einwählen kann. Es gab da zwar zwischenzeitlich mal einen Tweak, der es auch "normalen" usern erlaubte, der war dann aber mit irgendeinem Update nicht mehr möglich, wenn ich mich recht erinnere.

Sei es drum. Sag Bescheid, ob du den Zugriff per pubkey-auth hinbekommst oder ob noch was klemmt...

 

[Nordlicht000]

Leg auf der Ubuntu-Kiste mal folgende Datei an:

~/.ssh/config

Ich habe mich mit einem administrativen Account (nicht root) auf dem UbuntuServer per SSH eingeloggt. Welches Verzeichnis ist dann nun ~/.ssh/config , d.h. was bedeutet die Tilde? Ist es das Home-Verzeichnis des administrativen Accounts? Habe dort die config-Datei mit dem von dir geposteten Inhalt (natürlich mit der richtigen IP) gespeichert. In das gleiche Verzeichnis habe ich auch den von putty erzeugten privaten Key gespeichert.
Aufruf von ssh admin@IP bringt aber nur den ganz normalen SSH-Login mit Username und Paßwort auf die QNAP. Nix über Keys. Allerdings kommt auch nicht die Fehlermeldung vom Windows-Putty mit "Server refused our key".

Insofern ist erstmal davon auszugehen, dass der Key auf der QNAP einen Neustart wohl eher nicht überlebt.

Das hatte ich schon ausprobiert. Das überlebt einen Neustart nicht. Daher ja die Sache mit der autostart.sh.

Zum Thema root bzw. admin. Ich kenne das so, das man die SSH-Ordnerstruktur immer im Benutzer-Home-Ordner des Benutzers erstellt, von dem man aus bzw. mit dem man sich verbinden will. Der Benutzer-Home-Ordner des Systembenutzers root liegt i.d.R. unter /root wohingegen alle anderen inkl. admin unter /home/admin etc. liegen sollten.

Tja, ich habe aber keine Home-Verzeichnisse meiner auf der QNAP eingerichtenten User, d.h. auch /home/admin existiert nicht. Diese werden von QNAP nur erstellt, wenn ich im ControlPanel bei Freigabeordner "Startverzeichnis" aktiviere. Das möchte ich aber nicht, da dann alle Homeverzeichnisse automatisch auch Freigaben sind (habe 3 normale User eingerichtet) und daher in der Netzwerkumgebung von Windows zu sehen. Diese möchte ich aber nicht haben, da ich nur alleine die QNAP nutze und ich für die Freigaben eigene Verzeichnisse angelegt habe.
So sieht das auf der QNAP aus:

[/] # cd home
[/home] # ls -al
total 0
drwxr-xr-x  4 admin administrators  80 2022-03-23 22:36 ./
drwxr-xr-x 23 admin administrators 560 2022-04-15 17:06 ../
drwxr-xr-x 14 admin administrators 680 2022-04-15 17:07 httpd/
drwxr-xr-x  3 admin administrators 180 2022-04-15 17:06 Qhttpd/

 

[frosch2]

Ich würde an dies Sache anders herangehen.
Wozu Schlüssel im eigenen kleinen LAN?
Man kann das freigegebene Verzeichnis auf der QNAP doch mounten, dann ist das wie ein lokales Verzeichnis.
Dann sichert man das Verzeichnis mit der Software, die man mag.
Ich mag rsnapshot

 

[the other]

Moinsen,
die ~ bedeutet in diesem Zusammenhang wie du richtig vermutest den Verweis auf das /home des jeweils angemeldeten users.

Dass weiterhin der Zugang per Passwort erfolgt und nicht per key liegt aller Wahrscheinlichkeit daran, dass die sshd_config noch nicht angepasst wurde.
Dort muss eingestellt werden, dass der Zugriff ggf. nur noch via pubkey erfolgen darf (und einige andere Dinge).
EDIT: wobei vorher natürlich sichergestellt sein muss, dass das auch funktioniert, sonst eher doof
EDIT2 (sorry): versuchen, indem du die Anmeldung mit schlüssel "erzwingst" mit der option -i und der Angabe, wo der key liegt...

Ohne jetzt die qnap Besonderheiten zu kennen: imho wäre es am einfachsten, wenn du für den Zugriff ein eigenes Adminkonto einrichtest, diesem die /home Verzeichnissoption gibst, dort dann im versteckten Ordner ssh den Schlüssel hinterlegst. Der übersteht dann auch den Neustart (oder löscht qnap das /home Verzeichnis der user?).
Das Problem später wird dann nämlich sein imho, dass du den keys und Ordnern, in denen diese liegen, noch ein bestimmtes Niveau an Zugriffsrechten geben musst, damit nur der "richtige" user zugreifen darf (sonst funzt es eh nicht und bricht mit einer Fehlermeldung ab a la "Rechte nicht strikt genug".

Da steht dann die Entscheidung an, ob du den Weg gehst, dass die /home Verzeichnisse unter Windows angezeigt werden (was aber sicher kaschiert werden kann, oder?), oder ob du die ssh Nummer "sauber" lösen willst mit /.ssh Ordner im eigenen /home...
Wenn ich eh der einzige Nutzer wäre, wüsste ich, was für mich der Weg wäre...aber das muss jede*r selbst entscheiden...

 

[the other]

Moinsen @frosch2 ,
wenn ich @Nordlicht000 richtig gelesen habe, dann soll da was für einen reinen backup Server entstehen...(korrigiert mich gerne).
FALLS dem so ist, dann wäre eine dauerhafte Verbindung eher nicht so schlau.

Schön wäre es, wenn sich der backupserver nach Konfig mit dem Quell-Server verbindet, die Daten für das backup zieht und die Verbindung dann wieder abbaut.
Und dafür muss dann eben entweder die Name / Passwort Kombi hinterlegt werden (okay im eigenen Netz) oder eben mit keys (ohne passphrase!!) gearbeitet werden (okayer im eigenen Netz ).

 

[Nordlicht000]

Ha, nach dieser Anleitung habe ich jetzt vom UbuntuServer aus den Key erzeugt und mit dem dort beschriebnenen Befehl auf die QNAP kopiert. Nun kommt beim Login mit

ssh -i .ssh/qnap.key admin@IP

keine User/Paßwortabfrage mehr. Scheint also funktioniert zu haben.
Seltsam, das es mit dem von puttygen erzeugten Key nicht funktioniert hat. Weiß jemand warum das so ist? Müßte doch von Windows aus mit putty genauso gehen?

Habe nun aber mal auf der QNAP nachgesehen: finde aber nicht, wo der qnap.key.pub hin kopiert wurde. Nach /home/ jedenfalls nicht. Und auch nicht in /etc/ssh, wo bereits von QNAP erzeugte Keys liegen. Wo ist der kopierte Key also geblieben?
Gestartet habe ich die QNAP auch noch nicht, d.h. ob das einen Naustart überlebt weiß ich noch nicht. Das kann ich erst morgen ausprobieren, die die QNAP z.Zt. mit anderen Aufgaben beschäftigt ist. Vorher will ich aber die qnap.key.pub-Datei finden und sichern.

wenn du für den Zugriff ein eigenes Adminkonto einrichtest, diesem die /home Verzeichnissoption gibst,

Bei Qnap geht nur "alles oder nichts", d.h. entweder haben alle User ein Home-Vezeichnis oder keines.

(oder löscht qnap das /home Verzeichnis der user?

Ja. Solange "Startverzeichnis" im ControlPanel nicht aktiviert ist, werden die kompletten Home-Verzeichnisse beim Neustart gelöscht.

oder ob du die ssh Nummer "sauber" lösen willst mit /.ssh Ordner im eigenen /home...

Daher geht dieses wohl auch nicht. Wird nach dem Neustart auch weg sein.

Man kann das freigegebene Verzeichnis auf der QNAP doch mounten, dann ist das wie ein lokales Verzeichnis

Hi, das wäre meine absolute Notlösung gewesen, wenn ich das mit dem SSH-Key nicht hinbekomme. Aber birgt das nicht auch wieder Gefahren bzgl. Verschlüsselungstrojaner? So ein Ungeziefer breitet sich doch über alle verbundenen Netzwerklaufwerke aus.

dann soll da was für einen reinen backup Server entstehen...

Korrekt.

Schön wäre es, wenn sich der backupserver nach Konfig mit dem Quell-Server verbindet, die Daten für das backup zieht und die Verbindung dann wieder abbaut.

Ja, so hätte ich das gerne.

 

[Tommes]

Schön wäre es, wenn sich der backupserver nach Konfig mit dem Quell-Server verbindet, die Daten für das backup zieht und die Verbindung dann wieder abbaut.

Da muss ich doch gleich mal ein wenig die Werbetrommel für Basic Backup rühren. Leider gibt’s das nur für Synology NAS Systeme.

Ich brauche für den ganzen SSH Quatsch auch keine config anlegen oder in der sshd_config rumfuchteln. Solang man sich nicht als root verbinden will, sollte das auch ohne das alles funktionieren. Und SSH Authentifizierung im Heimnetzwerk ist durchaus sinnvoll und angebracht. (Meine Meinung)

 

[Tommes]

Seltsam, das es mit dem von puttygen erzeugten Key nicht funktioniert hat. Weiß jemand warum das so ist?

Hatte ich bereist beschrieben

 

[frosch2]

Wenn man einen NFS-Mount anlegt, brauch man kein Passwort und keine Schlüssel.
Man muss auch nicht dauerhaft mounten, ein

mount

oder

umount

kann man per cron oder besser in einem Skript ausführen.
Ich möchte hier nicht gegen die bisherigen Ausführungen argumentieren.
Man kann sich es aber auch einfach machen, gerade wenn @Nordlicht000 mit der Konsole nicht vertraut ist.

 

[the other]

Moinsen,

Wo ist der kopierte Key also geblieben?

Das kannst uns sagen...wohin hast du ihn den mit dem Befehl
ssh-copy-id

kopiert?

 

[Nordlicht000]

Hatte ich bereist beschrieben

Nein, dui hast was anderes beschrieben, namlich warum es zwischen QNAP und UbutuServer mit putty nicht funktioniert. Ich hatte aber versucht, mich von Windows aus (dort ist putty installiert) per SSH mit dem von putty generierten Key auf die QNAP einzuloggen und nicht vom UbuntuServer zu QNAP. Es sollte doch auch möglich sein, sich per von putty auf dem Windows-PC generierten SSH-Key von Windows aus auf die QNAP einzuloggen. Was ist der Unterschied zu einem auf dem UbuntuServer generierten Key mit Login vom UbuntuServer auf QNAP zu einem auf dem Windows-Rechner generierten Key mit Login vom Windows-Rechner auf QNAP? Der einzige Unterschied ist, daß das eine Windows und das andere Linux ist. Aber ein SSH-Login vom Windows-Rechner auf QNAP mit User/Paßwort ist doch auch möglich. Wo ist also der Haken dabei?

wohin hast du ihn den mit dem Befehl
ssh-copy-id

kopiert?

Hierhin:

 ssh-copy-id -i qnap.key.pub admin@IP

Wo isser damit hingekommen?

Edit: grep sucht und sucht und sucht...

 

[the other]

Moinsen,
Ähhh...keine Ahnung? Dank mangelnder qnap Erfahrung kann ich dir nicht sagen, wo da ggf ein Standardordner genutzt wird...
Eigentlich fehlt der Teil, wo du eben ne Angabe zum Ordner machst...
Ansonsten sollte er eigentlich im Ordner ~/.ssh liegen

 

[Nordlicht000]

Wenn die Tilde den Home-Ordner bezeichnet, dann gibt es diesen nicht (weder Home-Ordner noch .ssh-Ordner).
Es gibt nur einen /etc/ssh und dort drin ist die Datei nicht gelandet.

 

[the other]

Moinsen,
Ein ls -la gibt nach Anmeldung als admin nix?