새 편집기:

그래서 나는 돌아가서 몇 가지 심각한 테스트를 수행하고 문제에 대한 나의 견해를 약간 수정했습니다.

먼저, 완전하고 이해하기 쉬운 SSH 핸드셰이크 다이어그램에 대한 링크는 다음과 같습니다(동일한 페이지로 이동하기 위해).SSH 키 설명.

그래서 작업 중인 두 개의 Centos7 시스템에서 사용자의 .ssh 폴더와 루트 디렉터리를 정리했습니다. 컨트롤러는 가상 머신이고 서버는 금속입니다.

관심 있는 SSHD_Config 값은 다음과 같습니다.

#Port22, Protocol 2, PermitRootLogin yes, #StrictModes yes, 
PubKeyAuthentication yes, AuthorizedKeysFile .ssh/authorized_keys,
AllowUsers root me_meaning_me, PasswordAuthentication yes (only to allow ssh-copy-id operations to start), #PasswordAuthentication no, 
#ChallengeResponseAuthentication yes, ChallengeResponseAuthentication no,
ClientAliveTime 120, ClientAliveCountMax 720 for tripleo openstack timeout
UsePAM yes, GSSAPI yes

시작: ~/.ssh/ 위치, 사용자, 루트 사용자, 로컬 또는 서버에 파일이나 폴더가 없습니다.

1. ssh me@server- 비밀번호 승인됨 - 최종 상태: 새 로컬 Known_hosts의 새 서버 지문.
2. ssh-keygen me@server- 눈에 띄는 결과 없음 - 최종 상태 id_rsa 비공개, 로컬 id_rsa.pub 파일 ~/ssh/.
3. ssh-copy-id me@server- 눈에 띄는 결과가 없습니다. - 최종 상태: rsa-shaw서버에서 내 ~/.ssh/authorized_keys이름은 입니다 me@server.
4. me@serverSSH를 통해 서버에 연결할 수 있지만 서버 측 비밀번호를 제공해야 합니다.
5. ssh-keygen -f root-key root@server- 눈에 보이는 결과 없음 - 최종 상태: 로컬 me의 root-key rsa 개인 키 및 root-key.pub 공개 키 ~/.ssh/.
6. ssh-copy-id -i ~/.ssh/root-key.pub root@server- 키 및 root@server에 관한 일부 응답은 서버측 비밀을 제공해야 합니다.
7. 서버측 편집 /etc/ssh/sshd_config- #PasswordAuthentication yes및 로 변경합니다 PasswordAuthentication no.
8. ssh me@server성공했으며 비밀번호가 필요하지 않습니다.
9. ssh root@serverPublicKey, GSSAPI 오류로 인해 실패했습니다.
10. 많은 값 변경을 시도했지만 sshd_config모두 다시 얻었습니다.
11. kvm 스위치를 사용하여 서버에 로그인하고 루트 ~/.ssh/authorized_keys파일을 확인합니다. 파일의 단일 키는 me@server에 대해 생성된 키와 동일합니다.
12. 그들은 ssh-keygen -f root-key root@sever동일한 키를 생성하고 me@serverID를 추가했습니다.
13. ssh-copy-id -i root-key.pub root@serverme@server의 키와 동일한 키를 루트 파일로 이동합니다 ~/.ssh/authorized_keys.

이제 이 문제에 대한 원래 이름은 이러한 단계를 몇 시간에 걸쳐 여러 번 수행하고 항상 동일한 결과를 얻는 데 기반을 두고 있습니다.

이제 우리는 어떻게 생각합니까?