I have an array of users who need to just upload files to their set homedirs. I think sftp would suffice, but I don't want them to login via shell. So is it possible? My platform is centos 7, user's homedirs are stored lets say /personal/$user

I created user with these settings

useradd -m -d /personal/user1 -s /sbin/nologin

assigned user a passwd, then when I use sftp to login to the machine, it says cannot connect.


4 Answers 4


I like the following setup for managing SSH access, which I've used to manage a group of users on small fleets of servers. Security and ease of management is high on the list of my priorities.

Its key features are easily managing SSH rights through Unix group membership, having tightly defined permissions, and being secure by default.

Setting up

Install software (optional but useful):

yum install members   # or apt install members

Add groups:

addgroup --system allowssh
addgroup --system sftponly

In /etc/ssh/sshd_config, ensure that the following to settings are No:

PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no

And at the end of /etc/ssh/sshd_config, add these two stanzas:

Match Group allowssh
    PubkeyAuthentication yes

Match Group sftponly
    ChrootDirectory %h
    DisableForwarding yes
    ForceCommand internal-sftp

(don't forget to restart SSH after editing the file)


So, what does all this do?

  • It always disables root logins, as an extra security measure.
  • It always disables password-based logins (weak passwords are a big risk for servers running sshd).
  • It only allows (pubkey) login for users in the allowssh group.
  • Users in the sftponly group cannot get a shell over SSH, only SFTP.

Managing who has access is then simply done by managing group membership (group membership changes take effect immediately, no SSH restart required; but note that existing sessions are not affected). members allowssh will show all users that are allowed to log in over SSH, and members sftponly will show all users that are limited to SFTP.

# adduser marcelm allowssh
# members allowssh
# deluser marcelm allowssh
# members allowssh

Note that your sftp users need to be members of both sftponly (to ensure they won't get a shell), and of allowssh (to allow login in the first place).

Further information

  1. Please note that this configuration does not allow password logins; all accounts need to use public key authentication. This is probably the single biggest security win you can get with SSH, so I argue it's worth the effort even if you have to start now.

    If you really don't want this, then also add PasswordAuthentication yes to the Match Group allowssh stanza. This will allow both pubkey and password auth for allowssh users. Alternatively, you can add another group (and Match Group stanza) to selectively grant users password-based logins.

  2. This configuration limits any sftponly user to their home directory. If you do not want that, remove the ChrootDirectory %h directive.

    If you do want the chrooting to work, it's important that the user's home directory (and any directory above it) is owned by root:root and not writable by group/other. It's OK for subdirectories of the home directory to be user-owned and/or writable.

    Yes, the user's home directory must be root-owned and unwritable to the user. Sadly, there are good reasons for this limitation. Depending on your situation, ChrootDirectory /home might be a good alternative.

  3. Setting the shell of the sftponly users to /sbin/nologin is neither necessary nor harmful for this solution, because SSH's ForceCommand internal-sftp overrides the user's shell.

    Using /sbin/nologin may be helpful to stop them logging in via other ways (physical console, samba, etc) though.

  4. This setup does not allow direct root logins over SSH; this forms an extra layer of security. If you really do need direct root logins, change the PermitRootLogin directive. Consider setting it to forced-commands-only, prohibit-password, and (as a last resort) yes.

  5. For bonus points, have a look at restricting who can su to root; add a system group called wheel, and add/enable auth required pam_wheel.so in /etc/pam.d/su.

  • 2
    This should be the accepted answer. It provides the solution as well as breaking down the reasoning behind each step.
    – kemotep
    Feb 27, 2019 at 14:40
  • 1
    This is a really great answer with great additional security advice but I do worry for those users whose systems are relying on password logins, root logins, etc. Of course doing so is not good but maybe move the changes related to general security improvement to their own section so that an answer to the question with minimal changes is available? Feb 27, 2019 at 17:27
  • 1
    @JoshRumbut I didn't want to rewrite the answer for your (very correct) remarks, partly because it's really just showing My Way™, and partly in the hopes that it can be a sort-of canonical secure-by-default SSH setup example that many more people find useful. As a compromise, I tried to make it a lot clearer that root logins and password auth won't work, and I included instructions how to re-enable them :)
    – marcelm
    Feb 27, 2019 at 19:32
  • 1
    Good answer, imo the biggest shortcomings of the other answers were not taking security aspects into account, mainly chroot. +1 Feb 27, 2019 at 19:34
  • 1
    Chroot will not work for a generic %h. Surprisingly, you are required to chown root:root and chmod og-w
    – kubanczyk
    Feb 27, 2019 at 20:46

Edit your /etc/ssh/sshd_config to contain:

Match User [SFTP user]
ForceCommand internal-sftp

Restart sshd. If you have multiple users put them all on the match user line separated by commas like so:

Match User User1,User2,User3

The key to configuring sftp to not allow shell access is to limit users via the ForceCommand option.

  • Ok I did follow all steps but it did not log in
    – Sollosa
    Feb 27, 2019 at 12:34
  • 2
    @Sollosa Try with Match User [SFTP user] ForceCommand internal-sftp only, without chrooting stuff. Feb 27, 2019 at 12:36
  • @MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola
    – Sollosa
    Feb 27, 2019 at 12:42
  • 1
    On top of that, you can chroot the users so they can't navigate up and out of your defined "jail"
    – ivanivan
    Feb 28, 2019 at 18:31

just change their default shell to /sbin/nologin. Assuming most varieties of Linux:

# usermod -s /sbin/nologin username
  • 1
    I have tried it, but user is not able to login via sftp, I don't know why. I'm using centos btw.
    – Sollosa
    Feb 27, 2019 at 11:45
  • @Sollosa Probably either a permission problem in your sftp chroot, or sshd_config has a problem. You should update your question to include the permissions of your chroot directory, and your sshd_config with any sensitive information redacted.
    – Kefka
    Feb 27, 2019 at 11:49
  • I believe (though I cannot test it now) that this allows SFTP only if there's also Subsystem sftp internal-sftp) (or maybe ForceCommand internal-sftp). If there's common Subsystem sftp /path/to/sftp-server, nologin will prevent even SFTP. Feb 27, 2019 at 12:21
  • @MartinPrikryl I misunderstood their original unedited question to be asking how to disable shell access for users on an otherwise functional sftp server. I'd been awake for about ten minutes at the time so I wasn't as clearheaded as I might have felt. Though I didn't know that sftp-server requires a user to have a valid shell to work - that seems potentially dangerous. I only ever use internal-sftp just out of habit because that's how I've always done it.
    – Kefka
    Mar 4, 2019 at 13:45
  • See my answer to OpenSSH: Difference between internal-sftp and sftp-server (particularly the section at the end) Mar 4, 2019 at 13:48

you can use tftp. anything over ssh will require a some auth (key|pass).

while tftp can be secured, it may be worth revisiting the decision to provide access to anything without authentication.


  • 2
    I think OP wanted users (who presumably have usernames and passwords) to not be able to use a regular SSH client to connect to the server and execute arbitrary commands, but those same users be able to upload files via SFTP. Feb 28, 2019 at 6:41
  • tftp also has significant issues from a security standpoint. It might be tolerable on a locked-down, well-monitored network but I would not recommend using it for any situation where there's a secure alternative. Jan 13, 2021 at 0:33

You must log in to answer this question.

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