여러 사용자가 있는 EC2 인스턴스가 작동하고 있는데 그 중 일부는 홈 디렉터리로 루트가 지정되어 있고 일부는 FTP 전용이고 셸 액세스 권한이 없습니다. 다른 사용자도 기본 관리자 계정이지만 ec2-user는 기본 관리자 계정입니다. 루트 액세스 및 전체 SSH 로그인. 실행 중인 인스턴스에서는 모든 것이 잘 작동합니다.
인스턴스의 스냅샷 이미지를 만들고 스냅샷에서 새 인스턴스를 시작할 수 있습니다. 새 인스턴스와 연결된 키 쌍 측면에서 무엇을 선택하더라도(ec2-user에 대한 원래 키 쌍 사용, 새 키 쌍 생성 또는 키 쌍 없음 사용) 새 인스턴스가 시작되어 실행되면 다음을 수행할 수 없습니다. ec2-user 또는 다른 SSH 지원 사용자를 사용하여 서버에 SSH로 연결합니다. 그러나 ftp는 잘 작동합니다.
내가 알 수 있는 한 보안 그룹은 문제가 되지 않습니다. 들어오는 트래픽은 허용됩니다(그리고 어쨌든 원래 인스턴스와 동일한 보안 그룹입니다).
로그인 시도의 /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를 사용하는 모든 사용자에게 동일한 오류가 발생합니다. 로그에서 볼 수 있듯이 /etc/ssh/keys 폴더에서 공개 키를 찾도록 원래 인스턴스의 sshd_config를 변경했습니다.
실패한 인스턴스를 작업 인스턴스의 볼륨으로 마운트했습니다. 키는 예상대로 동일한 권한과 동일한 키 값을 가진 폴더에 있습니다. 다음은 키 폴더(.)와 ec2-user 파일의 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
#...
답변1
나는 이것이 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
답변2
sshd_config에 'AllowUsers' 지시문이 설정되어 있습니까? 원래 서버의 특정 사용자로 설정되어 있고 ssh가 아직 다시 시작되지 않았으므로 여전히 모든 사용자를 허용합니까?
아, 방금 디버그에서 이것을 봤습니다: "사용자 ec2-user가 142행에서 그룹 목록 sftponly와 일치하지 않습니다." sshd_config를 확인하십시오. 그룹을 허용하지 않았거나 sftp만 허용했을 수 있습니까?