Per SSH auf Pi zugreifen ohne weitere Aufforderungen

[maalik]

Hallo zusammen,

ich versuche, meine let's encrypt keys, monatlich auf meinen Pi zu übertragen, da der auch über Web erreichbar ist.

Ich möchte also das Kopieren automatisch durchführen lassen per Aufgabenplaner/SSH.

Ich habe mich bereits informiert, sshpass fällt bei Syno raus. Also geht wohl nur die Option mit PublicKeyAuth.


Folgendes ausgeführt:

Auf dem Pi:

ssh-keygen -t rsa -b 4096 -f /home/pi/keys/syno

(ohne passphrase erstellt)


Werte des Public-Keys in die authorized_Keys geschrieben

cat /home/pi/keys/syno.pub >>/home/pi/.ssh/authorized_keys

Auf der Syno:
syno.pub in den entsprechenden Ordner gelegt:

ssh -i /volume1/zeug/syno.pub pi@192.168.1.12

Leider bekomme ich weiterhin eine Passwort-Abfrage und zudem eine Passphrase-Abfrage.

Enter passphrase for key '/volume1/zeug/syno.pub':
pi@192.168.1.12's password:

Wo liegt mein Fehler?

Gruß

 

[Tommes]

Ich hab die Einrichtung einer SSH-Verbindung hier mal beschrieben *klick* (auch wenn ich heute wohl eine etwas effektivere Schreibweise der Befehle hernehmen würde (bin nur zu faul, das zu aktualisieren))

Alternativ gibt es noch diesen Wiki-Eintrag *klick*

Da du über den Aufgabenplaner dein Script?!? Auslösen möchtest, wäre eine SSH-Verbindung zwischen den Benutzern "root" sowohl auf der DS als auch auf dem Pi nicht verkehrt. Alternativ geht auf dem Pi natürlich auch der Benutzer Pi. Der SSH-Part sollte aber im jeweiligen Benutzer-Home Ordner liegen, also unter ~/.ssh (/root/.ssh) oder auf dem Pi ~/.ssh (/home/pi/.ssh)

Tommes

 

[maalik]

Ich habe deine Anleitugn exakt befolgt, mit Synology als Produktiv-System und Pi als Client, jedoch bekomme ich weiterhin eine Passwortabfrage.

 

[Fusion]

Passwortabfrage für den user oder für den Schlüssel?

 

[maalik]

Für den User. Bei beiden Befehlen hier. Bei Ersetzen von root@ durch pi@ gleiches Problem

root@SynologyDS215j:~# ssh root@192.168.1.12 -p 22
root@192.168.1.12's password:

root@SynologyDS215j:~# ssh -i ~/.ssh/synopi.pub root@192.168.1.12
root@192.168.1.12's password:

 

[Tommes]

Das sollte, wenn du dich an meine Anleitung gehalten hast, aber nicht sein. Notfalls alles nochmal löschen und noch mal von vorne beginnen. Alternativ könntest du auch über Ultimate Backup den SSH-Zugang legen. In der Hilfe zu Ultimate Backup steht auch nochmal beschrieben wie das mit einem "rsync-kompatiblen Server" funktioniert.

Tommes

 

[Fusion]

Die DS ist hier der Client und der Pi der Server? (nach deinem letzten posting)
Dann gehört der private key auf die DS und der pub Teil in die authorized_keys für den user auf dem Pi, oder wo dort die sshd_config eingerichtet ist (hast du ja ganz oben schon beschrieben).

Mit ssh -vvv, ein bis drei v bekommst du auch mehr debug output, der dir das vermutlich bestätigt.

 

[maalik]

Jetzt bin ich verwirrt. Ich möchte von Synology per SSH auf den Pi zugreifen. Nach dieser Anleitung:
http://www.synology-wiki.de/index.p...Keys_f.C3.BCr_den_Aufbau_einer_SSH-Verbindung

Was ist nun äquivalent zu Diskstation A und was ist Diskstation B?
Ich habe die Anleitung eben so befolgt:

Pi = Diskstation A, Syno Diskstation B

 

[Tommes]

Jepp... so stimmt das schon. Notfalls kannst du aber auch noch analog für die andere Richtung einrichten, dann hast du eine gegenseitige Kommunikation zwischen Pi und DS.

Ich denke, das der Verbindungsaufbau schon klappen würde, mich irritiert dabei aber die Passworteingabe. Eigentlich sollte hier nur der Handshake kommen.

 

[maalik]

Habe es nun nochmal umgedreht, und dann so wie eigentlich richtig probiert. Weiterhin eine Passwortabfrage.

In meinem Pi steht nun der .pub-Inhalt in der authorized_keys.

Auf meiner Syno sind in /root/.ssh/ die beiden Dateien synopi und synopi.pub

Muss man im ssh statement nicht noch den Ort des Files hinzufügen?

 

[maalik]

Sodele, jetzt haben wir es. Mit folgendem Aufruf geht es:

ssh -i /root/.ssh/synopi pi@192.168.1.12

Mit -i Parameter und der Angabe des geheimen Schlüssels, NICHT des .pub.

Sollte soweit sicherheitstechnisch korrekt sein oder?

 

[maalik]

Leider hab ich es noch nicht ganze geschafft. Wenn ich nun

scp -i /root/.ssh/synopi /usr/syno/etc/certificate/system/default/cert.pem pi@192.168.1.12:/etc/ssl/certs/

bzw.

scp -i /root/.ssh/synopi /usr/syno/etc/certificate/system/default/privkey.pem pi@192.168.1.12:/etc/ssl/private/

in der Konsole von root@SynologyDS215j ausführe, funktioniert alles.

Wenn ich die beiden Zeilen jedoch in eine .sh Datei packe und dann

/volume1/zeug/raspi_ssl_copy.sh

aufrufe, bekomme ich ein

root@SynologyDS215j:/volume1/zeug# /volume1/zeug/raspi_ssl_copy.sh
: Permission denied/
scp: /etc/ssl/private//privkey.pem: Permission denied

Warum geht es direkt, aber nicht über Datei?

 

[Tommes]

Hast du im Script den passenden "Shebang" drin...

#!/bin/sh

Stimmen die Dateirechte der raspi_ssl_copy.sh? Ist die Datei ausführbar?

chmod +x raspi_ssl_copy.sh

Prüf mal mit...

which scp

... wo genau scp liegt (bei mir unter DSM 6 unter /bin/scp) und gib den Pfad mit im Script an.

Und eigentlich startet man ein Script, wenn man sich im Ordner des Scriptes befindet mit

 ./raspi_ssl_copy.sh

So kenn ich es jedenfalls.

Tommes

 

[maalik]

Abend Tommes. Es lag am Shebang, das vergesse ich jedes mal.

Wir sind fast am Ziel! Das verschieben von cert.pem funktioniert, jedoch ist der Ordner /etc/ssl/private auf dem Pi der Gruppe ssl-cert zugeordnet, der User pi@ hat also keine Zugriff.

Kann ich die Gruppe auf root umstellen? Oder lieber mit chmod was ändern?

lg
Felix

 

[Fusion]

Du hattest doch weiter oben die Befehle geposted und gemeint die würden funktionieren. Dort wird doch auch der Nutzer pi benutzt um sich auf dem Pi einzuloggen und die Dateien dort hin zu kopieren.
Was stimmt jetzt?

Ansonsten würde ich am ehesten noch den Nutzer pi in die ssl_certs Gruppe packen.

 

[maalik]

Tut mir Leid, ich habe nur die erste Zeile getestet, die für cert.pem.

Ich bin dann davon ausgegangen, dass privkey.pem auch einfach sollte. Der Befehl selbst stimmt ja, bloß habe ich nicht beachtet, dass der Ordner private eben andere Berechtigungen hat.