DS215j - Server refused our SSH key

[Imradi]

Hallo zusammen,
das Thema ist zwar nicht neu (den letzten Thread habe ich aufmerksam gelesen, hat mich aber leider auch nicht weiter gebracht :/ ) aber ich hänge irgendwie fest.

Ich versuche nun schon eine Weile, SSH-Zugang mit einem Key hinzubekommen. Die Anleitung in der Wiki habe ich durchgearbeitet. Mehrfach.
Hier ist der aktuelle Stand. Verbinden soll sich der Nutzer "admin":

Diskstation_215> ls -al /volume1/homes/admin
drwx------    2 admin    users         4096 Dec  9 22:19 .ssh

Diskstation_215> ls -al /volume1/homes/admin/.ssh
-rw-------    1 admin    users          397 Dec  9 21:47 authorized_keys

Den Key habe ich mit PuTTyGen erstellt und abgespeichert (später in PuTTy ausgewählt zum verbinden). Den Public Key habe ich aus dem Feld in PuTTyGen kopiert und in die "authorized_keys" per vi eingefügt (ist das normal, wenn ich im PuTTyGen den Key komplett kopiere, dann im vi per rechtsklick einfüge, das erste "s" von ssh fehlt? Hatte ich dann manuell nachgefügt).

Den SSH-Dienst habe ich dann neugestartet:

synoservicectl --restart sshd

Wenn ich nun per PuTTy drauf möchte mit Key, Hostname admin@diskstation_215 , bekomme ich nur den Fehler "Server refused our key". Wo ist hier mein Denkfehler?

 

[goetz]

Hallo,

ist das normal, wenn ich im PuTTyGen den Key komplett kopiere, dann im vi per rechtsklick einfüge, das erste "s" von ssh fehlt?

ja, wenn man nicht durch Eingabe von i (input) in einer leeren Zeile in den Input Modus wechselt. Dann ist das erste s das Kommando für substitute characters.

Gruß Götz

 

[Imradi]

ja, wenn man nicht durch Eingabe von i (input) in einer leeren Zeile in den Input Modus wechselt. Dann ist das erste s das Kommando für substitute characters

Ah, immerhin wieder was gelernt. Danke
Um Probleme zu umgehen, habe ich per FTP das File auch noch mal direkt vom Rechner rübergeschoben. Damit garantiert keine Copy&Paste-Fehler passieren.

 

[goetz]

Hallo,
welches Format hat diese Datei? Wenn es DOS/WIN ist so können falsche Zeilenumbruchzeichen enthalten sein.

Gruß Götz

 

[Imradi]

Also eine Kontrolle ergab, dass das File in Codierung ANSI abgespeichert ist.

 

[dil88]

Es muss Unix-Zeilenenden haben.

 

[Imradi]

Beim FTP-Transfer habe ich auf "nur-text gestellt", das sollte ja ASCII übertragen.
Zur Sicherheit habe ich im vi noch :set ff=unix auf authorized_keys gejagt.
Ergebnis ist leider das gleiche: Server refused our key

Bald lass ichs einfach bleiben :/

 

[goetz]

Hallo,
mit der Standardeinstellung von puttygen wird ein 226 Zeichen langer Key generiert. Die Dateigröße von authorized_keys ist ebenso 226 Byte. Alles ist in einer Zeile ohne Zeilenumbruch am Ende.
Der Key beginnt mit ssh-rsa AAAA und endet mit = rsa-key-20120714 (Datum der Erstellung)

Gruß Götz

 

[Imradi]

Vielen Dank Götz! Damit wäre dann auch geklärt, dass ich zu doof bin, einen SSH-Key ordentlich zu generieren :/ Bei mir war PuTTyGen Standardmäßig auf 2048 bit eingestellt. Ich habe nun einen mit 1024 erstellt und teste gleich..

€: Mist, wäre ja auch zu einfach gewesen Auch das keyfile mit korrekter Größe wird zurückgewiesen. Erstellt direkt mit vi in der Shell.

Using username "admin".
Server refused our key
admin@diskstation_215's password:


BusyBox v1.16.1 (2014-11-06 16:02:07 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Diskstation_215> cd /volume1/homes/admin/.ssh
Diskstation_215> ls -al
drwx------ 2 admin users 4096 Dec 14 21:30 .
drwxrwxrwx 3 admin users 4096 Dec 9 22:42 ..
-rw------- 1 admin users 226 Dec 14 21:31 authorized_keys
-rw-r--r-- 1 admin users 204 Dec 11 18:06 known_hosts
Diskstation_215>

 

[goetz]

Hallo,
hast Du dann auch den neuen Private Key gespeichert und der putty Session zugeordnet?

Gruß Götz

 

[Imradi]

Das habe ich getan, ja. Mir gehen langsam die Ideen aus. Mich beschleicht langsam das Gefühl, bei der DS 215j wurde irgendetwas geändert, dass das auf dem altbekannten Wege nicht mehr funktioniert :/

.. wesentlich wahrscheinlicher ist aber wohl, dass ich es einfach nicht draufhabe
Ich versetze später alles nochmal auf den Ursprungszustand und starte nochmal bei 0 genau nach Anleitung. Ich wüsste nun nicht mehr, wo ich noch irgendwo Abweichungen hätte.

 

[jahlives]

mal in den Logs (/var/log/) geguckt ob etwas zum Grund der Ablehnung steht? Vielleicht steht was in messages

 

[Imradi]

Das Log habe ich nun gecheckt. Zwischen Bootup und Hibernation (als mein Verbindungstest stattfand), befindet sich leider nichts im Logfile.

Nachtrag: Ich protokolliere hier nun mal live meine durchgeführten Schritte. Ihr sagt dann einfach, an welcher Stelle ich mist baue
(Sorry für den Megapost! :/ )

Zunächst alles Rückgängig:

• PublicKeyfile und PrivateKeyfile lokal gelöscht.
• Ordner /volume1/homes/admin/.ssh komplett entfernt:
  

  Diskstation_215> pwd
  /volume1/homes/admin
  Diskstation_215> ls -al
  drwx--x--x    2 admin    users         4096 Dec 15 16:32 .
  drwx--x--x    5 root      root          4096 Dec  6 18:34 ..

• sshd_config default wiederhergestellt:

  cp /etc.defaults/ssh/sshd_config /etc/ssh/sshd_config

Dann von vorn den Lack:

• SSH-Key mit PuTTYGen erstellt: SSH-2 RSA 1024 bits - passphrase vergeben, Public und Private gespeichert. Kompletten public key aus dem Feld oben in die Zwischenablage gepackt.
• /volume1/homes/admin/.ssh/ erstellt, darin authorized_keys, Rechte angepasst:
  

  Diskstation_215> pwd
  /volume1/homes/admin
  Diskstation_215> mkdir .ssh
  Diskstation_215> chmod 0700 .ssh
  Diskstation_215> touch .ssh/authorized_keys
  Diskstation_215> ls -al .ssh
  drwx------    2 root     root          4096 Dec 15 16:45 .
  drwx--x--x    3 admin    users         4096 Dec 15 16:44 ..
  -rw-r--r--    1 root     root             0 Dec 15 16:45 authorized_keys
  Diskstation_215> chown -R admin .ssh
  Diskstation_215> chmod 0600 .ssh/authorized_keys
  Diskstation_215> ls -al .ssh
  drwx------    2 admin    root          4096 Dec 15 16:45 .
  drwx--x--x    3 admin    users         4096 Dec 15 16:44 ..
  -rw-------    1 admin    root             0 Dec 15 16:45 authorized_keys

• sshd_config NICHT angefasst. Soll ja ohne laufen.

• vi authorized_keys

  - "i" gedrückt für Input (danke für den Hinweis!), rechtsklick zum einfügen - "ESC" zum beenden des Modus und :wq für Save-Quit:
  

  -rw-------    1 admin    root           226 Dec 15 16:51 authorized_keys

• Dienst restart mit

  Diskstation_215> synoservicectl --restart sshd

• PuTTY gestartet, den neuen PrivateKey unter SSH -> Auth eingestellt, Verbindung zu Host admin@Diskstation_215 mit passendem Port versucht:
  

  Using username "admin".
  Server refused our key
  admin@diskstation_215's password:

Wo ist denn da mein Denkfehler? /var/log/messages ist leer nach dem Boot der Box.

 

[Tommi2day]

Bei mir tut das ohne Probleme. Der User muss sich auch normal anmelden können, also in /etc/passwd reinschauen, das dort im letzten Feld (Shell) kein /sbin/nologin sondern /bin/sh drinsteht. Dann als root ein su - <user> versuchen.
Bei PuttyGen muss die Openssh-Version des Public-Keys (ganz oben in der Box) in die authorized_keys in einer durchgehenden Zeile kopiert werden. Das .ssh Verzeichnis hat bei mir die Rechte 755, die authorized_keys 600.

 

[Imradi]

Danke für deinen Input Tommi. Bei all den Problemen hab ich doch was sehr positives entdeckt. Nämlich die Community hier im Forum. Ist echt toll, wie hier geholfen wird

also, der User sieht in der /etc/passwd so aus:

admin:x:1024:100:System default user:/var/services/homes/admin:/bin/sh

Rein aus Neugier: Wie würde ich das ändern, wenn da /sbin/nologin stünde? Einfach in der Datei ändern?

su admin funktioniert:

/volume1/homes/admin $

Den Public-key habe ich in einer Zeile in der Datei stehen, kopiert aus dem Feld für openSSH in PuTTYGen.

Und dennoch.. "Server refused our key", ohne Abfrage der Passphrase oder so, direkt bei Verbindung. :/

 

[Tommi2day]

Einfach in der Datei ändern?

genau

"Server refused our key", ohne Abfrage der Passphrase oder so, direkt bei Verbindung

Du kannst versuchen, den private Key von einer anderen Linux Machine mit ssh -i <id_file> -vvv zu testen, ob das ein Putty-Problem ist. Mehr fällt mir langsam auch nicht mehr ein.

Ich lasse meine Keys immer auf einer Linux-Maschine erzeugen. Das kannst Du auch auf der Syno machen. Einfach ssh-keygen -t rsa als als der User ausführen und die defaults übernehmen. Im .ssh Verzeichnis sollten dann die Keys liegen. das id_rsa.pub file gleich zu authorized_keys kopieren und die Rechte auf 600 ändern. Ein ssh localhost (also auf sich selbst) sollte dann sofort funktionieren. Das id_rsa File importierst Du dann nach Putty.

 

[Imradi]

Ich werd noch bekloppt. Ich geb es echt auf..

Ich habe nun den Key direkt auf der Syno erstellt:

ssh-keygen -b 1024 -t rsa

Das Ergebnis, nach cp des .pub nach authorized_keys und chmod:

Diskstation_215> ls -al
drwxr-xr-x    2 admin    root          4096 Dec 17 20:20 .
drwxrwxrwx    3 admin    users         4096 Dec 15 16:44 ..
-rw-------    1 admin    users          235 Dec 17 20:20 authorized_keys
-rw-------    1 admin    users          966 Dec 17 20:18 id_rsa
-rw-r--r--    1 admin    users          235 Dec 17 20:18 id_rsa.pub
-rw-r--r--    1 admin    users          178 Dec 17 20:12 known_hosts
Diskstation_215>

Ein

ssh -i id_rsa -p 5022 -vvv localhost

verläuft Negativ für Key-Auth:

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: id_rsa (0x2bb09330), explicit
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
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
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
admin@localhost's password:

Das id_rsa habe ich nach PuTTY übernommen und erhalte nun das:

Unable to use key file "F:\Dokumente\id_rsa" (OpenSSH SSH-2 private key)
Using username "admin".

Darf doch nicht wahr sein

 

[Tommes]

Versuch es doch einfach mal mit...

ssh-keygen -t rsa

Woraufhin dann im Benutzer-Home Ordner (bei mir root) sowas raus kommen sollte...

/root/.ssh
/root/.ssh/id_rsa
/root/.ssh/id_rsa.pub

Den Inhalt der Datei /root/.ssh/id_rsa.pub z.B. mit vi editieren und den Inhalt für die weitere Verwendung des Keys z.B. in die Zwischenablage kopieren. Fertig.

Damit hatte ich damals den RSA-Key zwischen DS und Raspberry Pi erstellt. Lief bei mir ohne Probleme. Jedoch habe ich bei der Generierung des RSA-Keys kein Benutzer / Passwort eingegeben, sondern diesen Punkt einfach übersprungen.

Tommes

 

[Tommi2day]

2 probleme sehe ich noch:
1. Verzeichnisrechte

drwxrwxrwx 3 admin users 4096 Dec 15 16:44 ..

Das übergeordnete Verzeichnis darf keine Schreibrechte für andere haben, bei mir

drwxr-xr-x 5 admin users 4096 Dec 15 20:18 ..

nun bitte nochmal den lokalen Connect prüfen.
2. id_rsa ist nicht direkt in Putty verwendbar, sondern muss erst mit puttygen importert und in ein ppk umgewandelt werden.

 

[Imradi]

2 probleme sehe ich noch:
1. Verzeichnisrechte
Das übergeordnete Verzeichnis darf keine Schreibrechte für andere haben, bei mir
nun bitte nochmal den lokalen Connect prüfen.
2. id_rsa ist nicht direkt in Putty verwendbar, sondern muss erst mit puttygen importert und in ein ppk umgewandelt werden.

Ok.. peinlich. Ich habe 2. behoben. Ist mir nicht mal aufgefallen.. Mit dem importierten Schlüssel noch mal getestet, dann kam immerhin wieder der gewohnte Fehler "Server refused our key".

Dann habe ich 1. behoben, CHMOD 755 (wobei ich ohne Mist das als einziges nicht geändert habe, das kam von Haus aus schon so. Alle User-Homes kommen mit 777 bei mir o.o).
Connect mit Key getestet... und es geht?! Kein Klagen, kein Meckern.. es kommt die Frage nach Passphrase und nach eingabe bin ich drin. Das hätte ich nun nicht erwartet.
Aber mein Dank ist dir gewiss, Tommi2day! Und natürlich allen anderen, die hier fleißig mitgeholfen haben.