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.