Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have root login disabled in SSH and I want to be able to eliminate the possibility of a sudo user editing the /etc/ssh/sshd_config file and enabling root ssh login. Is this possible?

share|improve this question
Unsure, but potentially you could use LSM (grsecurity/AppArmor/SELinux etc) to finegrain what sudo can do. Then it should be possible to limit the "unlimited power to file permissoins" for root. – humanityANDpeace Mar 31 '14 at 14:04

Ultimately, blacklists don't work: it would be a vain endeavour to try to find all ways by which a root-equivalent user could alter the contents of /etc/ssh/sshd_config and try to fix them all. For instance, a lot of commands can output some data in a file whose name is provided as parameter -- that could be used to alter /etc/ssh/sshd_config.

Instead, use whitelists: explicitly allow sudoers to run an explicit, small sets of commands (e.g. a command to trigger a reboot, if that is relevant to your situation), and all others must be forbidden.

Alternatively, use SELinux to constrain sudoers into a not-exactly-root role and get /etc/ssh/sshd_config out of their reach. But this may involve some considerable configuration work (SELinux seems to be up to the task, but I have not tried it, so I do not guarantee success here). Also, be aware that the power of nuisance of a rogue root user tends to be pervasive: there are many many ways by which such a user can harm your security. It seems better to just not trust evil people with sudo powers. Or maybe some more comprehensive isolation layer would be warranted: instead of having several users in a single machine, with some semi-administrative powers, give a virtual machine to each user, that he may play with at will without impacting the other users. Depending on your context, this may or may not be applicable.

share|improve this answer
I like what your saying but its not about trusting evil people. It's about minimizing risk in the event that an account gets compromised (eg. someone looks over my shoulder with a set of binoculars and sees me enter my password) – Omar Jackman Aug 28 '13 at 19:04
I basically want to be able to do everything I need: yum install, vim, configure, make, etc. I was hoping there is a way to just make a new user group like sudoers and have it not be able to edit /etc/ssh/* – Omar Jackman Aug 28 '13 at 19:07
yum install manages the system packages -- including openssh and its configuration files, like /etc/ssh/sshd_config. If yum can do its job under whatever constraints you want to apply, then it can do anything, up to and including replacing the kernel. I fear that your problem does not have a solution as stated. – Tom Leek Aug 28 '13 at 19:30

The closest you are going to get to making that impossible is to use an extremely restricted set of what is possible through sudo. You will have to forbid access to vi, editors, shells and su. You're better off trying to determine what commands are necessary and hoping none of them have the ability to edit files or directories or execute commands.

Ultimately if you are giving someone privileges on your system, you are inviting risk.

There are some other alternatives you can consider:

Monitor the SSH logs for root logins with password auth. That's your leading indicator that your file has been changed.

Monitor that file for changes with a frequently running cron. If someone modifies that file and doesn't notice the monitor, you'll catch it.

share|improve this answer
If available, an auditd watch is likely better than polling or monitoring after the fact. If the OS and filesystem support it, making sshd_config immutable (e.g. via chattr), or mounting / read-only are possible alternatives. A last resort to permit selective sudo editing of files might be a chroot wrapper script, and a statically linked editor... yuck. – mr.spuratic Aug 28 '13 at 17:16
cat may be safe or not, depending on whether there are files that must remain confidential, such as a full-suoder's private ssh key. But tee is definitely unsafe. – Gilles Aug 28 '13 at 20:12
Agree with Gilles. I'll take cat off of my list. We're all cat people, right? – u2702 Aug 28 '13 at 20:49

Yes, with AppArmor it might be possible:

I have tried arround somewhat with using MAC (mandatory access control) and the AppArmor LSM (linux security module) and I found, that you might have a change using AppArmor to make /etc/ssh/sshd_config impossible to be written to using sudo.

This AppArmor profile would limit what the user can do after having gained "root power" via sudo

/usr/bin/sudo {
  capability setgid,
  capability setuid,
  / rw,
  /** rwmix,
  deny /etc/ssh/sshd_config w,
  deny /usr/sbin/aa* rw,
  deny /sbin/app* rw,
  deny /usr/bin/sudo rw,
  deny /etc/apparmor.d/profile.usr.bin.sudo rw,
  deny /sys/kernel/security/apparmor/ rw,
  deny /sys/kernel/security/apparmor/** rw,

To be safe, first lookup if there is already an preexisting AppArmor profile for /usr/bin/sudo

$ aa-status | grep sudo

In case there is none the output is empty! If not empty you should best talk to those guys who have setup the profile and not go on here.

If - as expected - there is not yet a profil you ca create one with this command:

root@computer:/root/# echo "/usr/bin/sudo {
>   capability setgid,
>   capability setuid,
>   / rw,
>   /** rwmix,
>   deny /etc/ssh/sshd_config w,
>   deny /usr/sbin/aa* rw,
>   deny /sbin/app* rw,
>   deny /usr/bin/sudo rw,
>   deny /etc/apparmor.d/profile.usr.bin.sudo rw,
>   deny /sys/kernel/security/apparmor/ rw,
>   deny /sys/kernel/security/apparmor/** rw,
> } " > /etc/apparmor.d/yourprofile.usr.bin.sudo

Then you can start/setup the new profile

root@computer:/root/# apparmor_parser -r /etc/apparmor.d/yourprofile.usr.bin.sudo
root@computer:/root/# aa-enable /etc/apparmor.d/yourprofile.usr.bin.sudo

resultingly a for a user this should be the result:

ssh_user@computer:~$ sudo bash -c "echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config"
[sudo] password for ssh_user: 
bash: /etc/ssh/sshd_config: Permission denied
ssh_user@computer:~$ sudo -i
root@computer:/root/$ echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config
-bash: /etc/ssh/sshd_config: Permission denied
root@computer:/root/$ aa-disable profile.usr.bin.sudo
Can't open perl script "/usr/sbin/aa-disable": Permission denied

Sadly I cannot give you insight how to implement this in other LSM like SELinux or grsecurity.

Anyways I would appreciate to get a feedback if the solution helped you :)

Be aware that the limitations regarding what can be done with sudo are for everybody and that means if you use sudo to get superuserpower you will suffer the same limitations (i.e. you cannot disable apparmor, nor /etc/ssh/sshd_config yourself. Only one who can is a real root via login.

share|improve this answer

You could write your /etc/ssh/sshd_config to a physically read only drive. In that case even if you were logged in as root itself, you could not change sshd_config.

But then you would have to watch out for

  • if the user can mount and unmount drives, then they could just unmount whatever drive you have sshd_config on
  • if the user has physical access to your machine, then they could just replace the disk
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.