I'm starting a very little hosting company for a few friends and little clients, nothing big.
I want to give my "clients" the right to manage their files on the server. I hate FTP as it is not secure and it's in my opinion obsolete.
So I'd like to allow my users to connect through SFTP but not allow them to connect through SSH. (I know, I know, SFTP is using SSH). But I was just wondering, is it possible?
So I wouldn't have to install a FTP service on the server and everything would be awesome!
Starting with version 4.9 OpenSSH (not available in centos 5.x but ChrootDirectory feature was backported) has an internal-sftp subsystem:
Subsystem sftp internal-sftp
And then block other uses:
Match group sftponly
ChrootDirectory /upload
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
ForceCommand internal-sftp -d /%u
Add your users to the sftponly group. The chroot directory must be owned by root, and cannot be group-writeable, so create a subdirectory for each user that's owned by the appropriate user (if you match their home directory, it will be the default working directory when connecting). I'd also set /bin/false as the user's shell.
As an example, users can then upload single files with:
sftp username@hostname <<< 'put filename.ext /'
(scp will hopefully soon be modified to use sftp so this will become easier)
Checkout rssh which is a fake shell that allows sftp but denies ssh
More about RSSH
http://www.pizzashack.org/rssh/
RPMs
http://pkgs.repoforge.org/rssh/
You can configure rssh to allow / deny different behaviours like sft, scp etc.
The solution from Rob Wouters need only a minor change... as I could not comment for lack of points, I'll just reproduce here how it worked for me.
The directory you chroot to in sshd_config, really need to belong to root and not writable by any other user or group. So, if you put
ChrootDirectory /upload/%u
the user directory specified by '%u' must comply to the same rule. If you don't, you'll get "bad ownership or modes for chroot directory" error. Instead, you put only the base directory and pass the user owned and writable directory to the ForceComand. See below:
# override default of no subsystems
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
Match group sftponly
ChrootDirectory /upload
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
ForceCommand internal-sftp -d /%u
Now, when the user logs in, the internal-sftp will change de current directory to the right place.
I use the method of specifying the user shell as /bin/false as mentioned. However, you must ensure that /bin/shell is in /etc/shells. Then it works ssh=no ftp=ok.
I also use vsftpd and add this
chroot_local_user=YES
to
/etc/vsftpd/vsftpd.conf
so that ftp-ers can't see date other then their own.
Advantage to these simple changes are no annoying config to ssh config for each user.
Configuring ssh to enable only sftp for some selected users is a good idea and it works properly, provided that you you install either scponly or rssh.
rssh works fine, unless you need to configure jail, in this case try to follow instruction provided by CHROOT manuals is crazy, leading to "copy" large parts of system executables and library just below "each user jail", including rssh shell itself.
It is a space-wasting method.
scponly needs a deep understanding in configuration leading to ever-present problem of login rejection in case of jail setup.
The straightforward way to allow "ftp" functionalities with jail properly working, SSL/TLS support for secure transactions and login is to use an "old-but-working" VSFTPD, which installs quickly and cleanly and offers all configurability as needed and, last but not least: it works!
Maurizio.
Don't forget to find the line UsePAM yes and comment it:
#UsePAM yes
Without disabling this, your SSH server would crash on reloading/restarting. Since you do not need fancy functions of PAM, this is fine.
This is the way i set up SFTP and disallowing SSH.
please do the following:
First create sftp user and group sftp
Create separate directory as root for the SFTP files: sudo mkdir -p /home/sftpdir
Have a tested sshd_config file that allows SSH over port 22 but also SFTP on random port for security reasons
#$OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value.Port 38250 Port 22 PasswordAuthentication no ChallengeResponseAuthentication no
Set this to 'yes' to enable PAM authentication, account processing,
and session processing. If this is enabled, PAM authentication will
be allowed through the ChallengeResponseAuthentication and
PasswordAuthentication. Depending on your PAM configuration,
PAM authentication via ChallengeResponseAuthentication may bypass
the setting of "PermitRootLogin without-password".
If you just want the PAM account and session checks to run without
PAM authentication, then enable this but set PasswordAuthentication
and ChallengeResponseAuthentication to 'no'. UsePAM yes X11Forwarding yes PrintMotd no
Allow client to pass locale environment variables AcceptEnv LANG LC_*
#DenyUsers sftpuser
override default of no subsystems Subsystem sftp internal-sftp
Match group sftp Match User sftpuser Match LocalPort 38250 ForceCommand internal-sftp ChrootDirectory /home/sftpdir PermitTunnel no AllowAgentForwarding no X11Forwarding no
AllowTcpForwarding no
sudo service sshd restart
service sshd status
sudo touch /bin/sftponly
echo -e '#!/bin/sh\necho "This account is limited to SFTP access only."' | sudo tee -a /bin/sftponly
sudo chmod a+x /bin/sftponly
echo "/bin/sftponly" | sudo tee -a /etc/shells
finally Test and you should not be able to connect.
A template to use SFTP client with a SSH key and basic verbosity:
sftp -v -oPort=$RANDOM_PORT -i ~/.ssh/$SSH_KEY.pem sftpuser@$HOST
