“known_hosts에 올바른 호스트 키 추가”/ 호스트 이름 당 여러 개의 ssh 호스트 키가 있습니까?


147

내가 제어하는 ​​컴퓨터에 ssh하려고하면 익숙한 메시지가 나타납니다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
[...].
Please contact your system administrator.
Add correct host key in /home/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.

나는 정말로 열쇠를 바꾸었다. 그리고이 문제를 해결하는 방법은 known_hosts파일 에서 이전 키를 삭제하는 것 입니다.

그러나 내가 원하는 것은 ssh가 이전 키와 새 키를 모두 수락하도록하는 것입니다. 오류 메시지 ( " Add correct host key") 의 언어 는 이전 호스트 키를 제거하지 않고 올바른 호스트 키를 추가 할 수있는 방법이 있어야한다고 제안합니다.

이전 호스트 키를 제거하지 않고 새 호스트 키를 추가하는 방법을 알 수 없었습니다.

이것이 가능합니까, 아니면 오류 메시지가 잘못 오도됩니까?


9
이것은 오류를 생성하는 호스트 키입니다. 호스트에는 하나의 키만 있어야합니다. 이것은 클라이언트 또는 사용자 키와 관련이 없습니다. 별개의 호스트 또는 다른 것 사이에 떠있는 IP 주소가 하나 있습니까?
David Schwartz

4
내 경우에는 가까운 장래에 두 가지 키를 많이 전환하면서 몇 가지 사항을 다루 겠다는 것을 알고 있습니다. 이것은 여러 호스트 상황이있는 하나의 IP에서도 유용 할 것 같습니다. 주로 특정 실용적 응용 프로그램을 제외하고 본인의 교육이 가능한지 알고 싶습니다.
Samuel Edwin Ward

답변:


148
  1. 서버의 rsa 키를 가져옵니다. server_ip서버의 IP 주소는 다음과 같습니다 192.168.2.1.

    $ ssh-keyscan -t rsa server_ip
    

    샘플 응답 :

    # server_ip SSH-2.0-OpenSSH_4.3
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    
  2. 클라이언트에서 전체 응답 행을 복사 server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...하고이 키를 ~/.ssh/known_hosts파일 맨 아래에 추가 하십시오.

    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key, and/or the very bottom of the `known_hosts` file)
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG... (line you're adding, copied and pasted from above)
    

12
이것은 효과가 있었다! 그러나 "HashKnownHosts"를 사용하고 있으므로 항목이 약간 다르게 보입니다. 운 좋게도 ssh_config (5)는 ssh-keygen (1)을 가리키며 "ssh-keygen -H"를 사용하여 해시되지 않은 항목을 해시 할 수 있다고 설명했습니다. 감사합니다!
Samuel Edwin Ward

2
이 "작동"하지만 키를 확인하지 않으므로 mitm 공격에 취약합니다.
JasperWallace

3
@JasperWallace은, 첫 번째 단계는 (예를 사용하여 로컬 호스트에 대한) 보안 연결을 통해 이루어집니다만큼 꽤 안전해야, 내가 생각
ONY

3
서버에서 모든 키 유형을 수집 할 수있는 방법이 있습니까? 때때로 당신은 그들이 RSA, DSA, ECDSA, RSA1인지 알지 못합니다.
Sopalajo de Arrierez

3
같은 맨 페이지는 또한 쉼표로 유형을 분리, 그렇게 할 수 있다고 @SopalajodeArrierez ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip하지만 유일한 이유 찾을 - rsa1dsa키를 재구성 / 업그레이드해야 서버를 식별하는 것입니다
kbolino

94

다음을 사용하여 known_hosts에서 해당 항목을 제거하십시오.

ssh-keygen -R *ip_address_or_hostname*

known_hosts 파일 에서 문제가있는 IP 또는 호스트 이름을 제거하고 다시 연결을 시도합니다.

매뉴얼 페이지에서 :

-R hostname
known_hosts 파일에서 호스트 이름에 속하는 모든 키를 제거합니다. 이 옵션은 해시 된 호스트를 삭제하는 데 유용합니다 (위의 -H 옵션 참조).


11
"이전 호스트 키를 제거하지 않고 새 호스트 키를 추가하는 방법"
사무엘 에드윈 워드

4
이것은 최고의 솔루션입니다!
Thomas Decaux

8
이것은 어떻게 19 표를 얻습니까? 그것은 질문에 대답하는 것에 가깝지 않습니다 ..
Molomby

2
"git ssh update host key automatically"에 대해 Google을 검색하면 귀하의 질문이 두 번째로 나타납니다. 이 대답은 내가 찾던 것입니다. 정확히 내가 원하는 것을 사용하여 새 질문을 열면 중복으로 닫힐 수 있습니다.
Jason Goemaat

호스트 이름도 작동합니다
damluar

18

매우 간단한 방법은 다음과 같습니다.

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

그런 다음 known_hosts를 편집하여 원래 키를 지우고 다음을 사용하여 호스트로 ssh하십시오.

ssh name@computer

새 키가 자동으로 추가됩니다. 그런 다음 두 파일을 비교하십시오. meld와 같은 프로그램은 두 파일을 비교하는 좋은 방법입니다. 그런 다음 known_hosts에 두 키가 모두 포함되도록 파일을 병합하십시오.

두 개의 키를 유지하는 이유는 대상 시스템이 멀티 부팅이라는 것입니다. 설치간에 키를 동기화하는 방법이 있다고해도 감히 여러 키를 허용하는 것이 더 쉬운 것 같습니다.

2015/06 수정

나는 이제 더 간단한 방법을 발견 할 것이라고 덧붙였다. [항목을 식별 할 수있는 한, 일반적으로 특정 위치를 참조하는 오류 메시지와는 별도로 호스트 이름 / IP 주소에서];

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

HostKeyAlias ​​옵션도 있습니다.

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

그런 다음 ssh 클라이언트가 별칭 아래에 새 키를 추가 한 후 known_hosts를 편집하여 별칭의 '실제'호스트 이름 / IP 주소를 별칭으로 대체하거나 alias 옵션을 사용하여 해당 호스트의 해당 화신에 연결할 수 있습니다



apt-get / yum 설치 이름은 단순히 meld입니다
Mark

cp, mv, ssh 대신 cat ~ / .ssh / known_hosts.bak ~ / .ssh / known_hosts> tmp 대신 잘 작동하는 제안의 변형을 수행했습니다. mv tmp ~ / .ssh / known_hosts
피터 N 루이스

6

여러 다른 시스템 (arm 바이너리, 프로젝트, xbmc 등을 컴파일하는 데 사용되는 dev 시스템)으로 부팅하고 동일한 문제가 발생하는 라즈베리 파이와 동일한 문제가 있습니다. 그들은 로컬 네트워크에서 DHCP를 사용하며 MAC 주소가 같기 때문에 라우터가 항상 동일한 IP를 재사용했습니다. 호스트 파일에 다른 도메인 이름을 사용하여 해결했습니다.

10.10.10.110 pi-dev
10.10.10.110 pi-xbmc
10.10.10.110 pi-etc

known_hosts 파일은 동일한 IP 주소 인 경우에도 호스트 이름별로 지문을 저장하므로 각 고유 한 호스트 이름은 다른 항목을 갖습니다.

새 시스템을 사용할 때마다 호스트 파일에 이름을 추가하는 데 어려움을 겪어 ip 주소에서 앞에 0을 사용하여 더 게으른 방법을 찾았습니다.

$ ssh pi@10.10.10.110
$ ssh pi@010.10.10.110
$ ssh pi@10.010.10.110

(정규화되지 않은) ip 주소의 각 변형은 known_hosts에 자체 항목을 가져옵니다.


1
OpenSSH 사람들은 나에게 현명 해졌습니다.이 허점은 더 이상 최신 버전에서는 작동하지 않습니다.
Mike

허점을 계속 사용할 수 있도록 CheckHostIP noin ~/.ssh/config을 사용할 수 있습니다 . 별명을 /etc/hosts정의 CheckHostIP no하여이 3 개의 호스트 이름 만 사용 하거나 정의 할 필요가 없습니다 .
GnP

3

클라이언트와 서버 모두 OpenSSH 6.8 이상을 사용하는 경우 또는 의 UpdateHostKeys yes옵션을 사용할 수 있습니다 . 예를 들면 다음과 같습니다.ssh_config~/.ssh/config

Host *
    UpdateHostKeys yes

이것은 SSH가 서버가 가지고있는 모든 호스트 키를 저장하도록하며, 서버가 known_hosts하나의 호스트 키를 변경하거나 제거 할 때 키도 변경되거나 제거됩니다 known_hosts.


이것은 가장 유용한 답변입니다! 호스트 키가 이미 변경된 경우 원래 질문을 해결하는 방법을 명시 적으로 제공하지는 않지만 다른 모든 답변은 새 호스트 키를 확인하지 않으므로 안전하지 않습니다. 이 옵션을 사용하면 새 호스트 키로 안전하게 롤오버 할 수 있습니다.
Jaap Eldering

1

두 개의 키로 작업하려는 이유를 모르겠지만 ~/.ssh/known_hosts파일에 유효한 키를 두 개 이상 추가 할 수 는 있지만 수동으로 수행해야합니다.

다른 해결책은 StrictHostKeyChecking=no이 특정 호스트에 대한 옵션 을 사용하는 것입니다.

ssh -o StrictHostKeyChecking=no user@host

당신 ~/.profile이나 비슷한 것에 별명을 넣을 수 있습니다.

alias hc=ssh -o StrictHostKeyChecking=no user@host

이 경우 StrictHostKeyChecking이 도움이되지 않는 것 같습니다. 호스트가 known_hosts 파일에없는 경우에만 동작을 지정합니다. 여기에 언급 : gossamer-threads.com/lists/openssh/dev/45349#45349
Samuel Edwin Ward

여기에서 작동합니다. 경고 메시지가 표시되지만 로그인은 계속됩니다.
Sven

이상하다. 비밀번호 인증을 사용하고 있습니까? OpenSSH를 사용하고 있습니까?
Samuel Edwin Ward

1

로컬 네트워크 로만 ssh 하면 ...

간단한 해결책은 이전 키 파일을 지우고 빈 키 파일로 바꾸는 것입니다. 이렇게하면 새 키로 모든 연결을 다시 인증 할 수 있습니다. 로컬 네트워크 외부의 사이트에 대해 ssh 키가 저장되어 있으면 해당 서버에 처음 연결할 때와 같이 초기 연결이 안전한지 확인해야합니다.

예 :

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

그런 다음 스페이스, 백 스페이스 cntl + x 및 'y'를 눌러 새 버퍼 (파일)를 저장하십시오. 나쁜 습관이지만 로컬 네트워크 외부에 정기적으로 ssh하지 않는 것이 좋습니다 (예 : uni 또는 work server)

안전한 로컬 네트워크에서는 중간 공격으로 사람을 구할 수 없기 때문에 안전합니다.

항상 이해하는 코드를 사용하는 것이 좋습니다!


4
known_hosts매번 전체 파일을 지우면 ssh가 제공하지 않는 대부분의 보안이 무효화됩니다.
kasperd

실제로 안전한 내부 네트워크에서는 코드를 무의식적으로 복사하는 것보다 코드를 이해하고 보안을 우회하는 것이 더 안전하다고 주장합니다. 외부 네트워크에서는 상황이 다를 수 있습니다.
Aaron

-1

엄청나게 많은 답변이 있지만 엄격한 호스트 검사를 완전히 해제하거나 관련이없는 호스트 정보를 파괴하거나 사용자가 키를 대화식으로 받아 들일 수있게함으로써 예상치 못한 시점에 보호를 포기하는 경우가 많습니다.

다음은 엄격한 호스트 확인을 유지하면서 변경 이 예상되는 경우 제어 된 방식으로 키를 업데이트 할 수있는 간단한 기술입니다 .

  • 이전 키를 제거하고 하나의 명령으로 업데이트

    ssh-keygen -R server.example.com && \
        ssh -o StrictHostKeyChecking=no server.example.com echo SSH host key updated.
    
  • 사용하는 경우 IP 주소 또는 다른 호스트 이름으로 반복하십시오.

이 방법의 장점은 서버를 정확히 한 번만 다시 키울 수 있다는 것입니다. 삭제하려는 서버가 알려진 호스트 파일에 없으면 대부분의 ssh-keygen 버전에서 오류를 반환하지 않는 것 같습니다. 이것이 문제인 경우 두 명령을 순서대로 사용하십시오.

이 방법은 또한 연결성을 확인하고 ssh 명령 (로그인, 호스트 키 업데이트, 업데이트 된 SSH 호스트 키 출력 후 즉시 종료) 에서 로그에 대한 멋진 메시지를 생성 합니다.

ssh-keygen 버전이 0이 아닌 종료 코드를 리턴하고 이전 연결에 상관없이 오류없이이를 처리하려면 ssh-keygen 명령의 오류를 무시하고 두 명령을 순서대로 사용하십시오.

이 기술을 사용하는 경우 ssh 명령을 변경하거나 해당 ssh 명령 중 하나를 제외하고 호스트 검사를 해제 할 필요가 없습니다. 위의 ssh 명령이 오류없이 실행되는 한, 향후 ssh 세션이 충돌없이 작동하거나 새 키를 명시 적으로 승인 할 필요가 있음을 확신 할 수 있습니다.


-3

나는 같은 문제가 있었다.

내가 한 것은 sudo nano /home/user/.ssh/ host_allow열쇠를 지우고 지 웠습니다.

서버로 돌아 가면 새 키가 추가되었습니다.


2
왜 이런 일이 발생했는지에 대한 정보가 도움이 될 것입니다.
Drew Khoury

-4

sed 명령을 사용하여 문제를 일으키는 행을 제거하십시오.

OUTPUT: as show in above example
Offending key in /home/user/.ssh/known_hosts:86

알려진 호스트에서 언급 한대로 86 행을 제거하십시오.

CODE: 
sed -i '86d' /home/user/.ssh/known_hosts

다음에 ssh를 사용하여 액세스하면 시스템이 자동으로 새 키를 추가합니다.

최신 버전의 ssh

사용하다:

ssh-keygen -R <hostname|ip address>

호스트 이름 항목을 제거하고 다음과 .known_host같이 오래된 백업을 수행합니다.known_hosts.old


4
"하지만 내가 원하는 것은 ssh가 이전 키와 새 키를 모두 수락하도록하는 것입니다." 당신의 대답은 이것을하지 않습니다.
Samuel Edwin Ward
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.