EC2 Linux 서버(공개 키)에서 SSH 권한이 거부되었습니다.

2024-11-1 • tag-icon

linux ssh rhel aws amazon-ec2

EC2 Linux 서버(공개 키)에서 SSH 권한이 거부되었습니다.

마스터에서 슬레이브로 SSH를 시도할 때 2개의 Ubuntu Linux EC2 인스턴스(마스터 및 슬레이브)를 생성했지만 "권한 거부됨(공개 키)" 오류가 발생합니다.

서버 세부정보

ubuntu@ip-172-31-41-115:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

내 일기장

ubuntu@ip-172-31-41-115:~$ ssh -v [email protected]
OpenSSH_8.9p1 Ubuntu-3ubuntu0.6, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 172.31.39.155 [172.31.39.155] port 22.
debug1: Connection established.
debug1: identity file /home/ubuntu/.ssh/id_rsa type -1
debug1: identity file /home/ubuntu/.ssh/id_rsa-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/ubuntu/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519 type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519_sk type -1
debug1: identity file /home/ubuntu/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_xmss type -1
debug1: identity file /home/ubuntu/.ssh/id_xmss-cert type -1
debug1: identity file /home/ubuntu/.ssh/id_dsa type -1
debug1: identity file /home/ubuntu/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
debug1: compat_banner: match: OpenSSH_8.9p1 Ubuntu-3ubuntu0.6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 172.31.39.155:22 as 'ubuntu'
debug1: load_hostkeys: fopen /home/ubuntu/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:VXmUTrEoG6aXhqqnRZpg8RX4i7b8L5r0iAbyKtCmJwU
debug1: load_hostkeys: fopen /home/ubuntu/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '172.31.39.155' is known and matches the ED25519 host key.
debug1: Found key in /home/ubuntu/.ssh/known_hosts:1
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/ubuntu/.ssh/id_rsa
debug1: Will attempt key: /home/ubuntu/.ssh/id_ecdsa
debug1: Will attempt key: /home/ubuntu/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/ubuntu/.ssh/id_ed25519
debug1: Will attempt key: /home/ubuntu/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/ubuntu/.ssh/id_xmss
debug1: Will attempt key: /home/ubuntu/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected]>
debug1: kex_input_ext_info: [email protected]=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ubuntu/.ssh/id_rsa
debug1: Trying private key: /home/ubuntu/.ssh/id_ecdsa
debug1: Trying private key: /home/ubuntu/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/ubuntu/.ssh/id_ed25519
debug1: Trying private key: /home/ubuntu/.ssh/id_ed25519_sk
debug1: Trying private key: /home/ubuntu/.ssh/id_xmss
debug1: Trying private key: /home/ubuntu/.ssh/id_dsa
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).

다음 설정을 사용하여 /etc/ssh/sshd_config(마스터 및 슬레이브) 파일을 변경했습니다.

PermitRootLogin yes 
PubkeyAuthentication yes
 PasswordAuthentication yes 
GSSAPIAuthentication no 
GSSAPICleanupCredentials no

또한 문제가 될 수 있는 경우 보안 그룹의 모든 포트를 열도록 허용했습니다. 하지만 여전히 같은 문제가 있습니다

답변1

간단한 설정과 간단한 공인 IP에서는 모든 포트를 열지 않고, 비밀번호 인증을 사용하고, 루트 로그인을 허용하는 것을 강력히 권장합니다. 두 개의 VMS가 상호 작용하기 위한 것입니다.

이러한 가상 머신을 어떻게 만드는지 잘 모르겠습니다. 가능하다면 다시 시도해 보시는 것이 좋습니다. 구성 변경은 처음부터 최소화됩니다.

AWS에 대해 잘 모르지만, 슬레이브에서 프라이빗 키를 설정하거나 다운로드했어야 했는데, 분실한 경우 다음을 참조하세요.https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#replacing-lost-key-pair

이것을 메인 서버로 보내고 먼저 접근을 줄이세요:

chmod 400 .ssh/your_private_key.pem

확실하게 하기 위해 미리 서버에 ping을 보낼 수 있는지 확인하세요.
또는 AWS 구성으로 돌아가서 확인하세요.

모든 것이 괜찮아 보이고 서버가 실행 중인 경우입니다. 간단한 명령을 시도해 보세요:

ssh -i .ssh/your_private_key.pem your_user@your_ip

분명히 실제 이름으로 사용자를 변경하십시오. 확실하게 하려면 사용자 이름을 두 번 확인하세요.

그래도 문제가 해결되지 않고 여전히 AWS를 통해 서버에 액세스할 수 있으면 다음을 확인해 보세요.

사용자의 실명
다음 명령을 사용하여 SSH 구성을 확인하십시오.sshd -t
구성 업데이트 후 SSH 데몬이 다시 로드되었는지 sudo systemctl sshd reload, 그리고 시작되었는지 확인하세요.
인스턴스에 방화벽이 활성화되어 있는지 확인

이것이 기본 개요입니다. 나는 여전히 보안 고려 사항과 향후 SSHing을 위한 학습 단계로 돌아가서 다시 수행해야 한다고 생각합니다. 저에게는 VM을 시작하는 것만으로도 /var/log/auth.log가 엉망이 되기 때문에 이것이 여러분에게 어떤 영향을 미칠지 상상할 수 없습니다.

이 기능을 사용하려면 전체 설정에 대한 추가 정보를 얻어야 합니다. 사용된 IP나 호스트와 같은 구체적인 세부정보는 피하시기 바랍니다.

답변2

모든 분들의 지원에 감사드립니다. 문제는 다음 단계를 통해 마침내 해결되었습니다.

SSH 키 쌍 생성(아직 완료되지 않은 경우) - 마스터 서버에서

$ ssh-keygen -t rsa -b 4096
SSH 에이전트에 개인 키를 추가합니다(아직 수행하지 않은 경우): - 마스터 서버에서

$ eval "$(ssh-agent -s)" $ ssh-add ~/.ssh/id_rsa
공개 키 내용 인쇄 - 주 서버에서

$ 고양이 ~/.ssh/id_rsa.pub
공개 키를 나타내는 cat 명령의 출력을 복사합니다.
슬레이브 서버에 로그인
텍스트 편집기를 사용하여 Authorized_keys 파일을 열고 마스터 서버에서 복사한 공개 키를 붙여넣습니다.

$ 나노 ~/.ssh/authorized_keys
슬레이브 서버의 ~/.ssh 디렉터리 및 authenticate_keys 파일에 대한 적절한 권한을 설정합니다.

$ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys

관련 정보