SSH auf Standard-Account via key

[LukeLR]

Hallo liebe Gemeinde,
ein weiteres Mal benötige ich eure Hilfe. Aktuell bringt mich meine Synology zur Verzweiflung, wenn ich mich per SSH auf einen Standardaccount (nennen wir ihn "user", nicht root oder admin) verbinden möchte. Ich habe nach viel Ursachenforschung auf der Synology bereits festgestellt, dass in der /etc/passwd die Shell eines jeden Standardnutzers gesperrt ist, und dies mit einem Verweis auf /bin/sh korrigiert. Nun funktioniert der Login via Passwort auf "user", doch merkwürdigerweise nicht per Schlüssel.

Natürlich habe ich im Home-Verzeichnis von "user" (/volume1/homes/user) einen Ordner .ssh erstellt, und darin eine Datei authorized_keys, welche den öffentlichen Schlüssel meines Desktoprechners enthält. Auch ein Kopieren des .ssh-Verzeichnisses von root, in welchem ebenfalls der Schlüssel meines Desktoprechners hinterlegt ist (mit anschließendem Anpassen der Rechte) brachte keine Abhilfe. Auf den root-Account kann ich mich aber vom selben Desktoprechner mit selbem Schlüssel per SSH verbinden. Jemand eine Idee, wo hier das Problem liegen könnte? Google & Co. brachten keine Erleuchtung.

Über Lösungsvorschläge würde ich mich sehr freuen, und bedanke mich im Voraus
Lukas

 

[Fusion]

Da würde ich als erstes wohl mal die daemon config (etc/ssh/sshd_config) durchleuchten...
und den Verbindungsaufbau vom Client aus mal mit -vvv (triple verbose) machen.

 

[LukeLR]

Okay, probiere ich gleich mal aus! Danke schonmal

 

[LukeLR]

Den Output des Logins via ssh -vvv habe ich als Anhang angehängt, interessant sind wohl diese Zeilen:

debug1: Offering RSA public key: /Users/lukas/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/lukas/.ssh/id_dsa

Hier wird der relevante Key überprüft, doch es wird, ohne eine Fehlermeldung auszugeben, zur nächsten Authentifizierungsmethode übergegangen. Selbiges ist mir bereits beim Ausführen von ssh -v aufgefallen. Andere Keys außer id_rsa und id_rsa.pub sind im .ssh-Verzeichnis natürlich nicht enthalten. Was läuft hier schief? Angehängt ist darüber hinaus die sshd_config der Synology (natürlich im Original ohne die .txt-Dateierweiterung).

Für jegliche Hilfe bin ich weiterhin sehr dankbar!

 

[Fusion]

Es muss nicht nur ein private key auf dem Client vorhanden sein. Es muss nur sichergestellt sein, dass der Client weiß, welchen key er für welchen Server nehmen soll.
Ist der "user" jemand der sich am DSM anmelden kann? Bzw. hat dieser in /etc/passwd ein Home-Verzeichnis und die Shell eingetragen?

Bsp. ubuntu client (/etc/ssh/ssh_config), Verbindungsaufbau via "ssh user@syno", syno muss auf die richtige IP auflösen

Host syno
IdentityFile ~/.ssh/id_rsa.syno
Port xxx

Das nur zur Info.

Irgendwas ist da durcheinander. Aus dem Log (letzten 20 Zeilen oder so):
keys werden gesucht und der rsa gefunden (andere 0x0, nicht gefunden)
Client offeriert private key als public gegenüber dem Server
Client kann keine anderen private keys für Auth finden und wechselt zu nächsten Methode Passwort

Hättest du vielleicht noch die ssh_config vom Client? bzw. schaust dir die auch selber mal an.
Zusätzlich würde ich auch nochmal einen erfolgreichen root-login als Vergleich heranziehen, glaube aber nicht dass das viel hergibt.

Interessant wäre auch, was noch kommt, wenn du dich dann trotzdem mit Passwort einloggst (da könnte noch Info kommen, ob vielleicht doch Zugriffsrechte auf den pub-key falsch sind)

Glaube ich muss mir das nach etwas Schlaf nochmal ansehen, Gehirn ist etwas schwammig gerade.
Wie gesagt, ich schaue morgen nochmal und probiere auch mal bei mir was aus.

 

[Fusion]

Habe es gerade doch nochmal mit einem Normal-Nutzer probiert und es funktioniert hier.

/etc/passwd
user:x:uid:guid::/var/services/homes/user:/bin/ash

/volume1/homes/user/.ssh/authorized_keys und known_hosts
.ssh Permission 700
authorized_keys und known_hosts Permission 644, Besitzer user:users
Dateien nur kopiert aus /root/.ssh/ wie du auch schon mal.

An der sshd_config sehe ich nur den Unterschied, dass du die Ciphers fest eingetragen hast. Das habe ich bei mir auf der Spiel-DS nicht. Also vielleicht mal testweise auskommentieren.
Gibt vielleicht ein Problem mit Ciphers und den keys.
Die Auffälligkeiten aus dem Log im vorherigen Post konnte ich jedenfalls bei mir im Log nicht finden

Edit:
habe mal die Ciphers in die sshd_config eingetragen. Danach hatte ich connection refused, bis ich den SSH Dienst im DSM deaktiviert und wieder aktiviert hatte. Danach ging es auch mit dem Cipher Eintrag.
Ich habe die zu benutzenden Ciphers im DSM unter Terminal, Erweiterte Einstellungen nochmals neu ausgewählt. Nach deakt/akt von SSH tauche die Einträge bei mir ganz am Anfang der sshd_config jetzt auch auf. Meine Einstellung steht auf "hoch".
Deine Liste sieht noch angepasst aus, also vielleicht mal testweise auf eine Standardauswahl rücksetzen.

 

[LukeLR]

Ja, ich habe mal die Cipher-Liste verändert, um Speedtests über rsync zu machen. Die Zeile kann ich nachher mal auskommentieren, aber das verrückte ist ja, dass es mit dem Root-Benutzer und demselben Zertifikat problemlos geht, vom selben Rechner aus, mit denselben Konfigurationen. Also ich sitze hier an meinem Rechner, tippe ssh root@192.168.2.100 und es funktioniert, beende die Session, tippe ssh lukas@192.168.2.100 und es geht nicht. Also muss das Problem, dass den Login verhindert, doch irgendwie User-Spezifisch sein, oder?

 

[Fusion]

Ja, denke schon. Deshalb habe ich es ja gestern Nacht doch noch kurz getestet und meine Einstellungen für /etc/passwd und die authorized_keys geschrieben. Die sshd_config scheint identisch zu sein.
Cipher Auswahl und Bash (oder /bin/sh oder /bin/ash) hat auch keinen Einfluss. (Ich musste immer den SSH im DSM deaktivieren/aktivieren, damit Änderungen sauber übernommen wurden).

Zum Benutzer/ssh im DSM sehe ich auch keine besonderen Einstellungen. Mein user hat lesen/schreiben Berichtigung für "homes".

Darüber hinaus wäre jetzt noch die ssh_config auf dem Client einen Blick wert und einen zweiten Blick auf den Verbindungslog von gestern.
Danach gehen mir gerade die Ideen aus.

Edit:
Kannst mal probieren den private key direkt beim Aufruf mitzugeben.
ssh -i /path/to/id_rsa user@IP

Edit2:
Weitere Logs, enthalten leider nicht viel Info.
/var/log/synolog/synoconn.log
/var/log/synolog/synosys.log

 

[LukeLR]

Hallo Fusion, vielen vielen lieben Dank schonmal für deine ausführliche Hilfe! Hätte gar nicht damit gerechnet, dass sich jemand so viel Mühe macht, um mir bei der Problemlösung zu helfen. Tausend Dank! Das ist unbezahlbar und sehr bewundernswert Leider schaffe ich es momentan zeitlich nicht, mich darum zu kümmern - die Klausuren stehen an, und die Uni nimmt mich zu sehr in den Griff. Deshalb muss ich das Thema hier leider erstmal auf die lange Bank schieben (was mich selbst sehr ärgert, wo ich gerade so guten Support bekomme, aber ich habe leider keine andere Wahl...), aber noch nicht abschließen, in der Hoffnung, in den baldigen Semesterferien nochmal darauf zurückkommen zu können. Ich danke aber schonmal vielmals! Und werde die Tipps dann alle in Ruhe durchprobieren und berichten! Vielen dank!

 

[Fusion]

Kein Ding. EInfach wenn Zeit ist. ist bei uns auch nicht anders. War auch gerade 3 Wochen auf Dienstreise und hab NULL Forum gelesen.

 

[LukeLR]

Voll cool, danke!