"permission denied" ssh-publickey zu OpenWrt 19.07.7 (F!B 4040)

Technik
1

Hallo Freunde!

Obwohl ich selbstverständlich auch aktiver Freifunker bin (5 Router im Bereich KBU) handelt es sich bei meiner Frage NICHT um Freifunk. Ich möchte aber trotzdem hier fragen, weil ich weiß, dass sich hier die Wissensträger bezügl. OpenWrt tummeln. :grinning:

Vorbemerkung: Ich verwende seit vielen Jahren ssh zur Remoteverbindung auf allen meinen Linux-Rechnern, meinen 5 RasPi, meinen 5 FF-Routern und auch meinen mittlerweile 9 Wireguard-Servern (F!B 7412 und 4040).
Ich nutze für jedes meiner zur Remoteverbindung genutzten Geräte (PC, Notebook und Smartphone) einen eigenen RSA-Key (4K), verbiete in der sshd- oder in der dropbear-Config die Password-Auth und habe auch überall meine authorized_keys mit den drei public keys hinterlegt. Und es funktioniert auch selbstberständlich alles so, wie gewollt. Eine Verbindung per ssh ist also für mich etwas ganz normales, wo ich auch bislang keine Fragen hatte.

Außer: bei meinem neuen zentralen Wireguard-Server, welcher auf einer F!B 4040 läuft. Und das ist hier meine Frage.

Sobald ich eine Verbindung per ssh aufbauen will, kommt die Meldung „Permission denied (publickey)“.

  • Aktiviere ich per luci die Passwort-Auth, wird das PW von root abgefragt und ich bin „drin“. Will ich aber nicht.
  • Dass dropbear aktiv ist, sagt ja schon das oben genannte,
  • Auf allen 9 Wireguard-Geräten ist der gleiche SW-Stand (OpenWrt 19.07.7 r11306-c4a6851c72).
  • Gleiches trifft für die dropbear-Version zu (2019.78-2).
  • Alle Berechtigungen stimmen, völlig identische /etc/dropbear/authorized_keys und /etc/config/dropbear auf allen 9 Geräten.
  • Starte ich den Verbindungsversuch mit der Option -v sehe ich neben IMHO unrelevanten Zeilen lediglich „Permission denied“.

Ich habe das Gefühl, dass dropbear einfach auf der 4040 nicht mit public key auth arbeiten will.

Kann mir bitte jemand von euch auf die Sprünge helfen?

MfG Peter

2

Hast Du vielleicht ein ECDSA key verwendet? Falls ja, probiere es mal mit DSA oder RSA. Kann sein dass die Dropbear die modernsten Keys noch nicht frisst.

3

Das ist es leider nicht. Trotzdem vielen Dank!
Ich habs auch mit einem 2K-RSA getestet. Und sogar mal einen ECDSA probiert. nix …

4

Spuckt er bei ssh -vvv ... vielleicht einen Hinweis, der Dir was sag, aus?

5

Ich habe bei -vv aufgehört zu suchen und zu verstehen. Werde es trotzdem noch mal mit „supersupergeschwätzig“ versuchen.

Habe mir auch gerade noch mal auf dem Client die beiden known_hosts angesehen. Die erste mit dem korrekten RSA-Key des Servers und die zweite mit dem ECDSA. Der dropbear will also, und scheitert dann an der Authentisierung.
Wenn ich nicht auf allen meinen Geräten die (geprüft!) identische authorized_keys hätte und ich es auch mit allen drei Clients versucht hätte, würde ich an einen korrupten Schlüssel glauben.

6

So, mit -vvv getestet. Er will nicht mit publickey - mehr lese ich aber nicht heraus.
Bei einem „richtigen“ sshd würde ich in der sshd_config nachsehen, aber dropbear mit seinen drei Zeilen …
Kann man bei dropbear das gezielt eintragen? Ich habe es mit verschiedenen Varianten versucht, kam zwar beim Neustart keine Fehlermeldung aber auch kein Erfolg.

peter@erde:~/.ssh> ssh openwrt-wgs -vvv -i id_rsa
OpenSSH_8.4p1, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /home/peter/.ssh/config
debug1: /home/peter/.ssh/config line 8: Applying options for openwrt-wgs
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.188.200 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/peter/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/peter/.ssh/known_hosts2'
debug2: ssh_connect_direct
debug1: Connecting to 192.168.188.200 [192.168.188.200] port 22.
debug1: Connection established.
debug1: identity file id_rsa type 0
debug1: identity file id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4
debug1: Remote protocol version 2.0, remote software version dropbear
debug1: no match: dropbear
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.188.200:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/peter/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/peter/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.188.200
debug3: order_hostkeyalgs: prefer hostkeyalgs: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,kexguess2@matt.ucc.asn.au
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: aes128-ctr,aes256-ctr
debug2: ciphers stoc: aes128-ctr,aes256-ctr
debug2: MACs ctos: hmac-sha1,hmac-sha2-256
debug2: MACs stoc: hmac-sha1,hmac-sha2-256
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-rsa SHA256:yi7N8pmP8RmCaIS2sSqUsASGRr6jNIjlM7xzs1ZTnYw
debug3: hostkeys_foreach: reading file "/home/peter/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/peter/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.188.200
debug1: Host '192.168.188.200' is known and matches the RSA host key.
debug1: Found key in /home/peter/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: id_rsa RSA SHA256:AszE1pWqII7NOmDQUcnaOSTK+NJ5S+a4rNZae3UkaNA explicit
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
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 public key: id_rsa RSA SHA256:AszE1pWqII7NOmDQUcnaOSTK+NJ5S+a4rNZae3UkaNA explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
root@192.168.188.200: Permission denied (publickey).
peter@erde:~/.ssh>
7

So wie ich es vom Eingangspost verstanden habe kommst Du per password-ssh drauf, wenn Du es im UI freigibst/einstellst.
In dem Fall:

  • per ssh-password-auth einloggen,
  • publickey-only wieder aktivieren und ssh-demon von der bestehenden ssh-konsole neu starten (vermutl „/etc/init.d/dropbear restart“(?)), NICHT AUSLOGGEN!
  • „logread -f“ starten und offen lassen
  • ssh-login-versuche von extern starten und schauen, dass die obige Konsole meldet.
  • evtl. den Loglevel für den Dropbear hochsetzen und demon nochmal neu starten.
8

Ja, mit Passwort geht es. Ich werde mal deinen Text abarbeiten. Schon mal vielen Dank!

edit: publickey-only wieder aktivieren
Gibt es dazu (so wie in der sshd_conf) einen speziellen Eintrag oder reicht es dazu, die beiden „Haken“ in der GUI zu entfernen. Also „keine Passwort-Auth“ = „publickey Auth aktiv“?

9

Die ersten zwei Punkte sind abgearbeitet. Vermutlich meintest du „logread -f“ =>

root@OpenWrt-wgs:~# logread -f
Sun Apr 25 19:22:55 2021 authpriv.info dropbear[3099]: Child connection from 192.168.188.10:39072
Sun Apr 25 19:22:55 2021 authpriv.info dropbear[3099]: /etc/dropbear must be owned by user or root, and not writable by others
Sun Apr 25 19:22:55 2021 authpriv.info dropbear[3099]: Exit before auth (user 'root', 0 fails): Exited normally


drwx------    1 1026     1002             0 Apr  4 18:46 dropbear/

root@OpenWrt-wgs:/etc# ll dropbear/
drwx------    1 1026     1002             0 Apr  4 18:46 ./
drwxr-xr-x    1 root     root             0 Apr  9 15:43 ../
-rw-------    1 1026     1002          2298 Apr 24 18:44 authorized_keys
-rw-------    1 1026     1002           804 Feb 27  2020 dropbear_rsa_host_key
root@OpenWrt-wgs:/etc#

Und 1026 kam mir dann bekannt vor, dass bin ICH auf meinem PC!
Werde ich dann gleich mal ein chown machen … .

Fazit:
So eine Sch…!!
Kaum macht man es richtig, schon funktioniert es.
Ich wusste natürlich, dass das alles root:root sein muss. Habe es, und sogar die Rechte bestätigt.
Wobei die Frage bleibt, wie das passieren konnte. Ich habe ganz am Anfang nachgesehen, alles root:root. Jetzt sehe ich einige (weitere) Einträge, wo 1026 Besitzer ist. Ich bin mir ganz sicher, dass ich da nirgendwo (bewusst) was geändert habe.

Vielen Dank Andreas (?) und Christian, ich habe heute wieder viel gelernt.

MfG Peter

10

Natürlich, „logread -f“, nicht „syslog -f“.
In die Falle mit dem owner und chmod für die authorized_keys bin ich schon mehrfach gerannt, aber irgendwie noch nie unter openwrt, weil man da ja irgendwie defaultmäßig root ist und neue Dateien immer „für einen selbst“ sind als create-mode.

11

Hallo Andreas,

ich habe wirklich in der Nacht noch etwas über das „warum“ gegrübelt.
Ich glaube, dass ich in die Falle mit dem falschen Nutzer oder mit falschen Rechten wohl nur ein einziges mal - und das vor vielen Jahren - gelaufen bin. Ich habs ja auch (gleich nach der Installation) gezielt überprüft und in einem meiner Beiträge erwähnt.
Bei meinen „richtigen“ Linux-Installationen deaktiviere ich immer in der sshd_config die Anmeldung als root und auch die mit Passwort. Selbstverständlich erst dann, nachdem ich die Anmeldung mit public key getestet habe :wink: . Dropbear gestattet ja von Hause aus (leider) nur eine Anmeldung als root.
Also muss ich definitiv als root angemeldet sein. Habe ja auch keine anmeldefähigen user auf der Kiste. Und auch wenn ich mich (was ich ja unendloch oft gemacht habe) über die GUI anmelde, bin ich root.
Ich kann es einfach nicht verstehen, wie ein user (der auch auf seinem PC nur user ist!) in einem nur für root beschreibbaren Bereich oder bei root gehörende Dateien/Ordner Änderungen vornehmen kann.
Genau das werde ich demnächst noch einmal intensiv testen, indem ich mich (auf einem unrelevanten Router) per ssh als root anmelde und dann auf Deibel komm raus Dateien anlege/ändere, chown auf root-Dateien durchführe und anderen Blödsinn.

Die Schrecksekunde kam gestern, als ich mir vorstellte, dass das Problem nicht auf meinem vor mir liegenden WG-Server auftrat, sondern auf einem der beiden Wireguard-Server, welche sich in Dänemark oder in Ungarn befinden :frowning:

Gezogene Lehre: Immer vor dem Abmelden noch mal einen Kontrollblick auf relevante Dateien bzw. relevante Ordner werfen! Soviel Zeit habe ich ja als IT-Rentner.

Nochmals vielen Dank!

MfG Peter