No-user-rc in authorized_keys prevent logging in with SSH

Hi,

I'm creating an account for running a single command when connecting with SSH into the router (Archer C7 v2 running OpenWRT 22.03.3, r20028-43d71ad93e). I'm using an authorized_keys file with a line disabling features I do not need for this purpose for security reasons:

command="mycommand",no-X11-forwarding,no-user-rc,no-port-forwarding,no-agent-forwarding ssh-ed25519  ....

I noticed that with no-user-rc my key is not accepted. Even if I just use:

no-user-rc ssh-ed25519  ....

the log in fails with Permission denied (publickey). Removing no-user-rc logging in works.

~/.ssh/rc does not exists, though as far as I understand this should not be a factor. I know, makes no sense to disable it if the file does not exists, but in principle it could be an additional attack vector.

Any idea why this is? Is this a bug in SSH/dropbear, or a feature? Have I misunderstood something in the documentation?

Cheers!

Dropbear Key Location perhaps ?

I would say that dropbear simply rejects pubkey entries with options it does not recognize, for security reasons. It's the sensitive thing to do. If you don't recognize an option you can't enforce it, so it's best to refuse authentication completely instead of inadvertently accepting something the administrator presumes to be denied.

And here's the proof in code of my assumption:

There's no match_option() clause for "no-user-rc"

2 Likes

Ah, that explains it!

I sometimes forget I'm actually using dropbear instead of sshd from openssh - but I'm using the documentation of the latter! :wink:

Thanks!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.