SSH 키 기반 인증 : known_hosts 및 Authorized_keys


21

Linux에서 ssh 키 설정에 대해 읽었으며 몇 가지 질문이 있습니다. 틀 렸으면 말해줘…

호스트 tr-lgto가 ssh를 사용하여 호스트 tr-mdm에 연결하려고한다고 가정합니다. 실제 known_hoststr-mdm인지 확인 하려면 tr-mdm 에 키 쌍을 생성하고 tr-lgto에 공개 키를 추가합니다 . tr-mdm이 실제 tr-lgto인지 확인하려면 tr-lgto가 키 쌍을 생성하고 공개 키를 tr-mdm에 추가해야합니다 authorized_keys.

질문 1 : known_hosts 파일에 사용자 필드 가없고 IP 주소와 호스트 이름 만 있습니다. tr-mdm에는 각각 자신의 .ssh폴더 가있는 많은 사용자가있을 수 있습니다 . 각 known_hosts파일에 공개 키를 추가해야합니까 ?

질문 2 : ssh-keyscan -t rsa tr-mdmtr-mdm의 공개 키를 반환 한다는 것을 알았습니다 . 이 키가 어떤 사용자인지 어떻게 알 수 있습니까? 또한 공개 키 입력 /root/.ssh/은 해당 명령이 반환하는 것과 다릅니다. 어떻게 이럴 수있어?



나는 @Gilles 언급 질문에 "보안 파일을 포함하는 공개 키 정보"에 대한 답변에서 'SSH'에 대한 몇 가지 배경 컨텍스트를 추가 : < security.stackexchange.com/questions/20706/... >
IAM_AL_X

답변:


33

서버 시스템의 인증을 클라이언트 시스템에 혼합하고 사용자의 인증을 서버 시스템에 혼합합니다.

서버 인증

SSH 연결이 설정 될 때 가장 먼저 발생하는 것 중 하나는 서버가 공개 키를 클라이언트로 보내고, 공개 키 암호화 덕분에 클라이언트가 관련 개인 키를 알고 있음을 증명 한다는 것입니다. 이렇게하면 서버가 인증됩니다. 프로토콜의이 부분이 성공하면 클라이언트는 서버가 자신을 가장하는 사람임을 알고 있습니다.

클라이언트는 서버가 알려진 서버인지 확인하고 일부 불량 서버는 올바른 서버로 전달하려고하지 않습니다. SSH는 서버의 적법성을 확인하는 간단한 메커니즘 만 제공 ~/.ssh/known_hosts합니다. 클라이언트 시스템 의 파일 (시스템 전체 파일도 있음 /etc/ssh/known_hosts) 에서 이미 연결된 서버를 기억합니다 . 서버에 처음 연결하는 경우 서버에서 제공 한 공개 키가 실제로 연결하려는 서버의 공개 키임을 확인해야합니다. 연결하려는 서버의 공개 키가 있으면이를 ~/.ssh/known_hosts클라이언트에 수동으로 추가 할 수 있습니다 .

기밀 데이터를 보내기 전에 서버를 인증해야합니다. 특히, 사용자 인증에 비밀번호가 포함 된 경우 인증되지 않은 서버로 비밀번호를 보내면 안됩니다.

사용자 인증

서버는 원격 사용자가 해당 계정에 액세스 할 수있는 권한이 있음을 증명할 수있는 경우에만 원격 사용자 로그인을 허용합니다. 서버의 구성과 사용자의 선택에 따라 사용자는 여러 형태의 자격 증명 중 하나를 제시 할 수 있습니다 (아래 목록은 완전한 것은 아님).

  • 사용자는 로그인하려는 계정의 비밀번호를 제시 할 수 있습니다. 그런 다음 서버는 비밀번호가 올바른지 확인합니다.
  • 사용자는 공개 키를 제시하고 그 공개 키와 관련된 개인 키를 소유하고 있음을 증명할 수 있습니다. 이것은 서버를 인증하는 데 사용되는 것과 동일한 방법이지만, 이제 사용자는 자신의 신원을 증명하려고 시도하고 서버는이를 확인합니다. 사용자가 개인 키를 알고 공개 키가 계정의 권한 부여 목록 ( ~/.ssh/authorized_keys서버)에있는 경우 로그인 시도가 승인됩니다 .
  • 다른 유형의 방법에는 사용자 인증 작업의 일부를 클라이언트 시스템에 위임하는 것이 포함됩니다. 많은 컴퓨터가 동일한 계정을 공유하는 기업과 같은 통제 된 환경에서 발생합니다. 서버는 다른 방식으로 사용되는 것과 동일한 메커니즘으로 클라이언트 시스템을 인증 한 다음 클라이언트를 사용하여 사용자를 인증합니다.

1
좋은 답변 Gilles,하지만 내 질문은 모든 서버가 임의의 공개 키를 보내고 관련 공개 키가 있음을 증명할 수 있다는 것입니다. 서버가 정품임을 어떻게 증명합니까?
Alex

@ 스파르타쿠스 나는 당신이 "그리고 관련 개인 키가 있음을 증명"을 의미한다고 생각합니까? 아이디어는 클라이언트가 무작위로 생성 된 값 ( 챌린지 )을 서버에 보내고 서버는 도전에 따라 개인 키를 기반으로 계산을 수행하므로 서버는이를 수신 할 때까지 계산을 수행 할 수 없습니다 도전) 그리고 그것은 개인 키에 대한 지식으로 만 가능합니다.
Gilles 'SO- 악의를 멈춰라'

Alex가 클라이언트가 서버에 처음 연결하는 것을 말합니다. 클라이언트가 처음으로 서버를 신뢰한다고 생각합니다. 그런 다음 서버는 공개 키를 보내고 클라이언트는 다음 연결에 대해 서버를 인증 할 수 있습니다.
synack

@synack 아, 처음? 오히려 클라이언트는 사용자가 결정을 내릴 수있게합니다 ( "계속 하시겠습니까?"). 서버는 그 시점에서 아무 것도 증명하지 않습니다.
Gilles 'SO- 악마 그만'

당신이 옳습니다. 결정을 내리는 것은 사용자입니다.
synack

2

내 친구가 답을 주었다. 기본적으로 키는 사용자가 아닌 컴퓨터를 식별합니다. 따라서 키는 / etc / ssh /에 저장됩니다. 그래서 /root/.ssh에 저장된 것과 다른 키를 얻었습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.