Enable SSH shell access but disable SFTP access

Question

I've searched for a viable answer to this question, and most of the answers include advice on why to not do it. However, here's the scenario, and what makes it necessary:

I have a console app, and in each user's .profile, there is a startup command for the app, and directly after the command that starts it up, there's an "exit" command, which logs them out of the system. I only want them to be able to access this console app through the interface provided by it. Upon startup, the app presents the user with a list of clients that can be accessed through the app, with each client having their own data directory. Users are granted access to only the clients that they will need access to.

Now here's the problem: If I give the users SSH access, they will also be able to log in using an SFTP client, which will give them direct access to the data directories for the app, which is VERY undesirable, since that will also give them access to the data directories to which they should not have access.

This was such a simple thing to do when using a telnet/FTP combination, but now that I want to give the users access from anywhere on the internet, I haven't been able to find a way to shut them out of SFTP, while still allowing them access to the shell where they can run the app.

Answer 1

Edit:

In case it's not obvious, the following answer isn't intended as a secure method of preventing SFTP from being used by anyone with shell access to the server. It's just an answer that explains how to disable it from external visibility. For a discussion about user level security, see answers from @cpast and @Aleksi Torhamo. If security is your focus, this answer is not the proper one. If simple service visibiliy is your focus, then this is your answer.

We now continue to the original answer:

---

Comment out sftp support in sshd_config (and of course restart sshd):

#Subsystem sftp /usr/lib/openssh/sftp-server

Answer 2

As others have mentioned, disabling sftp isn't anywhere near sufficient - a user with unrestricted ssh access can view any file that their account has permissions to view, can modify anything they have permission to modify, and can easily download anything they can read to their own machine. The only way to stop them from doing this is to actually restrict their access. It's also not ideal to rely on .profile to restrict users, as that's not what it's for (Edit: As Aleksi mentions in his answer, it is in fact trivial to bypass .profile; the thing about .profile is that it's for convenience, not security, so it's not intended to restrict the user. Use things designed for security, like the things below, to provide security).

There are two basic ways to do this: you could restrict them via file permissions, or force them to only execute your console app. The second way is better: Assign users who should be restricted to the console app to a group (e.g. customers); then, in sshd_config, add the following lines:

Match Group customers ForceCommand /path/to/app 

What this does is make it so that all connections from users in that group open the console app; they cannot start anything else, including the sftp server tool. This also stops them from doing anything else with the system, and unlike .profile, does so using the SSH server itself (.profile restricts them at the shell, ForceCommand also prevents doing other things that don't involve starting a shell). Also unlike .profile, this is designed as a security thing; it is specifically made to resist a malicious user evading it.

The (probably inferior) alternative would involve creating a new user to run the console app. You would then restrict the data directories to that user, set the console app owned by that user, and set u+s on the program. This is the setuid bit; it means that someone who runs the console program does so with the permissions of the program's owner. That way, the user does not themselves have access to the directories, they only get it through the program. However, you should probably just use ForceCommand, as that restricts all access to "just run this program".

Answer 3

Do not attempt to do this with .profile because it provides no security whatsoever and restricts exactly nothing!

It doesn't matter what you put in .profile, since you can bypass it by simply giving a command to run on the ssh command line, like this: ssh user@host command. You can still get normal shell access by doing ssh -t user@host bash.

Disabling the sftp subsystem, like mentioned in another answer, doesn't help at all. Subsystems are essentially just aliases to commands, and you can still use sftp normally by doing sftp -s /path/to/sftp-executable user@host.

Like cpast and some commenters have said, you should use the proper mechanisms for restricting access. That is,

• Use ForceCommand in sshd_config
• Use passwordless login and command="..." in .ssh/authorized_keys
• Change the user's shell to something that restricts what the user can do

Notes:

• command="..." only applies for one key, so it doesn't restrict ssh login for the user using a password or another key
• You might also want to restrict port forwarding etc. (port forwarding, x11 forwarding, agent forwarding and pty allocation are the ones I've heard about)
  • AllowTcpForwarding etc. in sshd_config
  • no-port-forwarding etc. in .ssh/authorized_keys
• If you have other daemons (like FTP) running, you should verify that they don't let the user in (Some daemons make this decision based on the user's shell, so if you change that, you might want to re-check this)
• You can change the user's shell to a script that does what you want; it's either run without arguments or like script -c 'command-the-user-wanted-to-run'
• Both ForceCommand and command="..." run the command through the user's shell, so they don't work if the user's shell is set to eg. /bin/false or /sbin/nologin

Disclaimer: I'm no expert on the matter by any means, so while I can say that the .profile thing isn't safe, I can't promise there isn't some "gotcha" with the other methods that I don't know about. They're safe as far as I know, but I wouldn't be the first person to be wrong on the internet.

Answer 4

It is possible to enable SSH and disable SFTP both globally and per user/group.

I personally need this because I want to give access to some git repositories over SSH, and I like to disable systems that are not needed. In that case SFTP is not needed.

Globally

You can disable SFTP for all users in a couple of ways.

The missing subsystem

The SFTP daemon used by SSH can be configured through the Subsystem keyword. From the sshd_config(5) manual:

Subsystem Configures an external subsystem (e.g. file transfer daemon). Arguments should be a subsystem name and a command (with optional arguments) to execute upon subsystem request. The command sftp-server(8) implements the “sftp” file transfer subsystem. Alternately the name “internal-sftp” implements an in-process “sftp” server. This may simplify configurations using ChrootDirectory to force a different filesystem root on clients. By default no subsystems are defined. 

The last line suggests that it should be enough to not define any subsystem for "sftp".

A false lie

You could also disable SFTP by setting the SFTP daemon used by SSH to something unusable. For example, configure the "sftp" subsystem to /bin/false:

Subsystem sftp /bin/false 

When something would try to log in via SFTP, the SSH daemon would try to spawn the "sftp daemon" /bin/false. The /bin/false program does only one thing, and that is to return an error code. The SFTP connection attempt is effectively denied.

Per user/group

It is also possible to disable SFTP per user, group, or a couple of other criterias.

This does not work if you want your user to get a regular shell prompt. Nor does it make sense, as you could circumvent most stuff if you have shell access. It will only work if you only want to give access to a specific program.

Matching

To match a set of users, you could configure SSH with the Match keyword. From the sshd_config(5) manual:

Match ... The arguments to Match are one or more criteria-pattern pairs or the single token All which matches all criteria. The available criteria are User, Group, Host, LocalAddress, LocalPort, and Address. The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS section of ssh_config(5). ... 

A couple of examples:

• Match User eva matches the "eva" user
• Match User stephen,maria matches the "stephen" and "maria" users
• Match Group wheel,adams,simpsons matches the "wheel", "adams", "simpsons" groups

If you want more information, there are loads in the sshd_config(5) manual.

Forced command

Normally you get the user's login shell when you connect via SSH, but SSH can be configured to force a certain command. The command is forced for any SSH connection, including SFTP, and thus you might have the option to force the command you want.

The command to force can be configured with the ForceCommand keyword. From the sshd_config(5) manual:

ForceCommand Forces the execution of the command specified by ForceCommand, ignoring any command supplied by the client and ~/.ssh/rc if present. The command is invoked by using the user's login shell with the -c option. This applies to shell, command, or subsystem execution. It is most useful inside a Match block. The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment variable. Specifying a command of “internal-sftp” will force the use of an in-process sftp server that requires no support files when used with ChrootDirectory. The default is “none”. 

So you can force the constrained command you want using ForceCommand <your command>. For example:

Match User kim ForceCommand echo 'successful login man, congrats' 

Example

In my case where I want to give git access, I only need the user to have access to git-shell. This is the section that disables SFTP for my git users, along with some security options:

Match Group git # have to do this instead of setting the login shell to `git-shell`, # to disable SFTP ForceCommand /usr/bin/git-shell -c "$SSH_ORIGINAL_COMMAND" # disable stuff we don't need AllowAgentForwarding no AllowTcpForwarding no AllowStreamLocalForwarding no PermitOpen none PermitTunnel no PermitTTY no X11Forwarding no