SSH mit public key funktioniert nicht

[ProXy]

Hallo zusammen.

Ich versuche seit knapp 2 Stunden SSH mit public key zu sichern, allerdings klappt es einfach nicht. Ich habe eigentlich alle Dokus gelesen, die ich finden konnte, aber es klappt nicht. Es geht hier um den User "ProXy", mit welchem ich auch auf der Shell eingeloggt bin.

Was ich getan habe:
1. Mit PuTTY Keygenerator einen öffentlichen Schlüssel erzeugt und auf dem Windows Client gespeichert
2. Auf der Synology den Ordner ~/.ssh erzeugt, Rechte 700, Owner ProXy
3. Mittels SCP (alternativ auch von Hand kopiert) die Datei authorized_keys in .ssh/ abgelegt, Rechte 600, Owner ProXy
4. Den SSH Dienst neu gestartet

So sieht es auf der Syno aus:

ProXy@DS412:~/.ssh$ ls -la
total 4
drwx------  1 ProXy users  30 Apr 21 13:57 .
drwxrwxrwx+ 1 ProXy users  24 Apr 21 13:38 ..
-rw-------  1 ProXy users 477 Apr 21 13:57 authorized_keys

Wenn ich nun vom Windows Client aus per SSH als User ProXy verbinde, benötige ich nach wie vor ein Password. "ssh -v" ergibt folgendes:

C:\Users\ProXy_tf1xhgs>ssh -v ProXy@ds412
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
debug1: Connecting to ds412 [2003:d6:af0c:b500:211:32ff:fe14:3be1] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\ProXy_tf1xhgs/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\ProXy_tf1xhgs/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\ProXy_tf1xhgs/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\ProXy_tf1xhgs/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\ProXy_tf1xhgs/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\ProXy_tf1xhgs/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\ProXy_tf1xhgs/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\ProXy_tf1xhgs/.ssh/id_ed25519-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\ProXy_tf1xhgs/.ssh/id_xmss type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\ProXy_tf1xhgs/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to ds412:22 as 'ProXy'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:gsdiQQeXDxD8P9vDwv08TTmAw5IED2QNzBo2sxXH5Yk
debug1: Host 'ds412' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\ProXy_tf1xhgs/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\ProXy_tf1xhgs/.ssh/id_rsa
debug1: Trying private key: C:\\Users\\ProXy_tf1xhgs/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\ProXy_tf1xhgs/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\ProXy_tf1xhgs/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\ProXy_tf1xhgs/.ssh/id_xmss
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
ProXy@ds412's password:

Weiss jemand, woran der Fehler liegen könnte?

Danke vorab!

 

[the other]

Moinsen,
wirkt auf mich, als ob private Key nicht gefunden wird (unten) bzw. nicht so ist, wie es erwartet wird, es werden alle default Key-Orte nach dem Schlüssel durchsucht, dann geht er als fallback auf PASSWORD_Auth.

Geh doch der Einfachheit halber diese Schritte nochmal gezielt durch:

https://www.synology-wiki.de/index.php/Ssh_mit_Zertifikaten_absichern

In deiner Anleitung (was ich getan habe 1. bis 4.) steht auch nix davon, wo du den Private KEy hingetan hast...

Ich arbeite hier mit Linux und ohne Putty, daher halte ich mich mal etwas zurück...
In manchen Anleitungen wird aber auch angegeben, dass die Ordnerrechte nicht auf 0700 sondern 0755 gestellt werden müssen, nur der User darf Schreibrechte haben im /home Ordner...

https://forum.synology.com/enu/viewtopic.php?t=126166

https://www.synology-forum.de/archive/index.html/t-81695.html

 

[ProXy]

Den private key übergebe ich in Putty über die Optionen. Leider ohne Erfolg.

Diese Anleitung befolge ich Schritt für Schritt...das habe ich bestimmt schon ein Dutzend Mal gemacht. Kann man irgendwo nachprüfen ob der Public Key verwendet wird?

 

[TeXniXo]

Den private key übergebe ich in Putty über die Optionen.

Kannst du das näher ausführen? Da gibts ja ohnehin viele Möglichkeiten.

 

[ProXy]

Ich navigiere zu Connection -> SSH -> Auth, dort wähle ich unter 'Private key file for authentication' die Datei mit dem privaten Key aus. Anschliessend navigiere ich zu Session, und doppelklicke auf den Eintrag für die Synology.

Ist das etwa falsch?

Edit: Das war wohl tatsächlich nicht korrekt. Nun wird der private Key wohl übergeben, dafür scheint der Server damit auch nicht zufrieden:

login as: ProXy
Server refused our key

 

[the other]

Moinsen,
bin jetzt weder putty noch windows firm...daher die doofe Frage: kannst du (openSSH scheint ja vorhanden) das unter windows versuchsweise mal auf kommandozeile versuchen? Ich interpretiere die logfile so, dass auf c:// kein pukey gefunden wird, er geht ja alle key typen durch...

Und was mir gerade (ahem, langer Tag) auffällt: du schreibst du speicherst den PUBLICkey auf deinem Client (PC)...das wäre aber nicht der Ort für den öffentlichen Schlüssel, der gehört auf den Server (NAS)...lese ich dich falsch oder verwechselst du da was...wie gesagt, nicht der Putty Expert hier.

 

[ProXy]

Den Public key kopiere ich auf die Syno, am Client ist dieser gar nicht mehr vorhanden. Auf dem Client bleibt nur der private key, diesen lege ich "irgendwo" ab, da er zumindest in PuTTY sowieo von da genommen wird. Gebe ich die Datei in der cmd mit -i an, so erhalte ich: Load key "D:\\private.ppk": invalid format

Edit: Ich habe mit LogLevel DEBUG3 versucht das Logging zu erweitern, ich sehe dann aber dennoch nicht mehr. Entweder das Setting greift nicht, oder es passiert wirklich nichts, das heisst das public key file wird gar nicht benutzt.

 

[the other]

Moinsen,
jupp, das kann natürlich sein, dass die .ppk als Putty eigene Dateiform im Terminal nix bringt, da wird ja eine andere erwartet (unter Linux zumindest bei openSSH).

Hier noch mal zu Putty:

https://www.windowspro.de/thomas-drilling/putty-anmeldung-ueber-public-key-authentifizierung

Ich würde es alles wegtun, auf Null setzen und komplett neu machen (ja, doof, gerade, wenn du es schon zig mal wiederholt hast). Geht mir aber auch oft so, man versucht 3 mal, immer denselben Fehler drin, Haare gerauft, nochmal gelesen, Fehler bemerkt, Kopf auf Tisch geschlagen, zusammengeriisen, neu, klappt, freu.

Sieht bei dir so aus, als wenn Putty da eben einfach nicht die keys zusammenbringen kann.

Am Ende ggf. alles mal über die Kommandozeile laufen lassen, den gesamten Prozess, key auch dort erstellen, Putty mal weglassen:

https://www.thomas-krenn.com/de/wiki/OpenSSH_Public_Key_Authentifizierung_unter_Ubuntu

https://www.techgrube.de/tutorials/ssh-login-mit-public-private-key-authentifizierung

Bin mal gespannt, was die ssh Profis hier sagen, wenn die am Start sind...

 

[ProXy]

So, habe mal über die Shell die Schlüssel erzeugt. Dabei wurden die beiden Dateien erzeugt: id_rsa und id_rsa.pub

id_rsa.pub habe ich umbenannt zu authorized_keys

id_rsa auf den Client kopiert und mittels -i angegeben.

Ergebnis:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:CLp3XsVVLk5V63y13/Kb3CdrDoJvlTMn6Z2fupUbJKA D:\\id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
ProXy@ds412's password:

 

[Tommes]

Vielleicht hilft dir mein SPK SSHConfig da weiter. Neben der Generierung und Anzeige der SSH-Ordnerstruktur bietet die App auch eine kleine Hilfedatei, worin nochmal alles beschrieben steht bezüglich Schlüsselaustausch.

Tommes

 

[ProXy]

Hallo Tommes,

ich habe mit Hilfe deiner App alles nochmals neu aufgesetzt. Die drei erzeugten Dateien habe ich auf meinen Client kopiert, um beim SSH-Zugriff den privaten Schlüssel angeben zu können. Leider bleibt das Ergebnis unverändert.

debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:OonucQcF6oJ0Wivim4HwfycoYWWLuh5OjkI+IxwDDbg D:\\id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

So sieht deine App aus: https://prnt.sc/s3dja3

 

[Tommes]

Wow... und das alles in 10 Minuten? App installiert, Hilfe gelesen und RSA-Schlüssel erstellt. Sportlich!

Frage: Gibst du bei der Erstellung des RSA-Keys ein Passwort mit an? Falls ja, hast du da irgendwelche ungewöhnlichen Sonderzeichen drin?

 

[ProXy]

Als ich über deine App ein Kennwort vergeben habe, bestehend aus Buchstaben, Ziffern sowie einem ! meldete mir diese, dass das Passwort keine 5 Zeichen lang ist. Ich habe daraufhin ein einfacheres gewählt (nur kleine Buchstaben), dann lief die App durch.

 

[Tommes]

Die drei erzeugten Dateien habe ich auf meinen Client kopiert, um beim SSH-Zugriff den privaten Schlüssel angeben zu können.

In der Hilfe steht, das du den öffentlichen Schlüssel (id_rsa.pub) kopieren sollst, nicht den privaten (id_rsa).

Nichts desto trotz. Ich arbeite hier hauptsächlich mit WinSCP worin auch der Putty-Keygenerator enthalten ist. Ich habe dabei festgestellt, das dieser auch den privaten Schlüssel verarbeitet. Ist zwar nicht best practice, aber es funktionert.


WinSCP und PuTTY die Anmeldung per Key erlauben.

Benötigt wird die Schlüsseldatei id_rsa, welche man an einen gut zu erreichenden Ort, wie z.B. einem USB-Stick oder einem öffentlichen Share kopiert...

$ cp ~/.ssh/id_rsa /volume1/public

Anschließend muß in WinSCP für das Verbindungsziel unter...

Erweitert->Authentifizierung->Datei mit privatem Schlüssel

...der Speicherort zu der Schlüsseldatei angegeben werden. WinSCP generiert im Anschluss aus dieser Schlüsseldatei eine neue Datei mit der Dateiendung .ppk welche auch von PuTTY akzeptiert wird.

 

[ProXy]

Ich habe den Schlüssel auf der Synology erzeugt, dorthin möchte ich mich ja auch per SSH verbinden. Auf der Synology verbleibt doch eigentlich nur der öffentliche Schlüssel in der Datei 'authorized_keys'.

Um von Windows auf die Synology verbinden zu können, benötigt der Windows Client doch den privaten Schlüssel.

Oder ist daran etwas falsch?

 

[Tommes]

Der private Schlüssel verbleibt stets auf dem Server (deine DS). Nur der öffentliche Schlüssel wird weitergegeben. Bei der Verbindung zwischen Client (Putty) mit dem Server (deiner DS) wird der öffentliche Schlüssel von Putty mit dem privaten Schlüssel auf der DS verglichen und bei Übereinstimmung wird die Verbindung hergestellt. So sollte es eigentlich sein. Deine DS muss ja irgendwie den Schlüssel abgleichen können und das geht nur, wenn auf der DS halt der private Schlüssel, also die id_rsa vorhanden ist.

Lies in der SSHConfig Hilfe mal unter dem Punkt -Einrichten von SSH auf dem Remote Server-

 

[ProXy]

Ich habe mal eben das ganze mit einem rpi versucht. Dort hat alles sofort funktioniert, ich komme wie gewünscht ganz ohne Passwort auf den rpi. Also muss der Fehler an irgendetwas anderem liegen, mein Denken scheint zu stimmen.

 

[ProXy]

Ich denke inzwischen vertust du dich da selber auch etwas:



Der private Schlüssel ist auf dem Client. Der Client sendet diesen an den Server, der prüft, ob der öffentliche Teil in seinem Schlüssel zu finden ist und gleicht privaten und öffentlichen Schlüssel ab.

 

[Tommes]

Wenn du eine Verbindung von der DS in Richtung RPi aufbaust, dann muss auf deinem RPi aber auch ein privater Schlüssel vorhanden sein, richtig? Wenn auf deinem RPi nur der Schlüssel der DS in der authorized_keys eingetragen ist, dann kannst du dich vom RPi aus auf deine DS aufschalten, richtig?

 

[ProXy]

Ich habe den rpi als Server genutzt und so eingerichtet, wie ich es auch auf der Synology mache. Ich verbinde mich dann von meinem Windows Client auf den rpi. Auf dem rpi ist vorhanden:

pi@RaspScreen:~/.ssh $ ls -la
insgesamt 12
drwx------  2 pi pi 4096 Apr 21 17:18 .
drwxr-xr-x 19 pi pi 4096 Apr 21 17:18 ..
-rw-r--r--  1 pi pi  739 Apr 21 17:02 authorized_keys

Die Datei ist nichts weiter als die Datei id_rsa.pub umbenannt.

Der private Schlüssel id_rsa liegt auf dem Windows Client unter D:\x\
Die Verbindung stelle ich her mit:

C:\Users\ProXy_tf1xhgs>ssh -i D:\x\id_rsa pi@RaspScreen
Enter passphrase for key 'D:\x\id_rsa':
Linux RaspScreen 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l