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

评论

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

#1 楼

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将用户保留在自己的房屋中,但这是另一回事了。)

评论


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

–沃伦
09年11月12日下午4:44

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

– wzzrd
09年11月12日7:48

scponly也差不多是同一件事,而且显然不容易受到攻击:sublimation.org/scponly/wiki/index.php/Main_Page

–FrançoisFeugeas
09年11月12日上午10:52

似乎已经搬到了github。升华链接已死。 github.com/scponly/scponly/wiki

– spazm
2013年9月13日22:04

这个答案应该删除!它确实是过时的,并且可能使人们感到困惑-很多年前,rssh和类似的工具已经死了,并从所有OS存储库中删除了。 rssh具有未修补的漏洞,已有很多年了。

–ruruskyi
20 Nov 19在13:26



#2 楼

我已经很晚了,但是您可以使用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


该命令的作用:


它显示详细信息(可选:您可以删除从命令和authorized_keys文件中获取-v
它以递归方式复制路径/到/数据的内容。 (可选:如果不想创建递归副本,则可以从命令和authorized_keys文件中删除-r
它使用端口2222连接到服务器(可选:可以从命令中删除-P 2222
它使用身份文件自动进行连接(可选:您可以删除-i .ssh/id_rsa_key_file

path/to/data的内容将被复制到/path/to/directory/with/accessible/content/


将文件(或多个文件)从服务器复制到客户端,则应创建一个shell脚本来处理此问题,如此处所述

评论


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

–丹
15-10-14在12:11



@Dan-应该可以在authorized_keys文件上设置只读权限,即。 chmod 400〜/ .ssh / authorized_keys。

–罗杰·迪克(Roger Dueck)
16-10-6在15:30

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

–点
17年12月6日15:23



#3 楼

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

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp


允许的,这是SFTP而不是SCP ,但与受限制的外壳相比,它可以更安全地达到相同的目标。此外,如果需要,您可以更改用户的根目录。

评论


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

– higuita
13年5月28日在15:44



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

–马辛
2014年6月6日12:58



有关详细说明,请访问debian-administration.org/article/590/…。

– koppor
2015年11月15日在18:56

#4 楼

我使用MySecureShell来做到这一点。您也可以配置其他限制。

https://github.com/mysecureshell/mysecureshell

仅限制与SFTP / SCP的连接。无法访问外壳。

评论


我很惊讶!外壳完全符合我的要求!

– Regis May
20 Dec 11'在14:25

#5 楼

我建议使用scponly。

这是一个受限制的外壳,允许用户将听起来像是SCP文件发送到服务器,但实际上并未登录。有关软件的信息和源代码下载,请参见此处和预可以通过EPEL YUM存储库获得经过编译的RPM软件包。

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

评论


我第二。正是为此目的而专门设计的。

–犹他州黑德
2013年9月25日12:16在

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

– koppor
2015年11月15日18:49



#6 楼

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

#7 楼

我们在安全的ftp服务器上为我们只希望能够对文件进行scp但不能登录的用户使用了一个名为scponly的伪外壳。

#8 楼

我发现一种不错的方法是使用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文件,但是我的目的是拥有一个无密码的密钥我可以用于备份,而不必创建一个新用户,并且密钥不提供外壳程序(好,很容易)

评论


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

– davidgo
2015年10月12日在21:25

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

–菲尔
17年4月25日在1:18

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

–点
17年6月6日在15:27

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

–菲尔
17年7月7日在3:05

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

–点
17 Dec 7'在13:12



#9 楼

将用户的登录Shell更改为限制性的内容,这使用户只能运行scp,sftp-server和rsync,并且还检查是否允许使用不安全的参数(例如scp -S ...和rsync -e ..是不安全的,请参见此处:http://exploit-db.com/exploits/24795)。此类限制性登录shell的示例:


rssh

scponly(不仅如此,如果配置,还允许sftp,svn等)
transfer_shell

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

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

#10 楼

它不是最合适的解决方案,但是您可以向用户扔这样的东西。bashrc

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


我发现SCP用户获得了“哑巴”这个术语,而其他人通常会得到vt100。

我想用户可能会选择一个新的.bashrc,这不是最好的解决方案,但是对于快速又肮脏的解决方案,这将起作用

评论


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

–点
2017年12月6日15:29



嗯... ssh -o SetEnv TERM =笨笨的您的服务器bash?

– ulidtko
19年7月2日在18:45