Is it possible to grant users sftp access without shell access? If yes, how is it implemented?
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
add a comment |
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
add a comment |
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
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
sftp nologin
edited 12 hours ago
Sollosa
asked 12 hours ago
SollosaSollosa
4741718
4741718
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
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
allowsshgroup. - Users in the
sftponlygroup 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
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 yesto theMatch Group allowsshstanza. This will allow both pubkey and password auth forallowsshusers.
This configuration limits any
sftponlyuser to their home directory. If you do not want that, remove theChrootDirectory %hdirective.
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:rootand 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 /homemight be a good alternative.
Setting the shell of the
sftponlyusers to/sbin/nologinis neither necessary nor harmful for this solution, because SSH'sForceCommand internal-sftpoverrides the user's shell.
Using
/sbin/nologinmay be helpful to stop them logging in via other ways (physical console, samba, etc) though.
This setup does not allow direct
rootlogins over SSH; this forms an extra layer of security. If you really do need direct root logins, change thePermitRootLogindirective. Consider setting it toforced-commands-only,prohibit-password, and (as a last resort)yes.For bonus points, have a look at restricting who can
suto root; add a system group calledwheel, and add/enableauth required pam_wheel.soin/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
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 tochown root:rootandchmod og-w
– kubanczyk
3 hours ago
|
show 2 more comments
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
11 hours ago
1
@Sollosa Try withMatch User [SFTP user]ForceCommand internal-sftponly, without chrooting stuff.
– Martin Prikryl
11 hours ago
@MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola
– Sollosa
11 hours ago
add a comment |
just change their default shell to /sbin/nologin. Assuming most varieties of Linux:
# usermod -s /sbin/nologin username
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 alsoSubsystem sftp internal-sftp) (or maybeForceCommand internal-sftp). If there's commonSubsystem sftp /path/to/sftp-server,nologinwill prevent even SFTP.
– Martin Prikryl
11 hours ago
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
allowsshgroup. - Users in the
sftponlygroup 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
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 yesto theMatch Group allowsshstanza. This will allow both pubkey and password auth forallowsshusers.
This configuration limits any
sftponlyuser to their home directory. If you do not want that, remove theChrootDirectory %hdirective.
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:rootand 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 /homemight be a good alternative.
Setting the shell of the
sftponlyusers to/sbin/nologinis neither necessary nor harmful for this solution, because SSH'sForceCommand internal-sftpoverrides the user's shell.
Using
/sbin/nologinmay be helpful to stop them logging in via other ways (physical console, samba, etc) though.
This setup does not allow direct
rootlogins over SSH; this forms an extra layer of security. If you really do need direct root logins, change thePermitRootLogindirective. Consider setting it toforced-commands-only,prohibit-password, and (as a last resort)yes.For bonus points, have a look at restricting who can
suto root; add a system group calledwheel, and add/enableauth required pam_wheel.soin/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
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 tochown root:rootandchmod og-w
– kubanczyk
3 hours ago
|
show 2 more comments
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
allowsshgroup. - Users in the
sftponlygroup 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
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 yesto theMatch Group allowsshstanza. This will allow both pubkey and password auth forallowsshusers.
This configuration limits any
sftponlyuser to their home directory. If you do not want that, remove theChrootDirectory %hdirective.
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:rootand 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 /homemight be a good alternative.
Setting the shell of the
sftponlyusers to/sbin/nologinis neither necessary nor harmful for this solution, because SSH'sForceCommand internal-sftpoverrides the user's shell.
Using
/sbin/nologinmay be helpful to stop them logging in via other ways (physical console, samba, etc) though.
This setup does not allow direct
rootlogins over SSH; this forms an extra layer of security. If you really do need direct root logins, change thePermitRootLogindirective. Consider setting it toforced-commands-only,prohibit-password, and (as a last resort)yes.For bonus points, have a look at restricting who can
suto root; add a system group calledwheel, and add/enableauth required pam_wheel.soin/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
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 tochown root:rootandchmod og-w
– kubanczyk
3 hours ago
|
show 2 more comments
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
allowsshgroup. - Users in the
sftponlygroup 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
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 yesto theMatch Group allowsshstanza. This will allow both pubkey and password auth forallowsshusers.
This configuration limits any
sftponlyuser to their home directory. If you do not want that, remove theChrootDirectory %hdirective.
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:rootand 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 /homemight be a good alternative.
Setting the shell of the
sftponlyusers to/sbin/nologinis neither necessary nor harmful for this solution, because SSH'sForceCommand internal-sftpoverrides the user's shell.
Using
/sbin/nologinmay be helpful to stop them logging in via other ways (physical console, samba, etc) though.
This setup does not allow direct
rootlogins over SSH; this forms an extra layer of security. If you really do need direct root logins, change thePermitRootLogindirective. Consider setting it toforced-commands-only,prohibit-password, and (as a last resort)yes.For bonus points, have a look at restricting who can
suto root; add a system group calledwheel, and add/enableauth required pam_wheel.soin/etc/pam.d/su.
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
allowsshgroup. - Users in the
sftponlygroup 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
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 yesto theMatch Group allowsshstanza. This will allow both pubkey and password auth forallowsshusers.
This configuration limits any
sftponlyuser to their home directory. If you do not want that, remove theChrootDirectory %hdirective.
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:rootand 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 /homemight be a good alternative.
Setting the shell of the
sftponlyusers to/sbin/nologinis neither necessary nor harmful for this solution, because SSH'sForceCommand internal-sftpoverrides the user's shell.
Using
/sbin/nologinmay be helpful to stop them logging in via other ways (physical console, samba, etc) though.
This setup does not allow direct
rootlogins over SSH; this forms an extra layer of security. If you really do need direct root logins, change thePermitRootLogindirective. Consider setting it toforced-commands-only,prohibit-password, and (as a last resort)yes.For bonus points, have a look at restricting who can
suto root; add a system group calledwheel, and add/enableauth required pam_wheel.soin/etc/pam.d/su.
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 tochown root:rootandchmod og-w
– kubanczyk
3 hours ago
|
show 2 more comments
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 tochown root:rootandchmod 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
|
show 2 more comments
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
11 hours ago
1
@Sollosa Try withMatch User [SFTP user]ForceCommand internal-sftponly, without chrooting stuff.
– Martin Prikryl
11 hours ago
@MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola
– Sollosa
11 hours ago
add a comment |
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
11 hours ago
1
@Sollosa Try withMatch User [SFTP user]ForceCommand internal-sftponly, without chrooting stuff.
– Martin Prikryl
11 hours ago
@MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola
– Sollosa
11 hours ago
add a comment |
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.
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.
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 withMatch User [SFTP user]ForceCommand internal-sftponly, without chrooting stuff.
– Martin Prikryl
11 hours ago
@MartinPrikryl it worked Martin, thanks, I just removed chrootdirectory parameter & viola
– Sollosa
11 hours ago
add a comment |
Ok I did follow all steps but it did not log in
– Sollosa
11 hours ago
1
@Sollosa Try withMatch User [SFTP user]ForceCommand internal-sftponly, 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
add a comment |
just change their default shell to /sbin/nologin. Assuming most varieties of Linux:
# usermod -s /sbin/nologin username
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 alsoSubsystem sftp internal-sftp) (or maybeForceCommand internal-sftp). If there's commonSubsystem sftp /path/to/sftp-server,nologinwill prevent even SFTP.
– Martin Prikryl
11 hours ago
add a comment |
just change their default shell to /sbin/nologin. Assuming most varieties of Linux:
# usermod -s /sbin/nologin username
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 alsoSubsystem sftp internal-sftp) (or maybeForceCommand internal-sftp). If there's commonSubsystem sftp /path/to/sftp-server,nologinwill prevent even SFTP.
– Martin Prikryl
11 hours ago
add a comment |
just change their default shell to /sbin/nologin. Assuming most varieties of Linux:
# usermod -s /sbin/nologin username
just change their default shell to /sbin/nologin. Assuming most varieties of Linux:
# usermod -s /sbin/nologin username
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 alsoSubsystem sftp internal-sftp) (or maybeForceCommand internal-sftp). If there's commonSubsystem sftp /path/to/sftp-server,nologinwill prevent even SFTP.
– Martin Prikryl
11 hours ago
add a comment |
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 alsoSubsystem sftp internal-sftp) (or maybeForceCommand internal-sftp). If there's commonSubsystem sftp /path/to/sftp-server,nologinwill 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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