I'm trying to secure an account on our server called ssh_user that is used purely for connecting via SSH to our server. Everyone on our team logs into this account via a PSK secured ssh connection and tunnels to a specific port for our version control system. Security is maintained by everyone having their own PSK in the file /etc/ssh/ssh_user/authorized_users

The ssh_user account was created with sudo adduser -r -s /bin/sh ssh_user as to make the user a system account, with no home directory and as limited of a shell as possible.

Although these are already trusted users, the concern is always there of what access this account really needs, because I can still list directories in the root file system through this account, and read config files under /etc/ssh/..., so I'm wondering if this issue is as easy as issuing revoking all access to the group "others" across the entire filesystem with sudo chmod go-rwx /* ? I don't however know what (if anything) this would break on a default Ubuntu 16.04 install.

I'm by no means an expert at linux or security, and I'm not trying to pretend to know what I'm doing, so any input is greatly appreciated.


  • Why would you change a file or directory owned by -root- to something else? That one is already the best security you can get. "because I can still list directories in the root file system through this account" Ever heard of chroot'ing a user?
    – Rinzwind
    Jun 28, 2016 at 17:36
  • oh and you MUST treat / and /home as separate entities. /home/ needs things to be set to the user.
    – Rinzwind
    Jun 28, 2016 at 18:17
  • @Rinzwind They don't have home directories, so moot point there.
    – Kaz Wolfe
    Jun 28, 2016 at 18:19

2 Answers 2


Repeat after me: Running ANY permission command on / without knowing exactly what you're doing is a great way to break your system. Even if you know what you're doing, it's still probably the wrong thing to do.

In your case, the command won't work because it's the wrong one to start. Secondly, groups are a very valid Linux construct of users, and blocking off groups from accessing files is a really really bad idea.

If I'm understanding your case properly, you want to block users from resources that they aren't authorized to read. Fortunately for you, there are a few ways to do this, each with tradeoffs.

Option 1: No Shell At All (Best way)

You're using SSH to allow users to tunnel into a secure server, right? Why do users even need a shell in this case? Just block their access to the shell, and only let them tunnel!

To do this, simply create a new group called noaccess or similar. Then, copy and paste the below into your /etc/ssh/sshd_config file:

Match Group noaccess
    AllowTcpForwarding yes
    X11Forwarding no

If you want to be even more secure by restricting where they can tunnel, you can add the parameter PermitOpen to the SSH config. For example, if you want to only allow users to forward to port 1337 on the current server, you would add PermitOpen localhost:1337 to your config file, right under the AllowTcpForwarding directive, like so:

Match Group noaccess
    AllowTcpForwarding yes 
    PermitOpen localhost:1337
    X11Forwarding no

Finally, set the shell of the users to /bin/true by running the command chsh -s /bin/true <username>. Users will be silently (and forcefully) kicked back if they try to start any sort of interactive session. If you want to include a "friendly" error message, you can create a quick-n-dirty "fake" shell that will spit back an error message.

SSH gets rather annoyed when it can't access a shell, so you need to pass the command-line argument -N to the OpenSSH command, like so:

ssh [email protected] -N -L 3307:localhost:3306

If you're using PuTTY, make sure the highlighted checkbox is selected:

Don't start a shell or command at all

I've gone ahead and made a really simple (untested) shell that spits back an error message, and also keeps the terminal window open so that -N is unnecessary. You can find the source here if you want to compile and use it. Even with this, you should still use -N, but it's no longer absolutely necessary.

Option 2: Let them be

Users in Linux already have a pretty acceptable permission set. They can read files that are relevant to them and are important for the functionality of the system. At the same time, files that are "protected" (like private keys and /etc/shadow) already disallow reads from unauthorized users.

If your users are trustworthy already (and are actually going to be working on your system), this is the best option -- at the cost of keeping users out of where they don't belong

Option 3: Selective Targeting

If Option 2 is still too insecure for your needs, you can chmod o-rwx files that you don't want them to access. Examples of these include "secure" config files. However, you must be very careful that you don't cause services and applications to lose access to files that are needed to do their job.

You could also use Access Control Lists to block groups of users off of files, without setting them as the owning group. I caution, however, that this is fairly involved, and it opens up a way to allow users to "escape" their confined set if they find a shelled user that isn't in the blocked group.

Option 4: chroot

Using chroot allows you to control exactly what your users have access to. You decide what permissions, what commands, and so on. This is a very involved method that needs a lot of work to get working right, so it's not recommended for everyone.

If you're interested, this question explains it rather well.

  • Thank you for the detailed answer. This gives me a lot to work with, and I'm pretty sure option 1 is what I'm going for. There's no need to sandbox the account with chroot, because these are already trusted users, and there's no need to be so granular with the security by messing with access control lists. My next question was going to be about limiting their forwarding ports, and you answered that for me as well. Thanks! Jun 28, 2016 at 18:57
  • If my answer solved your problem, please consider clicking the little grey checkmark by it. It will mark the answer as "Solved" so it's easier for others to find, and it gives you some reputation as well!
    – Kaz Wolfe
    Jun 28, 2016 at 18:58
  • I'm doing this under a test account until I have it figured out, but when I run the command chsh -s /bin/true <username>, I am no longer able to maintain an SSH connection with my test account. I'm able to authenticate, and my putty output log shows that I am logged in , but then my ssh connection abruptly terminates. Any thoughts as to why this isn't working? Jun 29, 2016 at 2:14
  • 1
    @Jibberish51 This is very much intentional. The system kills any interactive sessions into the server, effectively forcing users to use noninteractive sessions (for example, tunneling). The shell will terminate but tunnels will remain open.
    – Kaz Wolfe
    Jun 29, 2016 at 8:57
  • 1
    @Jibberish51 Okay, I see what's going on. PuTTY is upset there's no terminal. In regular SSH, you need to pass the -N flag to it. I'm not sure of the PuTTY equivalent.
    – Kaz Wolfe
    Jun 29, 2016 at 16:23


sudo chmod go-rwx /*

would only allow root to access anything on your system which would break about everything.

See Simple & easy way to jail users for soem better ways to restrict what a user can do.

You must log in to answer this question.

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