我有一个function强大的EC2实例与几个用户,其中一些被chrooted到他们的主目录,其中一些是只有ftp和没有shell访问,等等… ec2用户是主要的pipe理员帐户,虽然其他人也有根访问和完整的sshlogin。 在运行的实例中一切正常。
我可以拍摄实例的快照图像,并从快照中启动新的实例。 无论我按照与新实例关联的密钥对(使用ec2用户的原始密钥对,创build新密钥对还是使用无密钥对)来select,一旦新实例启动并运行,我无法ssh到服务器使用ec2用户或任何其他SSH启用用户。 但是,FTP工作正常。
就我所知,安全组不是问题,就我所知,允许传入的通信(反正它和原始实例是同一个安全组)。
login尝试的/ var / log / secure给我:
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method none sshd[1739]: debug1: attempt 0 failures 0 sshd[1738]: debug1: user ec2-user does not match group list sftponly at line 142 sshd[1738]: debug1: PAM: initializing for "ec2-user" sshd[1738]: debug1: PAM: setting PAM_RHOST to "..." sshd[1738]: debug1: PAM: setting PAM_TTY to "ssh" sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method publickey sshd[1739]: debug1: attempt 1 failures 0 sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0) sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user sshd[1738]: debug1: restore_uid: 0/0 sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0) sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user sshd[1738]: debug1: restore_uid: 0/0 sshd[1738]: Failed publickey for ec2-user from xx.xx.xx.xx port 60597 ssh2 sshd[1739]: Connection closed by xx.xx.xx.xx sshd[1739]: debug1: do_cleanup
这对于所有启用了ssh的用户来说都是一样的错误。 从日志中可以看到,我在原始实例上更改了sshd_config,以便在/ etc / ssh / keys文件夹中查找公钥。
我在工作实例上将失败的实例挂载为卷。 密钥位于文件夹中,具有相同的权限和相同的键值,全部按预期方式。 这里是密钥文件夹(。)和ec2用户文件的ls -al。
drwxr-xr-x. 2 root root 4096 Dec 1 16:59 . -rw-------. 1 ec2-user ec2-user 388 Jul 25 13:27 ec2-user
什么可能导致这个问题? 我想在保存和启动快照或者设置原始实例的时候解决这个问题,但是不能安装有问题的实例,并且做一些手动的修改,以便它能正常工作,但是不能解决更大的问题。
更新:这是sshd_config文件中的活动设置:
#... Protocol 2 #... SyslogFacility AUTHPRIV LogLevel DEBUG #... AuthorizedKeysFile /etc/ssh/keys/%u #... PasswordAuthentication no #... ChallengeResponseAuthentication no #... GSSAPIAuthentication yes #... GSSAPICleanupCredentials yes #... UsePAM yes #... AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS #... X11Forwarding yes #... Subsystem sftp internal-sftp -f AUTH -l VERBOSE #... Match group sftponly ChrootDirectory /home/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -l VERBOSE -f AUTH #...
我怀疑这是一个SELinux问题。 检查您正在使用的文件夹的上下文,我认为它不会是正确的持有钥匙。
我害怕我再也不能访问Redhat框来确定上下文应该是什么了。 这就是说,试试这个:
ls -lZ /root/.ssh
这将产生您的新文件夹所需的selinux上下文。 如果我没有记错,应该是像system_u:system_r:sshd_t
然后,我们需要将该安全上下文应用于新的授权密钥位置:
semanage fcontext -a -t system_u:system_r:sshd_t “/etc/ssh/keys(/.*)?”
哪个关联正确的上下文与新的键位置。 最后,我们可以将上下文应用到新位置
restorecon -Rv /etc/ssh/keys
是否在sshd_config中设置了“AllowUsers”指令? 也许它设置为原来的服务器上的特定用户和SSH尚未重新启动,所以它仍然接受所有用户?
哦,我刚刚在debugging中看到这一点:“用户ec2用户不匹配组列表sftponly在第142行”检查sshd_config你可能已经不允许一个组,或只允许sftp?