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

[Nordlicht000]

Nach der Anmeldung muß am erst mit "Q" aus der Management-Console raus und zur normalen Shell zu kommen (muß man auch noch mit "Y" bestätigen). Wie ich das überspringen kann weiß ich auch noch nicht.
Edit: gefunden! Kann man in der Weboberfläche im Control-Panel unter "Allgemeine Einstellungen"/"Console management" deaktivieren.

Danach gibt es dieses:

[~] # ls -al
total 40
drwxr-xr-x  2 admin administrators  260 2022-04-15 20:27 ./
drwxr-xr-x 23 admin administrators  560 2022-04-15 17:06 ../
-rw-r--r--  1 admin administrators  415 2022-04-15 21:44 .bash_history
-rw-r--r--  1 admin administrators  175 2004-10-09 04:49 .bash_logout
-rw-r--r--  1 admin administrators  161 2004-10-09 04:49 .bash_profile
-rw-r--r--  1 admin administrators 1687 2007-07-18 12:24 .bashrc
lrwxrwxrwx  1 admin administrators    6 2022-04-15 19:01 .BitTornado -> ../tmp/
-rw-r--r--  1 admin administrators   36 2022-04-15 17:06 .buzzer_warnning.conf
-rw-r--r--  1 admin administrators 6526 2007-07-11 11:35 index_default.html
-rw-r--r--  1 admin administrators   27 2007-01-29 10:47 .profile
lrwxrwxrwx  1 admin administrators   15 2022-04-15 17:36 .ssh -> /etc/config/ssh/
-rw-------  1 admin administrators  747 2022-04-15 20:27 .viminfo
-rw-r--r--  1 admin administrators  923 2022-04-15 17:03 .vimrc

und das .ssh-Verzeichnis gibt dieses:

[~] # cd .ssh
[~/.ssh] # ls -al
total 44
drwxr-xr-x  2 admin administrators  4096 2022-04-15 17:36 ./
drwxr-xr-x 52 admin administrators 12288 2022-04-15 21:49 ../
-rwxrwxrwx  1 admin administrators   861 2022-04-15 21:05 authorized_keys*
lrwxrwxrwx  1 admin administrators    16 2018-12-24 15:45 id_rsa -> ssh_host_rsa_key
lrwxrwxrwx  1 admin administrators    20 2018-12-24 15:45 id_rsa.pub -> ssh_host_rsa_key.pub
-rw-r--r--  1 admin administrators   188 2022-04-15 17:36 sshd_config
-rw-r--r--  1 admin administrators    17 2022-04-15 17:36 sshd_user_config
-rw-------  1 admin administrators   668 2018-12-24 16:08 ssh_host_dsa_key
-rw-r--r--  1 admin administrators   605 2018-12-24 16:08 ssh_host_dsa_key.pub
-rw-------  1 admin administrators  1679 2018-12-24 16:08 ssh_host_rsa_key
-rw-r--r--  1 admin administrators   397 2018-12-24 16:08 ssh_host_rsa_key.pub

Die Datei authorized_keys war der von Putty erzeugte Key, der aber nicht funktionierte. Den hatte ich dort hinein kopiert gehabt. Die ssh_host_...-Dateien waren schon dort. Sind wohl Standarddateien von QNAP?
Aber die per ssh kopierte qnap.key.pub ist dort nicht zu finden. Das .ssh-Verzeichnis ist ja nur ein Link zu /etc/config/ssh und dort hatte ich ja als erstes nachgesehen gehabt.

Wo würde man den Schlüssel denn hinkopieren wenn es keine Home-Verzeichnisse gibt?

 

[Barungar]

Also soweit ich weiß, müsste das ssh-Verzeichnis für den admin bei QNAP das hier sein: /share/homes/admin/.ssh/
Es sollte ausreichen die Dateien, wie z.B. die authorized_keys oder die known_hosts, dort zu positionieren.
Und nein, ein mit Puttygen erstellter Key hat noch NIE bei einem openSSH selbst funktioniert. Dafür nimmt man ssh-keygen

 

[Nordlicht000]

Also soweit ich weiß, müsste das ssh-Verzeichnis für den admin bei QNAP das hier sein: /share/homes/admin/.ssh/

Ein solches Verzeichnis ist nicht vorhanden. Das gibt es wahrscheinlich nur wenn "Startverzeichnis" im ControlPanel aktiviert ist?
in /share liegen die ganzen Freigabeverzeichnisse und jede Menge Verzeichnisse mit HDA (B, C usw)_DATA. Da ist aber nix drin.
Dann gibt es in diesem Verzeichnis noch CACHEDEV1_DATA bis CACHEDEV4_DATA (es sind 4 Festplatten im NAS). In CACHEDEV1_DATA gibt es u.a. ein Homes-Verzeichnis und da drin sind tatsächlich für jeden User ein Userverzeichnis. Das admin-Verzeichnis enthält aber auch nicht den Key:

[/share/CACHEDEV1_DATA/homes] # cd admin
[/share/CACHEDEV1_DATA/homes/admin] #  ls -al
total 20
drwxrwxrwx 4 admin administrators 4096 2022-03-31 15:41 ./
drwxrwxrwx 7 admin administrators 4096 2022-03-19 15:09 ../
drwxr-x--- 3 admin administrators 4096 2022-03-31 15:41 .config/
drwxrwxrwx 3 admin administrators 4096 2018-12-24 16:06 .Qsync/
lrwxrwxrwx 1 admin administrators   27 2021-12-23 15:02 @Recycle -> /share/homes/@Recycle/admin
-rw-r--r-- 1 admin administrators  169 2022-04-15 13:43 .wget-hsts

Tja, seltsam. Wo wurde der Key wohl hinkopiert?

Und nein, ein mit Puttygen erstellter Key hat noch NIE bei einem openSSH selbst funktioniert

Wie haben die das denn dann hier geschafft? Danach schient es doch irgendwie möglich zu sein?

 

[the other]

Moinsen,
Nein, in deinem link werden die keys mit puttygen erstellt und mit putty die Verbindung. Das passt.
Wenn du aber eben ssh nicht mit nem ssh client Programm wie putty machen kannst, dann bei Linux mit openssh. Im Terminalfenster...
Nun passen aber eben die mit putty erstellten key Formate nicht für die Verbindung mit dem openssh unter Linux zusammen.

Einfacher ist es eben, das direkt unter openssh anzulegen, wie gesagt für /home Verzeichnisse zu sorgen (steht ja auch im link) und dann das dort mit den anzupassenden Rechten unterzubringen.

Aber vielleicht meldet sich ja auch noch einer der vielen qnap User zu Wort...da haben bestimmt einige genau diese frage selbst schon gehabt und beantwortet...

 

[Barungar]

Wie haben die das denn dann hier geschafft? Danach schient es doch irgendwie möglich zu sein?

Das ist was vollkommen anderes. In dem Artikel wird beschrieben, wie man von einem System mit PuTTY auf ein System mit SSH (z.b. openSSH) per Key zugreift. Das geht genauso wie es da beschrieben steht.

Du willst aber von einem System mit openSSH (Ubuntu Server) auf ein System mit openSSH (QNAP NAS) zugreifen. Und da akzeptiert der openSSH keine Keys, die mit PuTTY erzeugt wurden. Da musst Du einen richtigen SSH-Key für nehmen; und den erzeugt man mit ssh-keygen auf der Console.

Ich glaube PuTTYgen erklärt sogar irgendwo auch, dass es keine echten SSH-Keys (die openSSH kompatibel wären) erzeugt!

Edit
Ich habe jetzt echt die PuTTYgen-Anleitung gelesen. Und in Kapitel 8.2.14 steht, dass es keine openSSH Keys erzeugt! Das gilt aber speziell nur für den privaten Schlüssel. Der öffentliche Schlüssel von PuTTYgen ist okay für openSSH, daher kannst Du Dich von einem Windows PC mit PuTTY auch per Key auf einem openSSH-System anmelden. Weil in dem Fall bleibt der private Schlüssel auf dem PC und wird von PuTTY benutzt, dem openSSH-System gibst Du ja den öffentlichen Schlüssel, der dort in die authorized_keys kommt.

 

[blurrrr]

Ist mir bisher nie untergekommen bzw. hab ich auch noch nie etwas von gehört, da ich die Keys immer dort erstelle, wo ich sie auch brauche... So kann man solchen Problemen natürlich auch aus dem Weg gehen...

 

[Barungar]

Ist mir bisher nie untergekommen bzw. hab ich auch noch nie etwas von gehört, da ich die Keys immer dort erstelle, wo ich sie auch brauche... So kann man solchen Problemen natürlich auch aus dem Weg gehen...

Wie nicht untergekommen?! Das ist schon seit Jahrzehnten so... Ich kannte es noch nie anders.
Und Dein Vorgehen ist richtig, genauso soll es sein, dann passiert sowas auch nicht. SSH-Keys für Server-to-Server-Login werden auf Servern generiert und SSH-Keys für Client-to-Server auf dem Client, dann ist alles in Butter. Aber wie Du siehst wollen manche sowas mischen.

Normal ist bei mir:

1. SSH-Login vom Client mit Passwort auf dem (neuen, ersten) Server
2. Auf dem (neuen, ersten) Server meinen Client-SSH-Key hinterlegen
3. SSH-Login vom Client mit dem Key auf dem (neuen, ersten) Server
4. Neuen SSH-Key auf dem Server generieren
5. SSH-Login vom (ersten) Server zum (zweiten) Server mit Passwort
6. SSH-Key des Clients auf dem (zweiten) Server hinterlegen
7. SSH-Key des (ersten) Servers auf dem (zweiten) Server hinterlegen
8. Neuen SSH-Key auf dem (zweiten) Server genrieren
9. SSH-Key vom (zweiten) Server auf dem (ersten) Server hinterlegen
10. Fertig!

Nun kann der Client mit seinem SSH-Client-Key auf beide Server und beide Server können jeweils mit ihrem SSH-Server-Key auf den anderen Server. Falls es nicht gewünscht ist von beiden Seiten einen Server-zu-Server-Login zu machen, dann lässt man die Schritte 7-9 einfach weg.

 

[Tommes]

Ich stimme mit deiner Aussage...

SSH-Keys für Server-to-Server-Login werden auf Servern generiert und SSH-Keys für Client-to-Server auf dem Client, dann ist alles in Butter.

... sowie dein 10 Punkte Plan zum anlegen einer gegenseitigen SSH Kommunikation vollkommen überein. Wenn ich jedoch nur Daten von einem (zweiten) Server durch einen (ersten) Server abholen lassen will (Pull Backup), brauche ich nur den Verbindungsaufbau vom (ersten) zum (zweiten) Server, was mir einen gewissen Sicherheitsvorteil verschafft. Aber gut.

Was die Benutzer-Home-Ordner betrifft, so scheint es bei QNAP ähnlich zu sein, wie bei Synology, da hier die Benutzer-Home-Ordner im System unter /var/services/homes/[BENUTZERNAME] liegen. Nur root liegt, wie wohl bei jedem System, unter /root. Im DiskStation Manager bzw. in der File Station des Synology NAS werden aber nur die Ordner /home und /homes angezeigt, wobei /home der Benutzer Ordner des grade angemeldeten Benutzers ist, wohingegen /homes alle Benutzer-Home-Ordner beinhaltet - ist also ein Symlink auf /var/services/homes. Bei QNAP scheinen diese Ordner, wie du sagst, unter /share/homes/ zu liegen.

Auch bei Synology werden die Benutzer-Home-Ordner erst angelegt, wenn man das dem DiskStation Manager explizit mitteilt. Daher vermute ich mal, das @Nordlicht000 in jedem Fall den Benutzer-Home-Dienst auf seiner QNAP aktiveren muss, damit das mit der SSH Einrichtung überhaupt funktioniert. Alles ander wäre ja grober Unfug, wenn das ohne eine Benutzerverwaltung funktionieren würde.

Tommes

 

[Barungar]

@Tommes

Dafür der Hinweis bei Bedarf die Schritte 7 bis 9 auszulassen, wenn man keinen beidseitigen Zugriff der Server wünscht. Bei mir ist es häufig so, dass ich stanardmäßig gar keinen Server-zu-Server zu lasse. Aber ich habe auch gerade bei HA-System den Bedarf eines beiderseitigen Syncs mittels rsync. Da haben beide Systeme einen cron job der state files synchronisiert, dabei wird die Richtung vom gerade aktiven CARP Knoten vorgegeben. Da die wechselt, müssen beide in der Lage sein, per rsync/ssh etwas auf dem anderen zu schreiben.

 

[Tommes]

Alles gut. Es sollte ja nur als Hinweis dienen, nicht als "best practice". Bei dem Backup Programm, welches ich für ein Synology NAS geschrieben habe funktioniert das z.B. genauso. Man benötigt dazu nur eine "einseitige" Verbindung um Push- oder Pull Backups ausführen zu können. Dabei wird auf dem Synology NAS eine SSH-Verbindung durch den Systembenutzer root in Richtung eines Remote Servers aufgebaut, wobei man sich am Remote Server selber besser nicht als root anmelden sollte. Bei Synology funktionert das auch nicht mehr (so einfach). Aber wir schweifen mal wieder ab.

 

[Tommes]

Ich beschreib im folgenden, wie ich das immer mache, wobei ich das nicht als "best practice" betrachten würde, sondern einfach als eine von vielen Möglichkeiten, eine SSH-Verbindung zwischen zwei Servern herzustellen. Ob sich das 1 zu 1 auf deine Konfiguration anwenden lässt, muss man sehen. Sollte aber eigentlich. Ich hoffe jedenfalls, das dich das weiter bringt.

SSH-Ordnerstruktur erstellen​

Verbinde dich mit einem Benutzer deiner Wahl (z.B. root, admin, nordlicht o.ä.) z.B. via PuTTY mit deinem Ubuntu Server (hierfür benötigst du prinzipiell keine Keys). Nach der Eingabe deines Passwortes solltest du dich direkt in deinem home Verzeichnis befinden, sagen wir beispielsweise mal /home/nordlicht. Wenn du das lieber mit dem Benutzer root durchexerzieren möchtest, dann Wechsel in der Konsole zum Benutzer root mit...

sudo -s

... und gib das Passwort für den Systembenutzer root ein. Erstelle in dem Home-Ordner (/root oder halt z.B. /home/nordlicht o.ä.) einen neuen, versteckten Ordner mit…

mkdir -p ~/.ssh

RSA-Schlüssel erstellen​

Als Nächstes erstellst du die RSA-Keys. In der Regel wird beim erstellen eines RSA Schlüssels der Standardname id_rsa verwendet, in deinem Fall nehmen wir den von dir erwähnten Namen ssh_host_rsa_key. Gibt auf der Konsole also ein..

ssh-keygen -b 4096 -t rsa -f ~/.ssh/ssh_host_rsa_key

Gleich nach der Ausführung des Befehls wird man nach einer Passphrase, also einem Passwort gefragt. Hier bitte nichts eintragen, sondern die beiden Abfragen einfach mit der Return Taste bestätigen. Dies gilt aber nur für den Fall, das du eine passwortlose und damit unbeaufsichtigte Verbindung zu deinem Remote Server (der QNAP) aufbauen möchtest. Nach der Ausführung wurden folgende Dateien erzeugt, wobei die Datei ssh_host_rsa_key den privaten Schlüssel bereithält, die Datei ssh_host_rsa_key.pub dagegen den öffentlichen Schlüssel.

/home/nordlicht/.ssh/ssh_host_rsa_key
/home/nordlicht/.ssh/ssh_host_rsa_key.pub

authorized_keys anlegen​

In der Datei authorized_keys werden im späteren Verlauf neben dem eigenen-, auch alle öffentlichen Schlüssel bekannter Remote Server eingetragen, um so einen passwortlosen Verbindungsaufbau zu ermöglichen. Da die Datei noch nicht existiert, wird diese nun durch Eingabe von...

touch ~/.ssh/authorized_keys

...erstellt und im Anschluss gleich der eigene, öffentliche Schlüssel darin eintragen mit…

cat ~/.ssh/ssh_host_rsa_key.pub >> ~/.ssh/authorized_keys

Ordner- und Dateirechte setzen​

Zuletzt müssen noch die Zugriffsrechte für den erstellten Ordner ~/.ssh, sowie den beinhaltenden Dateien anpassen.

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/ssh_host_rsa_key*
chmod 0600 ~/.ssh/authorized_keys

Die SSH-Ordnerstruktur für deinen Ubuntu Server ist nun eingerichtet.

Weiter gehts mit deiner QNAP​

Bevor du beginnst, aktiviere im QNAP ControlPanel das „Startverzeichnis“. Öffne im Anschluss wieder einen Terminal z.B. über PuTTY, um dich mit deiner QNAP zu verbinden, oder noch besser, nutze das bereits geöffnete Terminalfenster deines Ubuntu Servers, um dich per SSH auf deine QNAP zu verbinden. Dazu müsstest du dann z.B. folgendes nach diesem Muster (Syntax) eingeben (die Portangabe lassen wir der Einfachheit halber mal weg)…

ssh [USERNAME]@[SERVER-ADDRESS]

Gib wieder dein Passwort ein und du solltest dich im Benutzer-Home-Ordner des angemeldeten Benutzers deiner QNAP befinden. Da ich selber keine QNAP besitze, kann ich nur vermuten, das du dich dann unter share/homes/admin befinden solltest, gesetzt dem Fall, das du dich mit diesem Benutzer angemeldet hast. Auch hier wird wieder der versteckte Ordner /.ssh erstellt mit…

mkdir -p ~/.ssh

… anders als auf deinem Ubuntu Server benötigst du für den Verbindungsaufbau von deinem Ubuntu Server in Richtung QNAP erstmal keine RSA-Schlüssel. Diese benötigst du nur, wenn du dich auch von deiner QNAP auf deinen Ubuntu Server verbinden möchtest. Möchtest du das, dann erstelle auch hier jetzt die RSA-Key's, wie oben bereits beschrieben. Ansonsten ist das einzige was du auf der QNAP benötigst, die authorized_keys, du du wieder mit…

touch ~/.ssh/authorized_keys

… erstellst. Anschließend werden wieder die Ordner und Dateirechte gesetzt mit…

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

Beende die Verbindung mit einem...

exit

… um wieder zurück auf deinen Ubuntu Server zu kommen.

Austausch des öffentlichen RSA-Schlüssels​

Du bist also wieder am Terminal deines Ubuntu Servers angemeldet. Jetzt musst du noch irgendwie den öffentlichen Schlüssel (public-key) in die authorized_keys deiner QNAP bekommen. Eine Möglichkeit ist, das über eine „einfache“ SSH Verbindung zu lösen. Die Syntax für den Befehl lautet…

cat ~/.ssh/[FILENAME].pub | ssh -p [PORT] [USERNAME]@[SERVER-ADDRESS] "cat >> ~/.ssh/authorized_keys"

… wobei du als FILENAME dann halt deinen gewählten Dateinamen, wie z.B. ssh_host_rsa_key, sowie für BENUTZER und SERVER-ADRESSE halt deine Verbindungdaten verwendest. Den PORT kann man auch weglassen, gebe ihm im Standard aber immer mit. Als Beispiel würde das dann so aussehen…

cat ~/.ssh/ssh_host_rsa_key.pub | ssh -p 22 [admin]@[meine-qnap] "cat >> ~/.ssh/authorized_keys"

Du wirst ein letztes Mal aufgefordert, dein Passwort für die QNAP anzugeben. Nachdem du das getan hast, solltest du dich wieder am Terminal deiner QNAP befinden. Daher gibst du wieder ein…

exit

… ein, um zurück auf den Ubuntu Server zu kommen.

UND DAS WARs!!!

Baust du jetzt erneut eine SSH Verbindung in Richtung deiner QNAP auf, dann wirst du nicht mehr nach einem Passwort gefragt, sondern landest direkt auf dem Terminal deiner QNAP.

Ich hoffe, ich habe in dieser Anleitung nichts vergerssen, ansonten korrigiert bzw. ergänzt mich bitte

Tommes

 

[Barungar]

@Tommes

ssh-keygen -b 4096 -t rsa -f ~/.ssh/ssh_host_rsa_key

Gleich nach der Ausführung des Befehls wird man nach einer Passphrase, also einem Passwort gefragt. Hier bitte nichts eintragen, sondern die beiden Abfragen einfach mit der Return Taste bestätigen.

Mit ssh-keygen -b 4096 -t rsa -f ~/.ssh/ssh_host_rsa_key -N '' kannst Du Dir an dieser Stelle den blöden Passwort-Prompt ersparen, besonders wenn Du dem User (fehleranfällig!) sagst, dass er nichts eingeben soll. Ich persönlich gebe dann lieber direkt aus dem Befehl nichts an, als mich auf einen User zu verlassen. Nach über 30 Jahren IT bedeuten User nix gutes.

 

[Tommes]

Mit ssh-keygen -b 4096 -t rsa -f ~/.ssh/ssh_host_rsa_key -N '' kannst Du Dir an dieser Stelle den blöden Passwort-Prompt ersparen…

Hammer! Danke! Siehst du… man kann alt werden wie eine Kuh und lernt immer noch dazu

 

[Nordlicht000]

Das ist was vollkommen anderes. In dem Artikel wird beschrieben, wie man von einem System mit PuTTY auf ein System mit SSH (z.b. openSSH) per Key zugreift. Das geht genauso wie es da beschrieben steht.

Der öffentliche Schlüssel von PuTTYgen ist okay für openSSH, daher kannst Du Dich von einem Windows PC mit PuTTY auch per Key auf einem openSSH-System anmelden.

Ich glaube wir reden hier aneinander vorbei. Mein erster Test war ja von einem System mit putty (Windows-PC) auf das QNAP so wie oben gesagt und ich wollte ja auch nur mit putty vom Windows-PC aus auf die QNAP. Und das hat eben nicht so funktioniert wie in dem Artikel beschrieben. Es hat überhaupt nicht funktioniert. Laut deiner obigen Ausssage hätte das aber funktionieren müssen.
Da ich es nicht so habe mit der Kommandozeile, wollte ich halt erstmal was bekanntes ausprobieren weil ich dachte das wäre einfacher. War wohl ein Irrtum. Der UbuntuServer war hier gar nicht beteiligt und ich hatte auch nicht vor zu mischen. Das diente nur zum Üben.

Du willst aber von einem System mit openSSH (Ubuntu Server) auf ein System mit openSSH (QNAP NAS) zugreifen.

Das hat ja nun funktioniert mit den auf dem UbuntuServer von SSH generierten Keys.
Und es überlebt sogar einen Neustart des QNAP ohne die Klimmzüge mit der autostart.sh.
Die autostart.sh hatte ich vor dem Neustart wieder geleert.

Die Datei authorized_keys war der von Putty erzeugte Key,

Hier muß ich mich mal selbst zitieren.
Nach dem Neustart ist die authorized_keys immer noch im Verzeichnis /etc/config/ssh (auch ohne den copy-Befehl in der autostart.sh), nur daß sie jetzt authorized_keys* heißt. Vom Datumeintrag der Datei her könnte das wohl ungefähr die Uhrzeit gewesen wo ich den Key vom Ubuntuserver auf die QNAP kopiert hatte. Ich habe mir mal den Inhalt angesehen:

N SSH2 PUBLIC KEY ----
Comment: "rsa-key-20220415"
dann kommen hier mehrere Zeilen Key-Buchstabensalat
---- END SSH2 PUBLIC KEY ----
ssh-rsa und dann noch mehr Key-Buchstabensalat Wartung@ubuntuserver

Das "Wartung@ubuntuserver" am Ende sagt doch, daß dies der Key ist, den ich mit dem Ubuntuserver per ssh generiert und erzeugt habe?
Dann hat QNAP den Key beim kopieren mit dem Befeht

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

vom Ubuntuserver auf die QNAP wohl in authorized_keys* umbennant und ich habe das deshalb nicht gefunden, weil ich nach qnap.key.pub gesucht hatte? Sehr seltsam diese Eigenmächtigkeiten von QNAP.
Aber Hauptsache es funktioniert.

Baust du jetzt erneut eine SSH Verbindung in Richtung deiner QNAP auf, dann wirst du nicht mehr nach einem Passwort gefragt, sondern landest direkt auf dem Terminal deiner QNAP.

Das SSH-Login vom Ubuntuserver aus mit den Keys funktioniert jetzt und überlebt auch einen Neustart. Die Startverzeichnisse mußte ich dafür nicht aktivieren. Dieser Befehl

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

reichte völlig aus um den Key auf die QNAP zu kopieren und QNAP hat das dann offenbar umbenannt in authorized_keys* und im Verzeichnis /etc/confg/ssh gespeichert.

Nach über 30 Jahren IT bedeuten User nix gutes.

Die größte Fehlerquelle sitzt immer vor der Tastatur.

 

[Barungar]

Ich glaube wir reden hier aneinander vorbei. Mein erster Test war ja von einem System mit putty (Windows-PC) auf das QNAP so wie oben gesagt und ich wollte ja auch nur mit putty vom Windows-PC aus auf die QNAP. Und das hat eben nicht so funktioniert wie in dem Artikel beschrieben. Es hat überhaupt nicht funktioniert.

Ich habe es gerade extra mal probiert... erfolgreich übrigens. Ich kann mich nun mittels PuTTY und SSH-Key auf der Shell meines QNAP-NAS anmelden. Den SSH-Key habe ich mit PuTTYgen erzeugt, im home-Verzeichnis des Users das .ssh-Verzeichnis angelegt und dort in der Datei authorized_keys den öffentlichen Schlüssel reinkopiert (voller Pfad auf meinem TS-h886: /share/homes/<user>/.ssh/authorized_keys). Done and working... sonst nix gemacht, keine Anpassungen in der GUI oder sonst was.

 

[Nordlicht000]

Hm, seltsam. Aber ich habe kein Verzeichnis /share/homes/<user>/
Bei mir ist das in /share/CACHEDEV1_DATA/homes/<user>/
Hast du bei dir im ControlPanel bei den Startseite-Ordner aktiviert?
Oder liegt das an meinem anderen Modell oder vielleicht auch an der Firmware-Version?

Egal, vom Ubuntuserver funktioniert es jetzt und vom Windows-PC aus (mit putty) reicht mir das normale Login mit User/Paßwort. Ist vielleicht auch besser so, denn wenn ich mir auf dem Windowsrechner mal was einfange (damit surfe ich ja im Internet), dann kann jeder ohne Paßwortabfrage auf meine QNAP.

Die Beschreibung im von "@the other" geposteten Link fand ich gut verständlich. Da wird auch ein E-Book angeboten. Da ich bisher noch nie ein E-Book gekauft hatte (ich bin eher ein Freund von echten Büchern, also die aus Papier ): kann man das auch wie bei einem normalen PDF mit dem Acrobat Reader auf jedem PC lesen oder braucht man dafür diese E-Book-Reader-Hardware oder spezielle Software oder ist das an einen bestimmten PC gebunden?

 

[blurrrr]

Wie nicht untergekommen?! Das ist schon seit Jahrzehnten so... Ich kannte es noch nie anders.
Und Dein Vorgehen ist richtig, genauso soll es sein, dann passiert sowas auch nicht.

Ja siehste, deswegen auch: bisher nicht untergekommen

Egal, vom Ubuntuserver funktioniert es jetzt und vom Windows-PC aus (mit putty) reicht mir das normale Login mit User/Paßwort. Ist vielleicht auch besser so, denn wenn ich mir auf dem Windowsrechner mal was einfange (damit surfe ich ja im Internet), dann kann jeder ohne Paßwortabfrage auf meine QNAP.

Najo, kannst auch Key mit Passphrase nutzen... Kannste Dir mal einen globalen "Dein-Key" erstellen... packe überall in die root/admin-Ordner, schreibst in den Kommentar Deinen Namen (damit Du weisst, für wen der Key ist (sofern mal andere dazu kommen)) und nutzt ein Passwort dabei. Eigentlich Standard, wenn man Keys für mehrere Admins ausrollt... Jeder hat seinen eigenen (und eines Passwort) und die Keys werden allesamt auf den jeweiligen Kisten hinterlegt, so dass ich jeder Admin dort mit seinem persönlichen Key anmelden kann (und jedes Backup-System und jedes Monitoring-System usw. usw. usw.).

EDIT: Soll heissen, dass Du Deinen persönlichen Key dann sowohl auf dem QNAP, als auch auf dem Ubuntu-Server (und ggf. anderen Geräten) nutzen könntest.

 

[Nordlicht000]

Habe gerade mal einen einfachen Testlauf mit rsync über SSH gemacht:

 rsync -ave 'ssh  -i home/<User>/.ssh/qnap_rsa' admin@IP:/share/CACHEDEV1_DATA/Public /mnt/Backup1/Test-Backup

Im Public-Verzeichnis auf der QNAP waren nur ein paar Testdateien drin. Ansonsten benutze ich das nicht. War also für ein Test gerade passend.
Eigentlich ist das Public-Verzeichnis über /share/Public zu erreichen, aber das ist auf der QNAP nur ein Link zu /share/CACHEDEV1_DATA/Public, wobei CACHEDEV1 wohl die Festplatte 1 ist (habe dort ein Raid5). Meine sebst erstellten Freigabeverzeichnisse auf der QNAP liegen auf CACHEDEV2_DATA bis CACHEDEV4_DATA. Wenn ich bei rsync den Link /share/Public als Quelle angebe, dann funktioniert es nicht. Auf dem Ubuntuserver ist dann lediglich ein Link gelandet, der zu nichts führt. Ist zwar ganz schön aufwändig mit diesen Kommanozeilenbefehlen, aber mit obigem Befehl hat es funktioniert.

Jetzt muß ich noch herausfinden wie man es macht, daß man so wie z.B. bei meinem Acronis verschiedene Versionen des Backups hat, d.h. ich möchte ja auch auf ältere Versionen zurückgreifen können, falls ich nicht sofort bemerke, daß ein Verschlüselungstrojaner zugeschlagen hat. Der würde das mit obigem Befeht erstellte Backup ja sofort unbrauchbar machen, da die Daten dann von jeweils der neuesten Dateiversion überschrieben werden, d.h. auch im Backup ist dann alles verschlüsselt.

 

[the other]

Moinsen,
na dann klappt es ja jetzt anscheinend...super!
Ich halte es da mit @blurrrr :
hier ist zwar außer mir niemand, der sich per ssh auf irgendwas schalten darf/soll/muss, ich habe aber trotzdem für die Gerätekategorien zwei Keypairs für mich erstellt...
einmal für die ganze Netzwerkstruktur (Router, Firewall, switches) für mich mit Passphrase, einmal für die NAS, den Druck/Scan Server und die RaspberryPis.

Vorgehen wie beschrieben: auf dem PC (von dem der ssh-Zugriff erfolgt) im Terminal die keypairs erzeugt, die .pub dann auf die zu erreichenden Geräte geschoben, Rechte angepasst, sshd_config konfiguriert, läuft.

Wie so vieles im Leben: die ersten 2-3 Versuche etwas holprig, dann besser, jetzt ne Sache von Minuten...wie Schwimmen und Fahrradfahren lernen.

 

[Barungar]

Hm, seltsam. Aber ich habe kein Verzeichnis /share/homes/<user>/
Bei mir ist das in /share/CACHEDEV1_DATA/homes/<user>/
Hast du bei dir im ControlPanel bei den Startseite-Ordner aktiviert?
Oder liegt das an meinem anderen Modell oder vielleicht auch an der Firmware-Version?

Ich habe, wie im Text erwähnt ein TS-h886... das h weißt an dieser Stelle darauf hin, dass es ein extra für QuTS hero gebautes Modell ist. Es mag also sein, dass QuTS hero anders auf dem Filesystem aufgebaut ist als das einfache QTS, da habe ich gerade keinen Vergleich. Was ich so an diversen Sources bzw. Man-Pages festgestellt habe, scheint QuTS hero aus der OpenBSD-Familie zu stammen. Über die Abstammung von QTS weiß ich nichts.