[GELÖST] passwordless ssh key login geht nicht

[jmaus]

Das ganze SSH password-less setup sollte also im Grunde ein "no-brainer" sein

Achja, und damit das ganze NOCH einfacher bzw. flexibler ist in Zukunft habe ich gerade noch entsprechende "Include" statements zu den globale ssh_config/sshd_config Files hinzugefügt:

https://github.com/jens-maus/RaspberryM ... 2665d7b703

Damit sollte es ab der nächsten RaspberryMatic Version (3.55.x.YYYYMMDD) möglich sein eigene Konfigurationsparameter für die sshd_config und/oder ssh_config (für den client) unter /usr/local/etc/ssh abzulegen um so z.B. den standard SSH Port von 22 auf einen anderen Port (wenn man das will/braucht) umzubiegen, etc.

[jmaus]

Wie habt ihr ssh aktiviert? Ich hab in der UI unter Sicherheit den Haken gesetzt und das Passwort eingegeben. BZW. jetzt nochmal ausgehakt und ohne Passwort aktiviert. Beide Male keine Änderung.
Den Key hab ich auch nochmal via vim in die authorized_keys kopiert, statt die Datei via scp hochzuladen. Auch keine Änderung.

Ich verstehs einfach nicht.

Na dann schau doch mal in die /var/log/messages Datei rein was er denn ausgibt beim versuch sich von aussen zu verbinden. Irgendeine Fehlermeldung oder ähnliches wird da schon auftauchen, denn im Prinzip sollte das schon wie hier von mir beschrieben funktionieren (ausser natürlich du hast jetzt schon zuviel am Grundsystem selbst kaputtgepatcht)

[mtsonline]

ok, jetzt hab ich es zum Laufen gebracht.

Und nein, ich habe nichts kaputt gepatched

Bitte prüft doch mal bei euch die Rechte von /usr/local/etc und /usr/local/etc/ssh

Die waren bei mir standardmäßig auf 755 bzw 775
Müssen aber auf 700 stehen, weil sonst die authentifizierung fehlschlägt.
Und ich habe nichts verändert seit der Installation gestern.
@jmaus kann es sein, dass es hier in der letzten Version ev falsche Rechte dieser Verzeichnisse gibt? bzw das bei euch allen geht, weil ihr nicht die letzte Version installiert sondern upgedated hattet?

[jp112sdl]

Müssen aber auf 700 stehen, weil sonst die authentifizierung fehlschlägt.

Stimmt, kann ich reproduzieren (mit 3.55.3.20201127)

Hab es gerade mal auf der blanken .OVA getestet.

In /var/log/messages kommt auch

Code: Alles auswählen

bad ownership or modes for directory /usr/local/etc/ssh
...
bad ownership or modes for directory /usr/local/etc

Nach dem Ändern auf 0700 geht es sofort.

Scheinbar werden beim Einspielen eines Backups die Rechte aus dem Backup übernommen. Und da es früher irgendwann mal bei mir gepasst hat, klappt die Authentifizierung nach wie vor

[mtsonline]

Danke fürs Bestätigen hab wirklich schon langsam an mir gezweifelt.

ja, die Fehlermeldung steht dort, durch die hab ich es entdeckt. Gestern hatte ich dummer Weise aber nur nach error gesucht und es deshalb übersehen. Heute hab ich mal die letzten Meldungen angesehen.


Danke euch allen für die Hilfe!

Liebe Grüße

[jmaus]

Danke auch von mir für diese Hinweise bzgl. permissions. Habe den sshd startup script nun entsprechen angepasst damit dieser die permissions der /usr/local/etc/ssh directories&co beim start von sshd korrekt setzt damit dieser konfigurationsfehler nicht noch einmal passieren sollte. Siehe:

https://github.com/jens-maus/RaspberryM ... e8f8e05aa9

[RolfBensch]

Das funktioniert hier leider immer noch nicht (CCU3 mit V3.55.5.20201226). Im Logfile steht weiterhin:

Authentication refused: bad ownership or modes for directory /usr/local/etc

Code: Alles auswählen

root@ccu3-webui:~# ls -dl /usr/local/etc
drwxr-xr-x    5 108      110           1024 Dec 27 13:26 /usr/local/etc

user 108 und group 110 gibt es hier nicht. Wäre hier nicht noch ein chown root:root /usr/local/etc angezeigt oder schrotte ich damit irgendein Sicherheits-feature?

[jmaus]

Das funktioniert hier leider immer noch nicht (CCU3 mit V3.55.5.20201226). Im Logfile steht weiterhin:

Authentication refused: bad ownership or modes for directory /usr/local/etc
[...]
user 108 und group 110 gibt es hier nicht. Wäre hier nicht noch ein chown root:root /usr/local/etc angezeigt oder schrotte ich damit irgendein Sicherheits-feature?

Die Frage ist doch wie zum Himmel hast du es geschafft das eine andere userid+groupid hinzubekommen? Das musst du schon selbst gemacht haben oder das etc verzeichnis irgendwoher kopiert haben via WinSCP oder ähnlichen tools.

[RolfBensch]

Die Frage ist doch wie zum Himmel hast du es geschafft das eine andere userid+groupid hinzubekommen? Das musst du schon selbst gemacht haben oder das etc verzeichnis irgendwoher kopiert haben via WinSCP oder ähnlichen tools.

Gute Frage. Die CCU3 ist praktisch fabrikneu und bei Inbetriebnahme wurde direkt RaspberryMatic installiert. Danach lediglich ein paar Heizungsregler und Wandthermostate angehängt. Keine Add-Ons, kein Backup-Restore o.ä.. Von meinem bestehenden Backup-Server habe ich einen Bestands-Key von außen per scp nach /tmp kopiert und anschließend ein "cat /tmp/key.pub >/root/.ssh/authorized_keys" ausgeführt. Weiteres war dann nur noch Recherche weshalb das Ergebnis nicht funktionierte. Weil ich diesen Thread gefunden habe, hatte ich auf das nächste Release gewartet (ohne Ausführung von chmod und chown auf diverse Verzeichnisse) und dieses heute installiert. Die Aktionen auf der CCU3 waren also sehr, sehr überschaubar - und dennoch diese Situation. M.E. kann das, sofern das nicht RaspberryMatic getan hat, nur über die Orginal-Firmware gekommen sein.

Ich habe das jetzt gelöst, indem ich chown root:root auf /usr/local/etc und /etc ausgeführt habe. Damit kann ich mich jetzt problemlos mit Key authentifizieren.