for using in my smarthome I need ssh-access with an unprivileged user (fhem). I have a TP-Link WDR4900 (openwrt 19.07) and an Archer C7v5 (openwrt 24.10). Everything works fine (ssh fhem@archerc7 -i .ssh/id_rsa) on both devices.
After upgrading the Archer a password for ssh-Access (fhem) is required, but ssh root@archerc7 -i .ssh/id_rsa works.
What can I do?
So which of two opposites?
I prefer automatic login using fhem with keyfile (like at the wdr4900).
Could you please please please a little bit more verbose?! Nobody here is a mind reader.
What does work, and what does not? Do you see any error message?!
You do use ssh from your pc to the router/access point or also between the openwrt devices?
1 Like
I will try 
Both Routers (Archer C7 (192.168.35.253) and WDR4900) work as Accesspoint. I have a script for checking the presence of a specific MAC-Address (mobile Phone) on the router.
This is running on a Linux-LXC /Debian 13).
Old Version (target wdr4900: ssh fhem@wdw900 -i mykey) works, on openwrt 24.10 it works also with the archerc7 (ssh fhem@archerc7 -i mykey).
After upgrade the C7 to 25.12
debug1: Host '192.168.35.253' is known and matches the ED25519 host key.
debug1: Found key in /opt/fhem/.ssh/known_hosts:2
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-256>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Will attempt key: .ssh/id_rsa RSA SHA256: XXX explicit
debug1: Offering public key: .ssh/id_rsa RSA SHA256:XXX explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
fhem@192.168.35.253's password:
But ssh root@archerc7 can connect:
debug1: Found key in /opt/fhem/.ssh/known_hosts:2
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-256>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Will attempt key: .ssh/id_rsa RSA SHA256:XXX explicit
debug1: Offering public key: .ssh/id_rsa RSA SHA256:XXX explicit
debug1: Server accepts key: .ssh/id_rsa RSA SHA256:XXX explicit
Authenticated to 192.168.35.253 ([192.168.35.253]:22) using "publickey".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Entering interactive session.
I hope this will help.
Edit: fhem@archerc7 using password-auth works
Are path permissions up to authorized keys correct, ie not modifiable by user or root.
1 Like
root@TP-ArcherC7:/home/fhem/.ssh# ls -lah
drw------- 2 fhem users 0 Mar 8 18:54 .
drwxr-xr-x 3 fhem users 0 Mar 8 13:01 ..
-rw------- 1 fhem users 1.5K Mar 8 18:54 authorized_keys
-rw------- 1 fhem users 98 Mar 8 16:58 id_ed25519.pub
-rw------- 1 fhem users 730 Mar 8 13:32 id_rsa.pub
should the permission for /home/fhem/.ssh be 755 or 700?
Directories above it?
nice you chopped off 9/10 of debug and expect us to guess them </sarcasm>
what do you need ssh -v, ssh -vv, ssh -vvv?
Keys?, Ip-Adresses?
The devices are not availible via internet, so I can post everything.
server/client quirk initialisation and all 3 key negotiation steps as offered/accepted crypto alg (keys not needed)
fhem@fhem:~$ ssh -v fhem@192.168.35.253 -i .ssh/id_rsa -o PubkeyAuthentication=true
debug1: OpenSSH_10.0p2 Debian-7, OpenSSL 3.5.4 30 Sep 2025
debug1: Reading configuration data /opt/fhem/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.35.253 [192.168.35.253] port 22.
debug1: Connection established.
debug1: identity file .ssh/id_rsa type 0
debug1: identity file .ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_10.0p2 Debian-7
debug1: Remote protocol version 2.0, remote software version dropbear
debug1: compat_banner: no match: dropbear
debug1: Authenticating to 192.168.35.253:22 as 'fhem'
debug1: load_hostkeys: fopen /opt/fhem/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: sntrup761x25519-sha512
debug1: kex: host key algorithm: ssh-ed25519
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: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:Q97Ktst9039DUzVTJoVAj6x+nPKyIqsYRFd/kBVHjOU
debug1: load_hostkeys: fopen /opt/fhem/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '192.168.35.253' is known and matches the ED25519 host key.
debug1: Found key in /opt/fhem/.ssh/known_hosts:2
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-256>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Will attempt key: .ssh/id_rsa RSA SHA256:DVWUp88OwfF/qiAbFMKkuSLCO4e+UcbN6e4x6KU6aUg explicit
debug1: Offering public key: .ssh/id_rsa RSA SHA256:DVWUp88OwfF/qiAbFMKkuSLCO4e+UcbN6e4x6KU6aUg explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
fhem@192.168.35.253's password:
Server: logread-e dropbear
Sun Mar 8 19:57:31 2026 authpriv.warn dropbear[5728]: Bad password attempt for 'fhem' from 192.168.35.60:52898
Sun Mar 8 19:57:31 2026 authpriv.warn dropbear[5729]: Bad password attempt for 'fhem' from 192.168.35.60:52910
Sun Mar 8 19:57:31 2026 authpriv.warn dropbear[5728]: Bad password attempt for 'fhem' from 192.168.35.60:52898
Sun Mar 8 19:57:31 2026 authpriv.warn dropbear[5729]: Bad password attempt for 'fhem' from 192.168.35.60:52910
Sun Mar 8 19:57:31 2026 authpriv.warn dropbear[5728]: Bad password attempt for 'fhem' from 192.168.35.60:52898
Sun Mar 8 19:57:32 2026 authpriv.warn dropbear[5729]: Bad password attempt for 'fhem' from 192.168.35.60:52910
Sun Mar 8 19:57:32 2026 authpriv.info dropbear[5728]: Exit before auth from <192.168.35.60:52898>: (user 'fhem', 3 fails): Max auth tries reached - user 'fhem'
Sun Mar 8 19:57:32 2026 authpriv.info dropbear[5729]: Exit before auth from <192.168.35.60:52910>: (user 'fhem', 3 fails): Max auth tries reached - user 'fhem'
pubkey was not accepted. Is it in place on the ssh server and are permissions of path leading to it immutable to outsiders?
Just wondering if this could be due to recent changes in dropbear authorized_keys location handling, combined to logging as other user than root.
E.g. the local patch for pubkey location handling was rewritten, and there have been upstream changes, too. https://github.com/openwrt/openwrt/blame/main/package/network/services/dropbear/patches/100-pubkey_path.patch
Other angle might be somehow too short key, or deprecated key type, or something similar.
Third angle might be directory permissions, like brada already suggested. See
I think, we are on the right way.
I use dropbear on both openwrt routers, the error came after upgrading from 24.10 to 25.12 on the archerc7. Permissions on the client (debian13 LXC) are not changed. I have upgrade the Archer C7 via sysupgrade image.
Regarding permissions....
[test-user@hiten ~]$ FILE="$( realpath .ssh/id_ed25519.pub )"; while [[ "${FILE}" != "/" ]]; do stat --format="%A %U %n" "${FILE}"; FILE="$( dirname "${FILE}" )"; done; set +x
-rw-r--r-- test-user /home/test-user/.ssh/id_ed25519.pub
drwx-----x test-user /home/test-user/.ssh
drwx-----x test-user /home/test-user
drwxr-xr-x root /home
bernd@hiten ~ $ cat /home/test-user/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILM1p5NPyNIpATO0fSk79whAUWtaCETmK6U7tDMW26EU
[test-user@hiten ~]$ FILE="$( realpath .ssh/id_ed25519.pub )"; while [[ "${FILE}" != "/" ]]; do stat --format="%A %U %n" "${FILE}"; FILE="$( dirname "${FILE}" )"; done; set +x
-rw-r--r-- test-user /home/test-user/.ssh/id_ed25519.pub
drwx------ test-user /home/test-user/.ssh
drwx-----x test-user /home/test-user
drwxr-xr-x root /home
bernd@hiten ~ $ cat /home/test-user/.ssh/id_ed25519.pub
cat: /home/test-user/.ssh/id_ed25519.pub: Permission denied
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.