I would like to set up a particular user account to have ssh access from a particular client using a public key, but prevent anyone logged in to this account from adding to the authorized_keys file.

I would have liked to make the .ssh directory contents owned by root so the account user cannot change it, but OpenSSH requires that the authorized_keys file be owned by the user.

I only want to do this with one account, so I want sshd to behave as usual with other accounts.

Is there another way of accomplishing what I want to do?

Thanks!
-C

Hello,

You could use chattr and make the file immutable. That wouldn't require any changes on the permissions, that is, you wouldn't need to change owner. Just use:
and the file will be immutable. Nobody, not even root, would be able to edit it and only root can change the attributes again. I think that's about your best option.

Kind regards,

Eric

1 members found this post helpful.

Nice idea, never though about it. But while it protect from editing/renaming/removing /home/<user>/.ssh/authorized_keys
User will still be able

For me it’s also working if ~/.ssh/authorized_keys is owned by root, as long as the file is readable by the user.

What about using hostbased authentication for this particular machine? The authorized_keys file could be empty then and owned by root, to avoid that someone copies the user’s private key on the client machine to another one (in case the purpose is to avoid access from another machine from this user), or destroys the private key and look theirself out.

But if .ssh owned by user then user still will be able remove authorized_keys and recreate this file with any content -
the very thing that OP tried to prevent

I didn’t say that it solves the problem, only that in my version of SSH it’s working in this case too.

With hostbased authentication it should be possible to disable public key authentication in /etc/ssh/sshd_config for this user/client machine.

I interpreter yours "works for me" as proposed solution. My bad.

Now that I re-read original post... I think that I miss whole point - why user shouldn't be able to modify his own
authorized_keys file, what do you actually trying to prevent?

@chrys, could you explain please?

Thanks to everyone who has responded to this question!

The purpose here is indeed to avoid access from another machine from this user. It's an account out of which a public web site runs, and the user account needs to be accessed by staff for administration, which should only be done from a very restricted (kiosk-like) machine (where one cannot just copy the secret key and take it awsy) in a particular office. The website is run out of this account, which is implemented as a mix of C CGI and PHP using suPHP.

Shell access is necessary for some functions, so SSH must be enabled so I can get in and do what needs to be done. The concern is that if there is an exploit in any of the suPHP scripts that allowed someone to write files, someone could execute code as the user that could add to authorized keys. open_basedir is not a defense against a binary helper program, and binaries must be able to run in the web directory.

I still don't understand why this specific user should access your box only from specific machine and others can do whatever they like. Or I miss something?

Anyway, may be AllowUsers option in the sshd config will help?

Erm.. if they can run code as the user, why wouldn't they just send an executing instance of /bin/sh back to themselves (and bypass most of the logging that sshd does)? Remember, if they're executing arbitrary code, you've lost.

Additionally, they'd be running as www-data/nobody/some other account, which is a completely separate user (unless you have your server running as root, and in that case you're boned).

I think you're making too niche of a security policy.