Is it possible to grant users sftp access without shell access? If yes, how is it implemented?












12















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.










share|improve this question





























    12















    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.










    share|improve this question



























      12












      12








      12


      8






      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.










      share|improve this question
















      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.







      sftp nologin






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 12 hours ago







      Sollosa

















      asked 12 hours ago









      SollosaSollosa

      4741718




      4741718






















          3 Answers
          3






          active

          oldest

          votes


















          17














          I like the following setup for managing SSH access, which I use at work to manage a group of users on small fleet 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
          X11Forwarding no
          AllowTcpForwarding no
          ForceCommand internal-sftp


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



          Explanation



          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 (these changes take effect immediately, no SSH restart required):



          # adduser marcelm allowssh
          # members allowssh
          marcelm
          # 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.




          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.







          share|improve this answer





















          • 2





            This should be the accepted answer. It provides the solution as well as breaking down the reasoning behind each step.

            – kemotep
            9 hours ago






          • 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?

            – Josh Rumbut
            6 hours ago






          • 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
            4 hours ago








          • 1





            Good answer, imo the biggest shortcomings of the other answers were not taking security aspects into account, mainly chroot. +1

            – Rui F Ribeiro
            4 hours ago








          • 1





            Chroot will not work for a generic %h. Surprisingly, you are required to chown root:root and chmod og-w

            – kubanczyk
            3 hours ago



















          7














          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.






          share|improve this answer


























          • Ok I did follow all steps but it did not log in

            – Sollosa
            11 hours ago






          • 1





            @Sollosa Try with Match User [SFTP user] ForceCommand internal-sftp only, without chrooting stuff.

            – Martin Prikryl
            11 hours ago











          • @MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola

            – Sollosa
            11 hours ago



















          1














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



          # usermod -s /sbin/nologin username





          share|improve this answer
























          • I have tried it, but user is not able to login via sftp, I don't know why. I'm using centos btw.

            – Sollosa
            12 hours ago











          • @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.

            – Mella
            12 hours ago













          • 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.

            – Martin Prikryl
            11 hours ago













          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f503312%2fis-it-possible-to-grant-users-sftp-access-without-shell-access-if-yes-how-is-i%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          3 Answers
          3






          active

          oldest

          votes








          3 Answers
          3






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          17














          I like the following setup for managing SSH access, which I use at work to manage a group of users on small fleet 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
          X11Forwarding no
          AllowTcpForwarding no
          ForceCommand internal-sftp


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



          Explanation



          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 (these changes take effect immediately, no SSH restart required):



          # adduser marcelm allowssh
          # members allowssh
          marcelm
          # 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.




          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.







          share|improve this answer





















          • 2





            This should be the accepted answer. It provides the solution as well as breaking down the reasoning behind each step.

            – kemotep
            9 hours ago






          • 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?

            – Josh Rumbut
            6 hours ago






          • 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
            4 hours ago








          • 1





            Good answer, imo the biggest shortcomings of the other answers were not taking security aspects into account, mainly chroot. +1

            – Rui F Ribeiro
            4 hours ago








          • 1





            Chroot will not work for a generic %h. Surprisingly, you are required to chown root:root and chmod og-w

            – kubanczyk
            3 hours ago
















          17














          I like the following setup for managing SSH access, which I use at work to manage a group of users on small fleet 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
          X11Forwarding no
          AllowTcpForwarding no
          ForceCommand internal-sftp


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



          Explanation



          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 (these changes take effect immediately, no SSH restart required):



          # adduser marcelm allowssh
          # members allowssh
          marcelm
          # 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.




          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.







          share|improve this answer





















          • 2





            This should be the accepted answer. It provides the solution as well as breaking down the reasoning behind each step.

            – kemotep
            9 hours ago






          • 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?

            – Josh Rumbut
            6 hours ago






          • 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
            4 hours ago








          • 1





            Good answer, imo the biggest shortcomings of the other answers were not taking security aspects into account, mainly chroot. +1

            – Rui F Ribeiro
            4 hours ago








          • 1





            Chroot will not work for a generic %h. Surprisingly, you are required to chown root:root and chmod og-w

            – kubanczyk
            3 hours ago














          17












          17








          17







          I like the following setup for managing SSH access, which I use at work to manage a group of users on small fleet 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
          X11Forwarding no
          AllowTcpForwarding no
          ForceCommand internal-sftp


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



          Explanation



          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 (these changes take effect immediately, no SSH restart required):



          # adduser marcelm allowssh
          # members allowssh
          marcelm
          # 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.




          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.







          share|improve this answer















          I like the following setup for managing SSH access, which I use at work to manage a group of users on small fleet 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
          X11Forwarding no
          AllowTcpForwarding no
          ForceCommand internal-sftp


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



          Explanation



          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 (these changes take effect immediately, no SSH restart required):



          # adduser marcelm allowssh
          # members allowssh
          marcelm
          # 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.




          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.








          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 2 hours ago

























          answered 10 hours ago









          marcelmmarcelm

          1,300411




          1,300411








          • 2





            This should be the accepted answer. It provides the solution as well as breaking down the reasoning behind each step.

            – kemotep
            9 hours ago






          • 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?

            – Josh Rumbut
            6 hours ago






          • 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
            4 hours ago








          • 1





            Good answer, imo the biggest shortcomings of the other answers were not taking security aspects into account, mainly chroot. +1

            – Rui F Ribeiro
            4 hours ago








          • 1





            Chroot will not work for a generic %h. Surprisingly, you are required to chown root:root and chmod og-w

            – kubanczyk
            3 hours ago














          • 2





            This should be the accepted answer. It provides the solution as well as breaking down the reasoning behind each step.

            – kemotep
            9 hours ago






          • 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?

            – Josh Rumbut
            6 hours ago






          • 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
            4 hours ago








          • 1





            Good answer, imo the biggest shortcomings of the other answers were not taking security aspects into account, mainly chroot. +1

            – Rui F Ribeiro
            4 hours ago








          • 1





            Chroot will not work for a generic %h. Surprisingly, you are required to chown root:root and chmod og-w

            – kubanczyk
            3 hours ago








          2




          2





          This should be the accepted answer. It provides the solution as well as breaking down the reasoning behind each step.

          – kemotep
          9 hours ago





          This should be the accepted answer. It provides the solution as well as breaking down the reasoning behind each step.

          – kemotep
          9 hours ago




          1




          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?

          – Josh Rumbut
          6 hours ago





          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?

          – Josh Rumbut
          6 hours ago




          1




          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
          4 hours ago







          @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
          4 hours ago






          1




          1





          Good answer, imo the biggest shortcomings of the other answers were not taking security aspects into account, mainly chroot. +1

          – Rui F Ribeiro
          4 hours ago







          Good answer, imo the biggest shortcomings of the other answers were not taking security aspects into account, mainly chroot. +1

          – Rui F Ribeiro
          4 hours ago






          1




          1





          Chroot will not work for a generic %h. Surprisingly, you are required to chown root:root and chmod og-w

          – kubanczyk
          3 hours ago





          Chroot will not work for a generic %h. Surprisingly, you are required to chown root:root and chmod og-w

          – kubanczyk
          3 hours ago













          7














          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.






          share|improve this answer


























          • Ok I did follow all steps but it did not log in

            – Sollosa
            11 hours ago






          • 1





            @Sollosa Try with Match User [SFTP user] ForceCommand internal-sftp only, without chrooting stuff.

            – Martin Prikryl
            11 hours ago











          • @MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola

            – Sollosa
            11 hours ago
















          7














          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.






          share|improve this answer


























          • Ok I did follow all steps but it did not log in

            – Sollosa
            11 hours ago






          • 1





            @Sollosa Try with Match User [SFTP user] ForceCommand internal-sftp only, without chrooting stuff.

            – Martin Prikryl
            11 hours ago











          • @MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola

            – Sollosa
            11 hours ago














          7












          7








          7







          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.






          share|improve this answer















          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 11 hours ago

























          answered 12 hours ago









          kemotepkemotep

          2,3943720




          2,3943720













          • Ok I did follow all steps but it did not log in

            – Sollosa
            11 hours ago






          • 1





            @Sollosa Try with Match User [SFTP user] ForceCommand internal-sftp only, without chrooting stuff.

            – Martin Prikryl
            11 hours ago











          • @MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola

            – Sollosa
            11 hours ago



















          • Ok I did follow all steps but it did not log in

            – Sollosa
            11 hours ago






          • 1





            @Sollosa Try with Match User [SFTP user] ForceCommand internal-sftp only, without chrooting stuff.

            – Martin Prikryl
            11 hours ago











          • @MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola

            – Sollosa
            11 hours ago

















          Ok I did follow all steps but it did not log in

          – Sollosa
          11 hours ago





          Ok I did follow all steps but it did not log in

          – Sollosa
          11 hours ago




          1




          1





          @Sollosa Try with Match User [SFTP user] ForceCommand internal-sftp only, without chrooting stuff.

          – Martin Prikryl
          11 hours ago





          @Sollosa Try with Match User [SFTP user] ForceCommand internal-sftp only, without chrooting stuff.

          – Martin Prikryl
          11 hours ago













          @MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola

          – Sollosa
          11 hours ago





          @MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola

          – Sollosa
          11 hours ago











          1














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



          # usermod -s /sbin/nologin username





          share|improve this answer
























          • I have tried it, but user is not able to login via sftp, I don't know why. I'm using centos btw.

            – Sollosa
            12 hours ago











          • @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.

            – Mella
            12 hours ago













          • 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.

            – Martin Prikryl
            11 hours ago


















          1














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



          # usermod -s /sbin/nologin username





          share|improve this answer
























          • I have tried it, but user is not able to login via sftp, I don't know why. I'm using centos btw.

            – Sollosa
            12 hours ago











          • @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.

            – Mella
            12 hours ago













          • 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.

            – Martin Prikryl
            11 hours ago
















          1












          1








          1







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



          # usermod -s /sbin/nologin username





          share|improve this answer













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



          # usermod -s /sbin/nologin username






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 12 hours ago









          MellaMella

          233111




          233111













          • I have tried it, but user is not able to login via sftp, I don't know why. I'm using centos btw.

            – Sollosa
            12 hours ago











          • @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.

            – Mella
            12 hours ago













          • 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.

            – Martin Prikryl
            11 hours ago





















          • I have tried it, but user is not able to login via sftp, I don't know why. I'm using centos btw.

            – Sollosa
            12 hours ago











          • @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.

            – Mella
            12 hours ago













          • 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.

            – Martin Prikryl
            11 hours ago



















          I have tried it, but user is not able to login via sftp, I don't know why. I'm using centos btw.

          – Sollosa
          12 hours ago





          I have tried it, but user is not able to login via sftp, I don't know why. I'm using centos btw.

          – Sollosa
          12 hours ago













          @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.

          – Mella
          12 hours ago







          @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.

          – Mella
          12 hours ago















          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.

          – Martin Prikryl
          11 hours ago







          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.

          – Martin Prikryl
          11 hours ago




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f503312%2fis-it-possible-to-grant-users-sftp-access-without-shell-access-if-yes-how-is-i%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Paul Cézanne

          UIScrollView CustomStickyHeader Resize height generates problems when scroll is too fast

          Angular material date-picker (MatDatepicker) auto completes the date on focus out