SSH에서 엄격한 RSA 키 검사를 제거하는 방법은 무엇입니까?


42

Linux 서버에 연결할 때마다 SSH 호스트 키를 변경 한 메시지가 표시됩니다.

$ ssh root @ host1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@ @ @ 경고 : 원격 호스트 ID가 변경되었습니다! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@ 누군가가 불쾌한 일을하고있는 것이 가능합니다! 누군가 지금 당장 도청 할 수 있습니다 (중간자 공격)! RSA 호스트 키가 변경되었을 수도 있습니다. 원격 호스트가 보낸 RSA 키의 지문은 93 : a2 : 1b : 1c : 5f : 3e : 68 : 47 : bf : 79 : 56 : 52 : f0 : ec : 03 : 6b입니다. 시스템 관리자에게 문의하십시오. 이 메시지를 제거하려면 /home/emerson/.ssh/known_hosts에 올바른 호스트 키를 추가하십시오. /home/emerson/.ssh/known_hosts의 위반 키 : 377

host1의 RSA 호스트 키가 변경되었으며 엄격한 검사를 요청했습니다. 호스트 키 확인에 실패했습니다.

몇 초 동안 로그인 상태를 유지 한 다음 연결을 닫습니다.

host1 : ~ / .ssh # 원격 호스트에서 읽습니다. host1 : 피어에 의한 연결 재설정 host1에 대한 연결이 닫혔습니다.

누구나 무슨 일이 일어나고 있으며이 문제를 해결하기 위해 무엇을 할 수 있는지 알고 있습니까?


1
이것은 이전의 질문에 속는 : serverfault.com/questions/2988/...을
드류 스티븐스

답변:


68

일부 사람들이 권장하는 것으로 알려진 known_hosts 파일 전체를 삭제하지 마십시오. 이로 인해 경고 지점이 완전히 무효화됩니다. 중간 공격에 걸린 사람이 발생했을 수 있음을 경고하는 보안 기능입니다.

변경 사항이 있다고 생각하는 이유를 식별하는 것이 좋습니다. 아마도 보안 허점으로 인해 SSH 업그레이드로 암호화 키가 변경되었을 가능성이 큽니다. 그런 다음 known_hosts 파일에서 특정 행을 제거 할 수 있습니다.

sed -i 377d ~/.ssh/known_hosts

(D)는 경고에 콜론 이후 도시 한 바와 같이 라인 377 eletes :

/home/emerson/.ssh/known_hosts:377

또는 다음을 수행하여 관련 키를 제거 할 수 있습니다

ssh-keygen -R 127.0.0.1 (obviously replace with the server's IP)

전체 키를 제거하지 말고 특정 키를 제거하기 전에 실제로 연결하려는 시스템인지 확인하십시오.


하나의 키 불일치로 인해 350 개가 넘는 서버를 삭제하지 않습니다. 왜 연결을 계속 닫는 지 아십니까?
setatakahashi 0:25의

관련 known_hosts 레코드를 제거한 후에도 해결되지 않습니까? 그렇지 않은 경우 ssh 클라이언트를 자세한 모드로 실행하여 어딘가에 붙여 넣을 수 있습니까?
Adam Gibbins

1
호스트 키가 유효하지 않기 때문에 시스템을 닫고 있습니다. 보안이 진지한 경우 서버 관리자에게 문의하여 호스트 키가 정당한 이유로 변경되었는지 확인해야합니다. 그렇다면 Adam의 설명에 따라 교체 할 수 있습니다.
Matthew Flaschen

나는 당신의 제안을 따랐지만 $ sed -i "46 d"~ / .ssh / known_hosts sed : 1 : "/Users/myusr/.ssh ...": l 명령 끝에 여분의 문자가 있으므로 수동으로 제거했습니다. vim과 효과가있었습니다. 고맙습니다!
루이스 라미레즈 몬테

3
Adam의 구문은 거의 맞지만 "377"과 "d"사이에 공백이 필요합니다. 또한 OS X에서 알려진 호스트는 ~ / .ssh / known_hosts에 있습니다. "."의 부족에 주목 파일 이름에.
ktappe

27

여기에있는 답변 중 일부는 OP의 질문에서 권장되는 행동 과정을 다루고 있지만 질문에 완전히 대답하지는 않습니다.

"SSH에서 엄격한 RSA 키 검사를 제거하는 방법과 문제는 무엇입니까?"

여기에서 문제는 다른 사람들의 조언에 따라 서버 재설치로 인한 호스트 변경 (대부분의 일반적인 시나리오)입니다. 그리고 권장 솔루션은 실제로 인라인 sed가있는 .ssh / authorized_keys 파일에서 문제가되는 키를 제거하는 것입니다.

그러나 나는 " SSH에서 엄격한 RSA 키 검사를 제거하는 방법 "이라는 질문의 특정 부분에 대한 답변을 보지 못했습니다 .

일반적으로에 저장된 ssh 구성 파일에서 StrictHostKey 검사를 제거 할 수 있습니다 ~/.ssh/config.

호스트 블록의 예는 다음과 같습니다.

Host 101
  HostName yourip|hostname
  User youruserid
  IdentityFile /path/to/keyfile
  Port 22
  StrictHostKeyChecking no

구체적으로 추가 된 줄은 그 일 StrictHostKeyChecking no을 하는 마지막 줄 입니다. 특정 시나리오에 따라이 기능은 전용 서버에서 여러 개의 가상화 된 컨테이너를 몇 개의 IP로 실행하거나 동일한 IP에서 다른 인스턴스를 중지 및 시작하는 등의 경우 유용 할 수 있습니다.


3
+1이 게시물은 실제로 오류 메시지의 엄격한 검사 부분을 다루기 때문입니다.
Shibumi

1
질문의 내용을 해결 해주셔서 감사합니다. 요인에 따라해야 할 일이 더있을 수 있습니다. 이 접근 방식은 호스트 검사를 "엄격한"에서 "일부"(내 용어)로 저하시킵니다. 로그인하려는 방식으로 비밀번호를 입력하지 않고 "일부"호스트 검사를 통해 비활성화 되었기 때문에 ssh에서 로그인을하지 못하도록 허가 한 상태가되었습니다. 따라서 ssh가 / dev / null을 "UserKnownHostsFile"로 사용하도록 지시해야합니다. 이렇게하면 호스트 검사가 "없음"으로 설정되고 위의 화재 경고가 적용되므로 전체적으로 또는 영구적으로 수행하지 마십시오.
카디프 우주 남자

이것은 정말 우아한 솔루션입니다. 공유해 주셔서 감사합니다!
LeOn-한 리

10

단일 서버에 대해서만 필요한 경우 StrictHostKeyChecking을 제거하는 또 다른 방법 :

ssh <server> -o StrictHostKeyChecking=no

로그인 할 수는 있지만 문제를 영구적으로 해결할 수는 없습니다.
Andres Canella

내가 할 때 나에게 다음 영구적으로 문제를 해결 키를 추가 할 수있는 기회 제공
그렉 도허티

아마도 우리는 다른 문제가 있습니까? 전에 다른 IP를 가진 서버에 연결하고 있습니다.
Andres Canella

데이터가 변경된 서버가있는 경우 알려진 호스트 파일에서 데이터를 삭제하고 (먼저 변경이 올바른지 확인한 후) 새 정보를 추가해야합니다. 새 서버가있는 경우 -o를 사용하면 서버에 연결하여 정보를 추가 할 수 있습니다.
Greg Dougherty

실제로 구성에서 StrictHostKeyChecking을 YES로 설정하고 새 서버에 연결하거나 이전 서버의 키를 변경했다는 것을 알고있는 경우에만이 스위치를 사용하는 것이 좋습니다.
mohak

5

우선,이 기계는 당신의 기계입니까? 의도적으로 호스트 키를 변경 했습니까? 그렇지 않다면 무언가가 그 데이터를 변경했다는 것이 매우 걱정됩니다.

둘째, ssh 디버깅을 켜십시오.

ssh -vvv user@host

단서를 위해 연결하려는 서버에서 / var / log / secure 및 / var / log / messages를 찾아보십시오. sshd는 좋은 오류 메시지를 제공합니다.

셋째,이 기계는 인터넷에 연결되어 있습니까? 정말로 루트 로그인을 허용해야합니까?


1
루트 +1 코멘트를의 로그인
파하드 Sadah

이 오류가 발생하는 데 필요한 것은 재 이미징중인 대상 시스템입니다. DMZ 측면에있는 대상에 연결하는 경우 MitM 공격이 거의 발생하지 않습니다.
ktappe

3

새로운 NIC, 새 IP, 서버 소프트웨어 변경 등과 같은 사항이 변경되었으므로이 문제가 발생합니다. 보안 초점은 SSH 호스트 키 보호 에 대한 좋은 기사입니다 .

$HOME/.ssh/known_hosts파일 을 편집하여 서버에서 키 (SFTP 또는 유사 항목 사용)를 제거하고 다음 연결시 새 키를 수락하십시오.

StrictHostKeyChecking 설정으로 인해 연결이 끊어 질 수 있습니다. 비슷한 문제는 이 스레드 를 참조하십시오 .


2
안돼, 제발 이러지마 이것은이 기능이 제공하는 모든 보안을 완전히 무효화합니다. known_hosts가 아닌 변경된 특정 키만 제거하십시오.
Adam Gibbins

5
known_hosts 파일을 제거하지 말고 편집하고 키를 제거하는 것이 좋습니다.

죄송합니다, 잘못 읽었습니다.
Adam Gibbins

2
이 메시지는 새로운 NIC에 의해 훨씬 적은 새로운 IP 주소에 의해 트리거 될 수 없습니다. Adam Gibbins의 정답을 참조하십시오.
bortzmeyer

1
당신이 투표하기 전에 (나는 사람들이 이것에 매우 만족한다고 생각합니다), 당신의 연구를하십시오. 이 보안 포커스 기사 인 securityfocus.com/infocus/1806을 읽으십시오 . "호스트 키가 변경 될 수있는 이유는 무엇입니까? 연결하려는 컴퓨터가 다른 DNS 이름 또는 IP 주소로 이동했거나 완전히 새로운 컴퓨터로 교체되었습니다." 답이 끔찍한 경우, 정정 할 기회를주십시오. 결국 이것은 위키입니다.

3

'호스트'(광범위하게 정의되었으므로 다시 설치 / 멀티 부팅에서 예를 들어 이전에 연결 한 IP 주소를 가진 완전히 다른 컴퓨터에 이르기까지 모든 것이 될 수 있음)가 ssh 클라이언트에 변경된 것처럼 보이면 오류.

엄격한 검사를 해제 할 필요가 없으며 저장된 키의 도매 삭제도 감지 할 수 없습니다.

특정 호스트 이름 또는 IP 주소에 대해 known_hosts에 두 개의 다른 키를 나열하는 것이 가능합니다. 현재 known_hosts에 저장된 '이전'키가 필요한지 여부에 따라 두 가지 대안을 제공합니다.

OP에 대해 알려진 호스트의 l377에서 참조하는 특정 키를 삭제하거나 둘 다 유지하십시오.

known_hosts에서 키를 삭제하지 않고 두 가지를 모두 유지하는 가장 간단한 방법은

  1. known_hosts [@ l377]에서 일시적으로 참조 된 'old'항목의 시작 부분에 #을 추가하도록 known_hosts를 편집하십시오.
  2. [ssh를 호스트에 연결], '자동으로'새 키를 추가하라는 메시지에 동의
  3. 그런 다음 known_hosts를 다시 편집하여 #

"known_hosts에 올바른 호스트 키 추가"/ 호스트 이름 당 여러 ssh 호스트 키에 대한 답변이 더 있습니까?


나는 두 가지 키 트릭에 대해 몰랐습니다. 이것은 문서화 된 행동이 아닙니까?
hackerb9
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.