I am developing a program that I want people to be able to connect to and use via ssh. I've decided a simple way of doing this would be to create an account for them on my linux server, and change which shell they use to login, to be my program instead of bash.

One measure I can take is to remove their PATH variable so that if they do somehow get access to bash, they won't be able to run any commands.

Is this horribly insecure? Am I replicating some other existing thing? Perhaps I should simply implement an SSL connection instead of SSH?

2 Answers 2


Removing the PATH variable wouldn't make any difference: if the users can run a shell command, then they could still set the variable, or run commands by giving their full path. If they somehow get access to a shell, you've lost.

Changing their shell to another does mean that their confined to that program — and anything they manage to launch from that program.

There is another way to restrict users who can only log in with SSH: you can give them a key (and not put a password on the account, so that the only way to log in is with the key), and put a command=… restriction in authorized_keys (see the sshd man page. This allows setting different commands on different keys for the same account, which may or may not be useful. Note that if you rely on restrictions in ~/.ssh/authorized_keys, you should make the user's home directory, the .ssh directory and its content owned by root so that the user cannot modify them.

If the program you want to give access to uses terminal interactions or is a stream filter, then dedicated SSH access is a good way to provide that service. If the program only produces output from a tiny amount of input, or if the program uses a fill-in-a-form type of interaction, then HTTPS would be more suited. Don't invent your own protocol on top of SSL for this — use whichever of remote shell (via SSH) or HTTP (via HTTPS) is the best for your program's interface. HTTPS will be easier to use for most users.

If you want to give the users some limited shell access that only allows them to run a limited set of commands, you can make their shell rbash, a restricted shell. Beware that restricted shells are hard to set up correctly: you need to make sure that none of the available programs have a shell escape (GNU sed, non-restricted versions of vi, …).

To confine the users more, jail them as much as possible. This can range from a mere chroot (which limits the files that the users can access if they manage to trick your program) to giving them an account only inside a full-blown virtual machine.

  • Is this a thing that people do? My program is definitely more of a command line thing rather than a simple form, so ssh is preferred to https. rbash sounds helpful too
    – Nacht
    Commented May 19, 2014 at 7:46
  • @Nacht Is what a thing people do? Commented May 19, 2014 at 7:49
  • There's a possible gotcha with the authorized_keys file: it's typically writable by the user, in a directory writable by the user. This means a user who can write to files in arbitrary locations can change or delete it.
    – Mark
    Commented May 19, 2014 at 8:01
  • @Gilles, use ssh for something other than shell access
    – Nacht
    Commented May 19, 2014 at 9:12
  • @Nacht Sure. For example, you're doing it. A common use case is for storage-only account, where the user is only allowed to run sftp-server or rsync or a few of this ilk. Commented May 19, 2014 at 9:17

(I'm assuming you're using OpenSSH here, since it's the default for Linux systems.)

Removing the PATH variable won't provide any security. If an attacker gets access to Bash, they can still use the shell's built-in commands, one of which lets them set PATH (and other environment variables) to whatever they want; further, they can still run programs by specifying the full path.

Changing the login shell provides some security: the user is restricted to doing things the login shell permits them to. There are some gotchas here on a Linux system, though: PAM is often configured to prevent login if the user's login shell isn't listed in /etc/shells.

If you're using OpenSSH, the ForceCommand configuration option in sshd_config can be used to force the user to run your program when they log in.

  • Changing the login shell does provide security. SSH passes receives a command as a string and runs the login shell with that string as an argument. The user is confined to what can be started from the login shell. Commented May 19, 2014 at 7:37
  • @Gilles, I tested this by running ssh mark@server grep xyzzy. There were five bash processes running before I logged in, and five running while grep was waiting. From this, I deduce that bash is not involved here.
    – Mark
    Commented May 19, 2014 at 7:39
  • Your deduction is incorrect. What actually happened is that ssh executed bash which executed grep. Compare with: bash -c 'grep xyzzy', ssh mark@server 'grep xyzzy; true'. When a command is the one last in a script, the shell sometimes optimizes by calling execve directly rather than forking a child, waiting for it to exit and immediately exiting with the same status. Also see what happens if you create an account whose shell is /bin/echo. Commented May 19, 2014 at 7:41
  • Nice to know about the ForceCommand option, does it mix well with the suggestions provided by Gilles?
    – Nacht
    Commented May 19, 2014 at 7:45
  • @Gilles, After further testing (I changed the login shell to /bin/true), I agree. I'll modify my answer accordingly.
    – Mark
    Commented May 19, 2014 at 7:54

You must log in to answer this question.

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