允许SFTP但不允许SSH?


94

我正在为一些朋友和小客户建立一个很小的托管公司,没什么大不了的。

我想赋予我的“客户”管理服务器上文件的权利。我讨厌FTP,因为它不安全,而且我认为它已经过时了。

因此,我想允许我的用户通过SFTP连接,但不允许他们通过SSH连接。(我知道,我知道SFTP正在使用SSH)。但是我只是想知道,有可能吗?

因此,我不必在服务器上安装FTP服务,一切都会变得很棒!

Answers:


121

从版本4.9开始,OpenSSH(在centos 5.x中不可用,但ChrootDirectory功能已向后移植)具有一个internal-sftp子系统:

Subsystem sftp internal-sftp

然后阻止其他用途:

Match group sftponly
     ChrootDirectory /home/%u
     X11Forwarding no
     AllowTcpForwarding no
     ForceCommand internal-sftp

将您的用户添加到该sftponly组。/由于chroot,您必须将用户的主目录更改为,并且/home/user应归root。我还将设置/bin/false为用户的外壳。


哇!太棒了!我将对此进行测试,然后返回此处进行验证。非常感谢!
Tommy B.

为ChrootDirectory事物+1!
凯尔·霍奇森

1
完成此操作后,我的sftponly用户无法通过ssh访问,并且能够通过sftp连接。但是,它根本看不到任何文件!尽管这些文件对此用户具有权限。:-(
EmilioNicolás2015年

3
如果您要执行此操作,并在sshd_config中找到已经存在“ / usr / lib / openssh / sftp-server”的条目,请在此处检查:serverfault.com/questions/660160/…-internal-sftp 是“较新的” ,更好,更轻松”
Xosofox

19

有一个外壳可以轻松地执行此操作。它也可以chroot


如果您同时需要SFTP用户和SSH用户,这将非常有用。您只需将/ etc / passwd中的shell替换为仅限于SFTP的shell。
Dragos


2

您可以修改/ etc / passwd并为该用户提供一个伪造的外壳,以使他不能使用ssh。


11
你测试了吗?
splattne 2012年

8
当我尝试将Shell设置为/bin/falsessh sftp 都不起作用时
Brad Mace

2
/ bin / false禁止任何形式的登录,这不是正确的方法。Rob Wouters的公认答案是如何限制用户仅使用SFTP,而不是更改外壳。如果您确实想更改外壳,则@Stone的连接将是一个好主意。
jwbensley 2014年

1
因此,假设不接受/ bin / bash且/ bin / false或/ sbin / nologin拒绝访问,应使用哪种外壳?
Putnik

1

如上所述,我使用将用户外壳指定为/ bin / false的方法。但是,必须确保/ bin / shell在/ etc / shells中。然后它可以工作ssh = no ftp = ok。

我还使用vsftpd并将此
chroot_local_user = YES 添加到/etc/vsftpd/vsftpd.conf中,以便ftp-ers除了看到自己的日期以外,看不到其他日期。

这些简单更改的优势在于,每个用户的ssh配置不会烦人。


1

不要忘记找到这一行UsePAM yes并对其进行评论:

#UsePAM yes

如果不禁用此功能,您的SSH服务器将在重新加载/重新启动时崩溃。由于您不需要花哨的PAM功能,所以很好。


0

将ssh配置为仅对某些选定用户启用sftp是一个好主意,并且只要您安装scponly或,它就可以正常工作rssh

rssh除非您需要配置监狱,否则工作正常,在这种情况下,尝试遵循CHROOT手册提供的说明是疯狂的,导致“复制”系统可执行文件和库的大部分位于“每个用户监狱”下面,包括rssh外壳本身。这是一种浪费空间的方法。

scponly 需要对配置有深入的了解,从而导致在监狱建立时出现拒绝登录的问题。

允许“ ftp”功能在监狱中正常工作的简单方法,对安全交易和登录的SSL / TLS支持是使用“老旧但可正常工作的” VSFTPD,它可以快速干净地安装并根据需要提供所有可配置性,最后但并非最不重要:它有效!

毛里齐奥。


0

不幸的是,所有答案都极具误导性:请执行以下操作:

  1. 首先创建sftp用户和组sftp

  2. 创建单独的目录作为SFTP文件的根目录: sudo mkdir -p /home/sftpdir

  3. 具有经过测试的sshd_config文件,出于安全原因,该文件允许通过端口22进行SSH,但也可以在随机端口上进行SFTP
#$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
  1. 重新启动并检查sshd服务的状态

    sudo服务sshd重新启动

    服务sshd状态

  2. 创建一个Shell文件。添加执行以回显通知消息

    sudo touch / bin / sftponly echo -e'#!/ bin / sh \ necho“此帐户仅限于SFTP访问。sudo tee -a / bin / sftponly

  3. 授予执行权限并追加到Shell文件

    sudo chmod a + x / bin / sftponly回声“ / bin / sftponly” | sudo tee -a / etc / shells

  4. 最终测试,您应该无法连接。

  5. 将SFTP客户端与SSH密钥和基本详细信息一起使用的模板:

    sftp -v -oPort = $ RANDOM_PORT -i〜/ .ssh / $ SSH_KEY.pem sftpuser @ $ HOST

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.