ssh public key auf DS klappt nicht

Status
Für weitere Antworten geschlossen.

intron

Benutzer
Mitglied seit
08. Aug 2011
Beiträge
11
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich nutze rsnapshot zum Sichern meines Servers - funktioniert wunderbar, aber leider nur mit manueller Passworteingabe. SSH public key auf der DS211j mit DSM 4.3 will nicht, so wie ich will.

Gemacht habe ich bisher folgendes:

  • neuen RSA-Schlüssel als root mit keygen auf dem Server erzeugt, Passwort leer
  • mit ssh-copy-id -i /root/.ssh/schlüssel.pub als root auf die DS kopiert
  • authorized_keys in /root/.ssh auf der DS ist vorhanden, CHMOD 600 gesetzt. die Rechte stimmen

Jetzt müsste doch eigentlich ein passwortloses SSH-Login von der DS auf den Server klappen - geht aber nicht. Was mache ich verkehrt?

Danke für hilfreiche Hinweise
Chris
 

mr coffee

Benutzer
Mitglied seit
04. Mrz 2012
Beiträge
115
Punkte für Reaktionen
2
Punkte
18
Vielleicht hilft dir das:

- Konfig-Datei öffnen ...
vi /etc/ssh/sshd_config

- ... das #-Zeichen bei diesen Zeilen entfernen und den Inhalt anpassen:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile /root/.ssh/authorized_keys

- ssh-Dienst neustarten:
/usr/syno/etc.defaults/rc.d/S95sshd.sh restart
 

intron

Benutzer
Mitglied seit
08. Aug 2011
Beiträge
11
Punkte für Reaktionen
0
Punkte
0
Hmh, hilft auch nicht. Jedenfalls nicht, wenn ich das auf der DS mache. SSH will immer noch das Passwort, wenn ich von der DS auf den Server will.
Muss ich da nicht eher was an der Server-SSH-Konfiguration verändern? Wenn ja was?
 

mr coffee

Benutzer
Mitglied seit
04. Mrz 2012
Beiträge
115
Punkte für Reaktionen
2
Punkte
18
Also ich habe heute zum ersten Mal eine rsync ssh connection von einer Diskstation zur anderen Diskstation auf Basis von private/public key realisiert. Daher habe ich nicht viel Erfahrung, versuche aber trotzdem mal zu helfen.

Verstehe ich das richtig? Es gibt einen (Linux?)-Server, und dieser soll sich bei der Diskstation anmelden, um mittels rsnapshot die Daten auf der NAS abzulegen.

Dann müsstest du doch für mein Verständnis die Keys auf der NAS erstellen, also mittels "ssh-keygen -t rsa" den private key "id_rsa" und den public key "id_rsa.pub" erstellen (Dateinamen sind natürlich nur Beispiele).
Der public key muss dann in die "authorized_keys" geschrieben werden, also beispielsweise per "cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys".
Außerdem müssen die Rechte gesetzt werden: "chmod 600 /root/.ssh/authorized_keys" (wie du ja bereits geschrieben hast).
Dann muss die Konfig-Datei angepasst werden und der Dienst neugestartet werden (siehe vorheriger Post). Alle Punkte bis hierher müssen auf der NAS erfolgen.

Auf den Server muss jetzt der private key kopiert werden, also die Datei "id_rsa". Dann kann man auf der Konsole des Servers sich testweise mit "ssh -i /VerzeichnisDesPrivateKeysAufDemServer/id_rsa root@IpDerNas" auf der NAS einloggen - ohne Eingabe eines Passworts.

Ich hoffe das hilft, so hat es auf jeden Fall bei mir funktioniert.

EDIT:
Habe gerade erst gesehen, dass du von der NAS auf den Server willst. Dann musst du nur jede Aktion "vertauschen". Welches OS hat der Server?
 

intron

Benutzer
Mitglied seit
08. Aug 2011
Beiträge
11
Punkte für Reaktionen
0
Punkte
0
Nein, anders:
rsnapshot läuft nur lokal, muss also zum Sichern der Serverdaten auf der DS laufen. Und das heisst, dass sich die DS via SSH auf dem Server anmelden muss, um die Daten abzuholen, und genau das funktioniert nicht, jedenfalls nicht per public key, und das sollte für einen Cronjob schon klappen .... Manuell ist das kein Problem, es dreht sich nur um das automatisierte Login ohne Passworteingabe. Umgekehrt, also vom Server auf die DS ist es kein Problem, aber das will ich ja gar nicht.
So richtig klar ist mir nicht, woran es liegen könnte, denn von anderen Rechnern im gleichen LAN auf den besagten Server (reine Linuxumgebung) klappt public key-SSH ohne Zicken.
 

intron

Benutzer
Mitglied seit
08. Aug 2011
Beiträge
11
Punkte für Reaktionen
0
Punkte
0
Ich komme nicht über die beschriebene Konstellation hinaus. Hat jemand noch eine Idee?
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
hat die DS denn den private Key? Hast du mal probiert ob es direkt auf der Konsole geht wenn du das Schlüsselfile explizit angibst, allenfalls noch mit -v damit ssh mehr Output erzeugt?
Code:
ssh -vv -i /pfad/key root@DEIN_SERVER
 

mimue

Benutzer
Mitglied seit
23. Jan 2009
Beiträge
11
Punkte für Reaktionen
0
Punkte
1
Ich bin mir nicht sicher, ob ein leeres Passwort keine Interaktion erfordert. Ich glaube man muss das Login bestätigen. Wenn das so sein sollte musst du den ssh-Agent benutzen. Im Bezug auf Sicherheit würde ich immer den privaten Schlüssel mit einem Passwort schützen.
Vielleicht hilft dir die Seite weiter

http://www.schlittermann.de/doc/ssh

Gruß
Micha
 

rookee

Benutzer
Mitglied seit
25. Sep 2012
Beiträge
61
Punkte für Reaktionen
0
Punkte
0
Hi,

ich habe das gleiche Problem. Ich versuche mich per ssh -i an der DS anzumelden und Daten zu holen, aber trotz Schlüsselpaar kommt eine Passwortabfage.

Nach dem Tip von jahlives (-vv) kommt folgende Ausgabe. Kann damit jemand etwas anfangen oder ein Problem erahnen?

Rich (BBCode):
...
debug1: Connection established.
...
debug1: Host 'ds213' is known and matches the RSA host key.
...
debug2: key: ~/.ssh/ssh-key ((nil))
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: ~/.ssh/ssh-key
debug1: read PEM private key done: type RSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
 

mimue

Benutzer
Mitglied seit
23. Jan 2009
Beiträge
11
Punkte für Reaktionen
0
Punkte
1
Hast du diese Sachen mal überprüft?

Ist der ssh-Zugriff überhaupt möglich? (Ein beliebtes Problem ist ... key_exchange ... connection closed by foreign host. Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht mit dem Namen für den eigenen Host übereinstimmt.
Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. Oder DNS in Ordnung bringen!

Passwort wird verlangt. Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, der auch der "angepeilte" Nutzer sein muß, schreibbar sein. Auch das Home-Verzeichnis des angepeilten Nutzers darf ausschließlich für den Eigenümer beschreibbar sein.
ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. M.W. ist die SSH2 auf Debian/GNU-Linux gepatcht und sucht die wie gehabt in ~/.ssh/authorized_keys, aber u.a. auf SuSE-Systemen habe ich schon gesehen, daß eben diese 2 angehängt werden muß.
Erzwingen der Verwendung von Schlüsseln

Wenn das jetzt alles so schön funktioniert, wollen wir ja auch die Anmeldung mit den Schlüsseln erzwingen. Wenn es nur den Root-Account betrifft, ist das relativ einfach:
# /etc/ssh/sshd_config
...
PermitRootLogin without-password
...
 

intron

Benutzer
Mitglied seit
08. Aug 2011
Beiträge
11
Punkte für Reaktionen
0
Punkte
0
Mir ist noch ein Aspekt aufgefallen; vielleicht spielt der ja eine Rolle, aber dazu bräuchte ich fachkundige Aufklärung.
Auf der DS gibt es einmal /etc/ssh/ mit einer sshd.config und es gibt /opt/etc/openssh/ mit ebenfalls einer sshd.config.
Welches Verzeichnis ist denn das relevante für den public key-Zugriff? Auf dem Server, auf den von der DS aus automatisch zugegriffen werden soll, gibt es nur /etc/ssh/.
 

rookee

Benutzer
Mitglied seit
25. Sep 2012
Beiträge
61
Punkte für Reaktionen
0
Punkte
0
Hast du diese Sachen mal überprüft?

Ist der ssh-Zugriff überhaupt möglich? (Ein beliebtes Problem ist ... key_exchange ... connection closed by foreign host. Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht mit dem Namen für den eigenen Host übereinstimmt.
Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. Oder DNS in Ordnung bringen!

ssh Zugriff ist über PW problemlos möglich. Auch Reverse-Auflüsung der IPs ist korrekt.

Passwort wird verlangt. Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, der auch der "angepeilte" Nutzer sein muß, schreibbar sein. Auch das Home-Verzeichnis des angepeilten Nutzers darf ausschließlich für den Eigenümer beschreibbar sein.
ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die Ordner haben die richtigen Rechte.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. M.W. ist die SSH2 auf Debian/GNU-Linux gepatcht und sucht die wie gehabt in ~/.ssh/authorized_keys, aber u.a. auf SuSE-Systemen habe ich schon gesehen, daß eben diese 2 angehängt werden muß.
Erzwingen der Verwendung von Schlüsseln

Hab´s probiert, hat aber auch nicht geholfen...


Für Hinweise die zur Festnahme des Verdächtigen führen, hat die Polizei ein Preisgeld i.H.v. einem kühlen Weizenbier ausgeschrieben ;-)
 

rookee

Benutzer
Mitglied seit
25. Sep 2012
Beiträge
61
Punkte für Reaktionen
0
Punkte
0
Hat niemand mehr eine Idee warum der ssh -i als root@ds213 nicht funktioniert?
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Dinge zum prüfen:

ist der Pub Key auf dem Server in authorized_keys eingetragen?
stimmen die Rechte auf dem File, dem übergeordneten .ssh Ordner und dem Homeverzechnis selber auf dem Server?
stimmen die Rechte auf dem private Key auf dem Client, dem .ssh Verzeichnis und dem Home?

Den debug hast du ja bereits gemacht. Mir fällt da nur die Zeile mit "we did not send ...." auf. Ich weiss nicht ob es noch andere Gründe dafür gibt, aber bei mir kenn ich diese Meldung wenn der Server ein Problem mit dem authorized_keys File hat
 
Zuletzt bearbeitet:

rookee

Benutzer
Mitglied seit
25. Sep 2012
Beiträge
61
Punkte für Reaktionen
0
Punkte
0
Hi Jahlives,

Danke für deine Antwort.

Meine Konfiguration:
"Alice" soll sich per Cron an "Bob" anmelden, rsyncen. Fertig.

Den Pub.Key und den Priv.Key habe ich auf "Alice" erstellt und den Pub.Key nach "Bob" /home/root/.ssh/authorized_keys kopiert und die Rechte auf root beschränkt.
(spielt es eine Rolle ob die Keys auf Alice oder auf Bob erzeugt wurden?)

im home/root/.ssh auf "Alice" liegt jetzt noch der Pub.Key und der Priv.Key.

Bei meinem Anmeldetest versuche ich:
Rich (BBCode):
ssh -i /home/root/.ssh/Priv.Key root@Bob

Sind bis daher irgendwelche Fehler erkennbar?
 

jahlives

Benutzer
Mitglied seit
19. Aug 2008
Beiträge
18.275
Punkte für Reaktionen
4
Punkte
0
Ist schwierig zu sagen :) Zeig doch bitte mal den Output von ls -al auf dem Server 1. für das Home von root 2. für roots .ssh Verzeichnis
Dann allenfalls noch den Inhalt von authorized_keys. Ist ja nur der Pub Key also nichts Geheimes. Wenn du dem Forum nicht traust kannst du mir das auch via PN schicken...
Was auch noch eine Testoption wäre ist den SSH Server im Debug Mode zu starten. Das ergibt sehr detaillierten Output auf der Konsole
 

j-m-s

Benutzer
Mitglied seit
14. Jan 2015
Beiträge
62
Punkte für Reaktionen
0
Punkte
6
Auch das Home-Verzeichnis des angepeilten Nutzers darf ausschließlich für den Eigenümer beschreibbar sein.

Oha! Das stand bisher nirgends! Also chmod 700 ~

Und das wars! Danach ging es! Danke!


PS: ja der thread ist alt, aber vielleicht hilf es anderen....
 

bhal

Benutzer
Mitglied seit
11. Nov 2018
Beiträge
1
Punkte für Reaktionen
0
Punkte
1
zur Aktualisierung:

ist immer noch aktuell:

chmod 700 ~

half auch bei mir - mit dem aktuellen DSM 6.2.1-23824 Update 1
 
Zuletzt bearbeitet von einem Moderator:

ujaudio

Benutzer
Mitglied seit
11. Jul 2010
Beiträge
51
Punkte für Reaktionen
2
Punkte
8
Ich blicke noch nicht ganz durch: Ich habe auf meinem (Ubuntu)-PC ein Schlüsselpaar erzeugt, den öffentlichen kann ich gleich übertragen, aber
ssh-copy-id -i /home/user/.ssh/id_rsa.pub root@192.xxx.xxx.xxx
funktioniert nicht, weil dann das Passwort für root abgefragt wird, was wohl nicht mehr funktioniert.

Nun kann ich die Datei auch manuell zur Synology bringen - nur wo muss ich sie da ablegen und welche Zugriffsrechte sind einzustellen?

Oder gibt es einen anderen eleganten Weg?
 

the other

Benutzer
Sehr erfahren
Mitglied seit
17. Okt 2015
Beiträge
2.099
Punkte für Reaktionen
539
Punkte
154
root zugriff und ssh

moinsen,
ich hab auch etwas länger rumgeschraubt mit dem ssh und den key-authentications...jetzt läuft es.
Weil es doch immer mal wieder vorkommt, ujaudio: der ssh zugriff für root ist eingeschränkt und vielleicht ist das ja teil deines Problems (s. https://www.synology.com/de-de/know...in_to_DSM_with_root_permission_via_SSH_Telnet)...

Also: schon versucht, die synology für einen anderen adminuser (nicht root) für ssh publickey zu konfigurieren (ich hab es nach Anleitungen hier https://www.synology-wiki.de/index.php/Ssh_mit_Zertifikaten_absichern und hier https://www.techgrube.de/tutorials/ssh-login-mit-public-private-key-authentifizierung und hier https://forum.synology.com/enu/viewtopic.php?t=126166 geschafft)??

Solange der user, den du zum anmelden nutzt, in der admin Gruppe ist sollte alles gehen. wenn du ggf. andere Nutzer anmelden willst (etwa für sftp, nicht unbedingt ssh Zugriff aufs Terminal). die nicht in der admin gruppe sind, dann wird es ein klein wenig komplexer, weil du die /etc/passwd bearbeiten musst und die Änderung per script regelmäßig neu setzen lassen musst (guckst du hier https://blog.emeidi.com/2017/11/25/...ssh-login-auf-synology-diskstations-erlauben/ )...

Der elegante Weg ist eigentlich ssh-copy-id...wie gesagt, ohne Weiteres aber nicht als root...

Und nicht vergessen, den ssh-server die sshd_config neu einlesen zu lassen mit synoservicectl --reload sshd

hoffe, das hilft einigen so, wie es mir geholfen hat...

grüßle
the other
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat