允许SCP但不允许使用SSH实际登录


62

有什么方法可以在Linux机器上配置用户(在本例中为Centos 5.2),以便他们可以使用scp来检索文件,但实际上不能使用SSH登录服务器。


我尝试将登录shell设置为/ bin / false,但这只是完全停止了scp的工作。
DrStalker

Answers:


44

rssh shell(http://pizzashack.org/rssh/)正是为此目的而设计的。

由于RHEL / CentOS 5.2不包含rssh软件包,因此您可以在此处获取RPM:http : //dag.wieers.com/rpm/packages/rssh/

要使用它,只需将它设置为新用户的外壳,如下所示:

useradd -m -d /home/scpuser1 -s /usr/bin/rssh scpuser1
passwd scpuser1

..或更改现有外壳的外壳,如下所示:

chsh -s /usr/bin/rssh scpuser1

..并进行编辑/etc/rssh.conf以配置rssh shell-尤其是取消注释allowscp行,以启用所有rssh用户的SCP访问权限。

(您可能还希望使用chroot将用户保留在自己的房屋中,但这是另一回事了。)


太棒了-我也一直在寻找类似的东西
沃伦

6
rssh背后的想法很好,但是iirc rssh并不是编程术语上的安全奇迹。一个简单的关于“ rssh exploit”的google产生的结果比我不满意的要多...
wzzrd

7
scponly或多或少同样的事情也显然少攻击倾向:sublimation.org/scponly/wiki/index.php/Main_Page
弗朗索瓦Feugeas

似乎已移至github。升华链接已死。github.com/scponly/scponly/wiki
spazm 2013年

38

我迟到了,但是您可以使用ssh键并在其〜/ .ssh / authorized_keys文件中指定允许的确切命令,例如

no-port-forwarding,no-pty,command =“ scp source target” ssh-dss ...

您可能需要在目标上使用ps来设置正确的命令设置。

PS:如果使用“ -v”运行测试scp命令,您会看到类似以下的内容

debug1: Sending command: scp -v -t myfile.txt

您会注意到,“-t”是一个未记录的scp选项,由程序在远端使用。这使您可以了解需要放入authorized_keys中的内容。

编辑: 您可以在此StackOverflow问题中找到更多信息(带有几个链接)。

对于backup_user在服务器端命名的用户,这是一个有效的示例。

~backup_user/.ssh/authorized_keys 服务器端的内容(具有更多的安全性限制):

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...

在〜backup_user /中创建一个链接,该链接链接到应可访问内容的目录。

$ ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT

现在,从客户端开始,以下命令应该起作用:

scp -v  -r  -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT

该命令的作用:

  • 它显示详细信息(可选:您可以-v从命令和authorized_keys文件中删除该文件)
  • 它以递归方式复制路径/到/数据的内容。(optionnal-r如果您不想进行递归副本,则可以从command和authorized_keys文件中删除)
  • 它使用端口2222连接到服务器(可选:您可以-P 2222从命令中删除)
  • 它使用和身份文件自动执行连接(可选:您可以删除-i .ssh/id_rsa_key_file
  • 的内容path/to/data将复制到/path/to/directory/with/accessible/content/

为了使从服务器到客户端文件(或几个)的副本,你应该建立一个处理这个shell脚本如这里所描述


1
什么可以阻止用户浏览他们的authorized_keys文件?可以限制它不归用户所有吗?

1
@Dan-应该可以在authorized_keys文件上设置只读权限,即。chmod 400 ~/.ssh/authorized_keys
罗杰·杜克

另外,您还应将其~/.bashrc(以及Bash执行的其他任何操作)设为~/.ssh/rc只读。但是,即使恶意用户可以访问rsync或sftp,他仍然可以删除~/.bashrc并上传一个新的。由于很难保护,因此建议您不要使用此方法(command="...")。
pts

31

我参加聚会有点晚,但是我建议您看一下ForceCommandOpenSSH 的指令。

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

当然,这是SFTP而不是SCP,但与受限制的Shell相比,它可以更安全地达到相同的目标。另外,您可以根据需要更改用户的根目录。


2
在match部分之后添加chrootDirectory %hAllowTcpForwarding no,以强制sftponly用户将chroot迁移到其家中。请注意,匹配项(必须!)是ssh配置的最后一部分,之后的选项仅适用于匹配的用户
higuita 2013年

4
ForceCommand internal-sftp -u 0077 -d /uploaddir通过在上传目录上强制使用umask,可以进一步加强它。结合“ ChrootDirectory”,它创建了一个受控制的,隔离的上传环境。注意:如果要使用默认目录和umask,则必须在中设置,而ForceCommand不是在Subsystem伪指令中设置。
Marcin 2014年


7

我建议使用scponly。

这是一个受限制的外壳,允许用户执行听起来像是将SCP文件发送到服务器的操作,但实际上无法登录。可在此处获得该软件的信息和源代码下载,并且可以通过以下途径获得预编译的RPM软件包:EPEL YUM存储库

安装后,您需要配置要限制访问权限的每个用户帐户,以使用新安装的受限外壳程序。您可以通过/ etc / passwd手动执行此操作,或使用以下命令: usermod -s /usr/bin/scponly USERNAME


我第二。 scponly专为此目的而设计。
犹他州Jarhead

1
似乎已经死了。debian似乎已将其删除:packages.debian.org/search?keywords = scponlygithub上代码也已消失。后续讨论:serverfault.com/questions/726519/…–
koppor


3

参加聚会很晚,但是只需将git用户的shell设置为/ usr / bin / git-shell。这是一个受限制的外壳,不允许交互式登录。您仍然可以使用'su -s / bin / bash git'或其他git用户名来吸引用户。


2

对于仅希望能够scp文件但不希望登录的用户,我们在安全的ftp服务器上使用了名为scponly的psudo shell 。


2

我发现一种不错的方法是使用authorized_keys文件的command =“ ...”功能。(此页面建议我)

您将运行的命令将测试以scp(和rsync)开头的参数。

这是authorized_keys文件:

# authorized_keys
command="/usr/local/bin/remote-cmd.sh" ssh-rsa.....== user@pewpew

这是remote-cmd.sh的内容:

#!/bin/bash
# /usr/local/bin/remote-cmd.sh
case $SSH_ORIGINAL_COMMAND in
 'scp'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 'rsync'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 *)
    echo "Access Denied"
    ;;
esac

我想您可能仍需要保护用户的authorized_keys文件,但我的目的是拥有一个无需密码即可用于备份的密钥,而无需创建一个新用户,并且密钥不提供外壳程序(好,轻松)


3
这非常酷-但我想可以通过发出执行scp的命令来破坏它,然后再运行脚本!
davidgo

@davidgo在$ SSH_ORIGINAL_COMMAND前面加上exec可能会解决该漏洞,假设scp和rsync本身不会尝试运行多个程序(在这种情况下,这会破坏该漏洞)
Phil

你也应该做~/.ssh/authorized_keys~/.bashrc(和任何其他的Bash执行)和~/.ssh/rc只读用户。但是,即使恶意用户可以访问rsync或sftp,他仍然可以删除~/.bashrc并上传一个新的。由于很难保护,因此建议您不要使用此方法(command="...")。
pts

1
@pts可以使rc文件以及包含它们的目录都由用户以外的其他人拥有(没人吗?),并且用户不可写。但是,此时最好使用诸如rssh之类的专用工具。哇,我才意识到这就是我的答案!老了!哈哈!
菲尔(Phil)

不要忘记scp -S ...rsync -e ...允许用户执行任意命令。因此,在执行之前,应检查$ SSH_ORIGINAL_COMMAND中的参数。此处的更多信息:exploit-db.com/exploits/24795
pts

1

将用户的登录Shell更改为限制性的名称,使用户只能运行scpsftp-serverrsync,并且还检查是否允许使用不安全的参数(例如scp -S ...rsync -e .. 。是不安全的,在这里看到:http://exploit-db.com/exploits/24795)。此类限制性登录shell的示例:

您可能想要在chroot或另一个受限制的环境(例如Linux中的nsjail)中运行其中之一,以禁用网络访问并更容易(将其列入白名单)控制可以读取和/或写入的目录。

我不建议使用command="..."~/.ssh/authorized_keys,因为没有仔细额外的保护(如chmod -R u-w ~用户),恶意用户可以上传新版本~/.ssh/authorized_keys~/.ssh/rc或者~/.bashrc,因此可以包括和执行任意命令。


0

它不是最优雅的解决方案,但是您可以向用户.bashrc中添加类似的内容

if [ "$TERM"  != "dumb" ]; then
  exit
fi

我发现SCP用户的术语为“哑”,而其他用户通常会获得vt100。

我想用户可能会在新的.bashrc上打听,这使它不是最佳解决方案,但是对于一个快速而肮脏的解决方案,它将起作用


1
我强烈建议您反对这种建议的解决方案,因为恶意用户很容易规避(例如,通过上传另一个~/.bashrc)。从某种意义上说,这也很TERM不稳定,也许新版本的OpenSSH会以不同的方式设置变量,或者某些sshd配置设置可能会影响TERM
pts

1
Ehhh ... ssh -o SetEnv TERM=dumb yourserver bash
ulidtko
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.