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?

  • 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. Commented Mar 31, 2014 at 14:04

6 Answers 6


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.

  • 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) Commented Aug 28, 2013 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/* Commented Aug 28, 2013 at 19:07
  • 1
    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
    Commented Aug 28, 2013 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.

  • 1
    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. Commented Aug 28, 2013 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. Commented Aug 28, 2013 at 20:12
  • Agree with Gilles. I'll take cat off of my list. We're all cat people, right?
    – u2702
    Commented Aug 28, 2013 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.

  • Downvote for being trivially bypassable. Commented Jun 20, 2019 at 22:33
  • @JosephSible Do you suggest that LSM are not effective in general, or apparmor in particular? if you can (trivally) sketch how the bypass would be done, would allow to improve the answer, thanks in advance :) Commented Jun 21, 2019 at 8:40
  • 1
    Both LSMs in general and AppArmor in particular are fine. The issue is with that particular profile. Allowing root to do everything except a few things is almost always a bad idea. Two ways of bypassing it immediately came to mind: 1. Add a job to /etc/crontab that overwrites sshd_config. 2. Run passwd to set a password for root that you know, then exit sudo, su to root, and change sshd_config. Commented Jun 21, 2019 at 12:55

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

I like Scottie's answer of chattr +i /etc/ssh/*

Perhaps then you then could use visudo -f /etc/sudoers to change to:

%sudo   ALL=(ALL:ALL) !/usr/bin/chattr, !/bin/su

This method should blacklist sudoers from running chattr and using sudo su but the easier method would just be to whitelist commands sudoers are allowed to run. All of this is one extra layer, but just like anyone with sudoer access, they can undo anything that root can.

  • sudo -i, run python as root and do a import sys... If you have limited sudo capabilities it's often extremely trivial to escalate this to total root access.
    – vidarlo
    Commented Jan 24, 2021 at 11:40

If it were me, I would just set the /etc/ssh files to immutable:
chattr +i /etc/ssh/*

Are you truly worried abut the file itself changing, or could you live with just knowing that the file has been changed?
If the latter, there are various intrusion detection programs (e.g. aide) that will monitor these files and alert you if it changes.
There are also configuration management programs, such as puppet or chef that can be configured to replace the files with a known good image if it were to change.

  • This can be undone with just a chattr -i. Commented Jun 20, 2019 at 22:35
  • Only if the us is smart enough to figure that out. Not everyone is. Anything that a smart SA can do can be undone by a smart hacker. It's really just trying to make sure it doesn't get changed accidentally by a user.
    – Scottie H
    Commented Jun 22, 2019 at 0:23
  • No, good security measures can't just be undone by any smart hacker. Only bad security measures can. Commented Jun 22, 2019 at 1:37
  • Disagree. It's like locking your car. That only keeps the honest people out. If a crook really wants your car, he'll take. Good security measures reduce the risk, they do not stop someone who really wants to mess with your system.
    – Scottie H
    Commented Jun 24, 2019 at 17:00
  • No, this is even less security than locking your car. Root can do chattr -i with no special security requirement, and only root can edit /etc/ssh/* anyway, so you've literally added no security boundary at all. Commented Jun 24, 2019 at 19:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .