#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 楼
它不是最合适的解决方案,但是您可以向用户扔这样的东西。bashrcif [ "$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
评论
我尝试将登录shell设置为/ bin / false,但这只会完全停止scp的工作。