일련의 가상 머신 및 하드웨어 서버에 액세스하기 위해 사용자 및 루트 계정에 대해 SSH를 구성하는 동안 공개/개인 키 관계 관점에서 볼 때 이해가 되지 않는 상황에 직면했습니다.
권장되는 단계는 다음과 같습니다.
ssh user@vm1생산하다The authenticity of host 10.1.10.9 can't be established. Are you sure you want to connect?
yesvm1 시스템 키의 지문을 파일에 입력하도록 선택합니다 ~/.ssh/known_hosts.
ssh user@vm1반환 Permission denied(공개키, gssapi, ...)
ssh-keygen로그인한 사용자('user')에 대한 ~/.ssh/id_rsa로컬 키 쌍을 생성합니다 id_rsa.pub. 둘 다 사용자의 컴퓨터 ID로 레이블이 지정됩니다: [email protected].
다음 단계의 버전은 다음과 같습니다.ssh-copy-id [-i ~/.ssh/id_rsa.pub] user@vm1
이는 PasswordAuthentication설정되어 있고 no대역 외에서 수정되어야 하기 때문에 일반적으로 실패합니다. /etc/ssh/sshd_config그런 다음 ssh-copy-id'사용자의 공개 키를 ~/.ssh/_authorizedkeysvm1의 파일에 복사할 수 있습니다.
성공적인 결과는 ssh-copy-id공용 파일의 (로컬) 소스와 원격에 추가된 키 수(1)를 식별합니다.
이때 PasswordAuthentication다시 설정할 수 있습니다 no.
이제 사용자의 파일에는 ~./ssh/authorized_keys사용자 이름과 컴퓨터 ID로 표시된 키가 포함되어 있습니다.
이제 다른 사용자(예: 루트)에 대해 SSH 로그인을 설정해 보겠습니다.
여전히 사용자로 로그인되어 있습니다.
ssh-copy-id root@vm1(비밀번호 확인 단계를 건너뜁니다...) 성공했습니다. [사용자]의 공개 키를 authorized_keysvm1 루트 폴더 ~/.ssh/의 파일 에 복사했습니다. 키에는 여전히 [사용자]의 이름과 컴퓨터 레이블이 붙어 있습니다.
이 작업에는 분명히 결함이 있는 것처럼 보일 수도 있고 그렇지 않을 수도 있습니다... MAC을 사용하는 경우 MAC에는 루트 사용자 폴더가 없기 때문에 이와 같은 것이 유일한 옵션입니다 ~/.ssh/.
이것의 효과는 다른 컴퓨터의 모든 사용자가 루트 비밀번호가 있는 모든 컴퓨터에서 SSH 루트 로그인을 만들 수 있다는 것입니다. authorized_keys대상 시스템 ~/.ssh/의 루트 폴더에 있는 파일 에 저장된 [사용자] 계정 공개 키를 기반으로 컴퓨터에 루트로 로그인할 수 있습니다 .
나에게 이것은 사용자의 공개 키가 로그인 권한을 인증하지만 대상 루트의 해당 개인 키가 ~/.ssh/원본 시스템의 제한된 루트 계정 폴더에 저장되지 않기 때문에 대상 시스템의 루트 액세스 보호가 약화되는 것처럼 보입니다.
내가 뭐 놓친 거 없니?
답변1
여전히 ssh-copy-id root@vm1 사용자로 로그인(비밀번호 인증 단계 건너뛰기...)에 성공하여 [user]의 공개 키를 vm1의 루트 ~/.ssh/ 폴더에 있는 Authorized_keys 파일에 복사했습니다. 키에는 여전히 [사용자]의 이름과 컴퓨터 레이블이 붙어 있습니다.
SSH 키 기반 인증의 원칙은 다음과 같습니다.클라이언트가 서버에서 요청한 사용자 이름 파일의 공개 키에 해당하는 개인 키를 소유하고 있음을 암호화 방식으로 증명할 수 있는 경우 ~/.ssh/authorized_keys액세스가 허용됩니다 .그게 다야. "[사용자] 이름 및 컴퓨터"는 실제로 사람들이 특정 공개 키를 쉽게 식별할 수 있는 자유 형식 텍스트 필드입니다. 이 필드의 내용은 어떤 방식으로든 인증에 사용되지 않습니다.
기본적으로 SSH 서버는 다음과 같은 이유로 들어오는 연결에서 클라이언트가 주장하는 사용자 이름에 신경 쓰지 않습니다.
- 클라이언트는 이를 서버에 공개하기를 원하지 않을 수 있습니다.
- 서버는 어떤 방식으로든 클라이언트 사용자 이름을 확인할 수 없습니다.
- 있다고 하더라도 도난당한 키를 가진 악의적인 클라이언트는 클라이언트에 도움이 되는 클라이언트 사용자 이름을 구성할 수 있습니다.
SSH 키 인증 사용을 제한하려면 매뉴얼 페이지에 설명된 대로 파일에 SSH 키를 authorized_keys추가 하면 됩니다 from="<hostname-or-IP-address-pattern>".sshd
이 옵션의 목적은 선택적으로 보안을 강화하는 것입니다. 공개 키 인증 자체는 네트워크나 이름 서버 또는 그 어떤 것(키 제외)도 신뢰하지 않습니다. 그러나 누군가 어떻게든 키를 훔치면 키를 통해 침입자가 어디에서나 로그인할 수 있습니다. 세상에. 이 추가 옵션을 사용하면 도난당한 키를 사용하기가 더 어려워집니다(키 외에 이름 서버 및/또는 라우터도 손상되어야 함).
나에게 이것은 사용자의 공개 키가 로그인을 인증하지만 대상 루트의 해당 개인 키가 소스 시스템 ~/.ssh / 폴더의 제한된 루트 계정에 저장되지 않기 때문에 대상 시스템의 루트 액세스 보호가 약화되는 것처럼 보입니다.
이는 원본 컴퓨터가 항상 대상 컴퓨터와 동일한 관리 제어를 받는 경우에만 해당됩니다. SSH는 이를 가정하지 않으며 소스 시스템을 기반으로 사용자가 누구인지 인식하는 것은 쓸모가 없습니다.라고 주장했다그 주장을 확인할 방법이 없다면 말이죠.
실행하고 루트 비밀번호를 성공적으로 입력하려는 경우 user@vm1이 예에서 발생하는 결과에 ssh-copy-id root@vm1놀랄 수도 있습니다. ssh-copy-idSSH 개인 키가 없고 SSH 프록시 전달이 허용되는 user@vm1:.ssh/id_*경우 프록시 연결을 사용하여 Mac 클라이언트 호스트에서 공개 키를 가져옵니다. 이것이 이름과 컴퓨터로 레이블이 지정된 공개 키가 파일 에 저장되는 방식입니다.sshdvm1ssh-copy-id[user]root@vm1:.ssh/authorized_keys
최신 macOS에는 ssh-agent모든 macOS 사용자 세션에서 기본적으로 사용할 수 있는 macOS Keyring과 통합된 확장 기능이 있습니다. 일반적인 OpenSSH 동작을 기대한다면 이는 놀랄 수도 있습니다.