TL;DR 한 원격 서버의 (로 설정 )에서 새 AWS EC2 인스턴스로 몇 개의 디렉터리를 편집했습니다
. 이제 오류 로 인해 들어갈 수 없게 되었습니다 .rsync/home/ubuntu777sshPermission denied (publickey)
프로덕션 환경을 SoftLayer에서 AWS로 마이그레이션하는 중입니다.
EC2(EBS)에 여러 디렉터리 가 있어야 했고 rsync그 과정에서 이전 디렉터리에서 /home/ubuntu/현재 EC2 인스턴스의 /home/ubuntu/.
(목적지에서) 내 rsync명령은 다음과 같습니다.
ubuntu@[aws.remote.ec2]:~$ sudo rsync --include 'dir1' --include '*.sh' --include '.py' --include 'api_logs' --include 'database_backups' --exclude '*' -avz -e "ssh -p $portNumber" ubuntu@[softlayer.remote]:/home/ubuntu/ /home/ubuntu/
파일이 성공적으로 전송되었습니다. 다음에 EC2에 접속 하려고 했을 때 옵션이 포함된 다음 로그를 ssh받았습니다 . (아래 로그에서 IP와 같은 개인 정보를 {}로 마스킹했습니다.)Permission denied (publickey)ssh -v
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/{localuser}/.ssh/config
debug1: /home/{localuser}/.ssh/config line 1: Applying options for aws-fr-
ec2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to {aws.ec2.ip} [{aws.ec2.ip}] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/{localuser}/Documents/AWS-Files/EC2-FR.pem type
-1
debug1: key_load_public: No such file or directory
debug1: identity file /home/{localuser}/Documents/AWS-Files/EC2-FR.pem-cert
type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2
Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat
0x04000000
debug1: Authenticating to {aws.ec2.ip}:22 as 'ubuntu'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
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: Server host key: ecdsa-sha2-nistp256
SHA256:g3nWVGmjJYVrNrwsDJMhzbLSw0FzBOLoUx80seD9qIs
debug1: Host '{aws.ec2.ip}' is known and matches the ECDSA host key.
debug1: Found key in /home/{localhost}/.ssh/known_hosts:11
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/{localhost}/Documents/AWS-Files/EC2-
FR.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
나는 우연히 발견했다이것질문은 있지만 도움은 없습니다. 나도 찾았어이것AWS 포럼의 스레드.
나는 나열된 단계를 따랐습니다.
게시자: mary@AWS:
이 인스턴스의 /home/ubuntu/.ssh 디렉터리와 여기에 포함된 파일에 대한 권한을 확인해 주시겠습니까?
권한을 확인하려면 인스턴스를 중지하고 루트 볼륨을 분리할 수 있습니다(연결된 디바이스를 기록해 두십시오). 그런 다음 사용 가능한 디바이스의 다른 인스턴스에 볼륨을 연결합니다. 필요한 경우 /fixroot와 같은 마운트 지점을 생성하고 이 마운트 지점에 장치를 마운트합니다. 마운트되면 /fixroot/home/ec2-user로 이동하여 디렉터리 및 파일 권한을 확인하세요. .ssh 디렉터리는 사용자(소유자)에 대해 rwx를 허용해야 하며 파일은 사용자만 읽을 수 있어야 합니다.
거기 있는 동안 확인해야 할 또 다른 사항은 Known_hosts 파일에 연결을 시도하는 클라이언트에 대한 중복 항목이 없다는 것입니다.
이 작업을 완료한 후에는 볼륨을 마운트 해제하고 인스턴스에서 분리할 수 있습니다. 그런 다음 첫 번째 단계에서 기록한 디바이스의 원래 인스턴스에 다시 연결하고 인스턴스를 시작합니다.
게다가
게시자: yromanenko:
알고 보니 ssh가 아닌 home/ubuntu 폴더에 대한 완화된 권한이었습니다. 루트 볼륨을 분리하고 권한을 수정하여 문제를 해결할 수 있었습니다. 다음 비디오는 단계를 안내하는 데 매우 도움이 되었습니다.
http://d2930476l2fsmh.cloudfront.net/LostKeypairRecoveryOfLinuxInstance.mp4
새 t2.micro인스턴스를 생성하고 의 단계에 따라 디렉터리 에 설정할 Mary권한과 의 해결 방법을 확인했습니다 .yromanenko755/home/ubuntu
문제가 있는 EBS 장치를 첫 번째 EC2에 다시 연결했지만 /dev/sda1동일한 Permission denied (publickey)오류로 인해 실패하려고 했습니다!!
결과적으로 이제 보조 인스턴스에서도 동일한 오류가 발생합니다 t2.micro. :(
어떤 도움이라도 주시면 감사하겠습니다!
답변1
나는이 정확한 문제를 겪었습니다. 저는 다른 인스턴스를 가동하여 차이점을 식별하기 위해 Amazon EC2 인스턴스를 사용하고 있었습니다. 손상된 시스템의 권한은 777이고 손상되지 않은 시스템의 권한은 700입니다. 설명할 수 없는 이유로 /home/user에 대한 rsync는 /home/user의 권한을 777로 변경합니다. 분명히 SSH에서는 /home/user가 700이 되어야 합니다. 보안상의 이유로. 이것은 또한 거북이가 끝까지 내려가고 다시 rsync되고 다시 중단되는 이유를 설명합니다.
운이 좋게도 다른 방법으로 디렉토리에 접근할 수 있다면,
chmod 700 /home/user
그것을 수정합니다.
앞으로는 /home/user의 하위 디렉터리로 rsync하십시오.