SSH 호스트 확인 오류를 처리하는 가장 부드러운 워크 플로우?

41

이것은 우리 모두가 직면하고 많은 생각을하지 않고 수동으로 해결할 수있는 간단한 문제입니다.

서버가 변경되거나 재 프로비저닝되거나 IP 주소가 재 할당되면 아래의 SSH 호스트 확인 메시지가 나타납니다. 이러한 ssh 식별 오류를 해결하기 위해 워크 플로를 간소화하고 싶습니다.

다음과 같은 메시지가 표시되면 일반적으로 문제의 행을 vi /root/.ssh/known_hosts +434제거합니다 ( dd).

다른 조직의 개발자 / 사용자 가이 메시지를 볼 때 좌절에서 전체 known_hosts 파일을 삭제하는 것을 보았습니다. 나는 멀리 가지 않지만이를 처리하는 더 우아한 방법이 있다는 것을 알고 있습니다.

팁?

[root@xt ~]# ssh las-db1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.

— ewwhite
소스

우리도 같은 문제가 있습니다. NASA의 메쉬 ti.arc.nasa.gov/opensource/projects/mesh에 대한 경험이 없지만 검토 할 기술 목록에 있습니다.

— Andrew Gilmartin

1

서버를 다시 설치 / 재 할당 할 때 이전 키를 복사하지 않는 이유는 무엇입니까?

— Random832

@ Random832 서버가 많거나 IP 주소를 자주 재활용하는 랩 / 테스트 환경 인 경우에는 확장 할 수 없습니다. 또는 다른 경우; 원래 서버를 사용할 수없는 계획되지 않은 서버 교체 ...

— ewwhite

3

내가 가진 큰 질문은 :이 상황에 어떻게 들어가는가? 호스트 이름을 재사용하는 경우 호스트 이름 지정 표준 ( tools.ietf.org/html/rfc1178 ) 을 다시 고려할 수 있습니다. IP 주소를 재사용하는 경우 해당 IP 주소에서 이전 서버를 해제하는 것과 동일한 절차의 일부로 ssh 키를 해제해야합니다. IP 재사용이 자동으로 발생하고 반의도없는 호스트 이름이 필수 인 "웹 스케일"환경에서 작업하는 경우 ssh 키를 수정하면 충분히 자동화 된 서버 수명주기 프로세스를 갖추어야합니다.

— Paul Gear

47

이 ssh-keygen명령을 사용하여 호스트별로 특정 항목을 제거 할 수 있습니다 .

ssh-keygen -R las-db1

해당 명령이 없으면 항상 sed를 사용할 수 있습니다.

sed -i '/las-db1/d' /root/.ssh/known_hosts

— 카일 브란트
소스

3

충돌하는 키 문제를 해결하기 위해 ssh-keygen -R을 사용하는 것도 우분투의 ssh 클라이언트가이 문제가 발생할 때 오류 메시지에서 제안하는 것입니다.

— Kenny Rasschaert 21

나는 그 ssh-keygen명령 으로의 전환을 몰랐다 . 좋은!

— ewwhite

10

누군가 "실제로 불쾌한 일을하고 있지"않은지 확인하고 확인하십시오.

— Michael Hampton

1

회의에서이 작업을 수행하지 마십시오!

— Paul Gear

2

@ewwhite /etc/ssh/known_hosts네트워크 에서 파일을 적절한 호스트 키 (퍼펫 등으로 관리)로 채우거나 개인 ~ / .ssh / known_hosts 파일을 채 웁니다 (이 중 하나를 수행하려면 ssh-keyscan알려진 양호 / 보안을 실행할 수 있습니다) 연결). 이 없다면 (당신이 보안에 대해 전혀하지 신경 가정) 세트 UserKnownHostsFile=/dev/null와 StrictHostKeyChecking=no당신에 ~/.ssh/config file(SSH에 옵션 또는 통과 -o)

— voretaq7

25

꼭두각시 사용자로서 이것을 해결하는 방법은 실제로 꼭두각시 서버가 SSH 호스트 키를 수집하여 SSH 연결을 만드는 모든 시스템에 게시하는 것입니다.

이 방법으로 제거에 대해 걱정할 필요가 없습니다. 30 분마다 에이전트가 실행되므로 꼭두각시가 실행 된 시간의 90 %가 키를 업데이트하고 업데이트했습니다. 나에게 대한 예외는 매우 드물기 때문에 기다릴 생각이 없다면 시스템 전체 known_hosts를 빠르게 편집하지 않아도됩니다.

class ssh::hostkeys {

  @@sshkey { "${::clientcert}_rsa":
    type => rsa,
    key => $sshrsakey,
    tag => 'rsa_key',
  }

  if 'true' == $common::params::sshclient {
    Sshkey <<| tag == 'rsa_key' |>> {
      ensure => present
    }
  }

  file {'/etc/ssh/ssh_known_hosts':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => 0644,
  }

}

— 조 레다 슈
소스

+1 구성 관리 도구를 통합하는 데 도움이됩니다.

— ewwhite

4

보안이 중요하지 않은 매우 구체적인 경우에 도움이되는 제안을 추가하고 싶습니다.

자주 다시 설치되는 컴퓨터가있는 랩 환경이 있습니다. 매번 새로운 호스트 키가 생성됩니다 (어쩌면 호스트 키를 어딘가에 저장하고 설치 후 스크립트에서 설정할 수 있습니다).

이 랩 환경에서는 보안이 문제가되지 않으며 키가 자주 변경되므로 .ssh / config 파일에 다음이 있습니다.

Host lab-*
  User kenny
  IdentityFile ~/.ssh/lab_id_rsa
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

이를 통해 실험실 컴퓨터에 연결해도 오류가 다시 발생하지 않으며 호스트 키를 확인하지 않고 ssh 클라이언트가 연결됩니다.

보안이 전혀 중요하지 않은 경우에만해야 할 일입니다. 중간자 공격에 취약한 위치에 있기 때문입니다.

— 케니 라샤 르트
소스

1

위험 해 보인다. 이 중 일부는 공개 시스템이므로 호스트 확인을 유지하고 싶습니다.

— ewwhite

1

이것이이 방법이 "보안이 덜 중요하거나 걱정되지 않는"경우에만 해당된다고 언급 한 이유입니다. 개인 네트워크 / 실험실 환경은이 구성에 적합합니다. 다중 머신 자동 스케일링 생산 / 공개 직면 시스템.

— dannosaur

4

openssh 5.6 릴리스 정보 에 따르면 더 이상 호스트 키를 사용할 필요가 없습니다.

호스트 기반 인증은 이제 인증서 호스트 키를 사용할 수 있습니다. CA 키는 sshd (8)에 설명 된대로 @ cert-authority 마커를 사용하여 known_hosts 파일에 지정해야합니다.

경고 : 지금까지 프로덕션에서이 기능을 사용하는 사람은 들어 본 적이 없습니다. 자신의 위험 부담으로 사용하십시오 (그러나 Opensh 개발자는 많은 테스트 및 코드 감사없이 그러한 킬러 기능을 릴리스하지 않을 정도로 편집증 적이라고 생각합니다).

2

SSHFP DNS ResourceRecord는 ssh 클라이언트가 활용하는 정도에 따라 도움이 될 수 있습니다. 호스트 이름으로 모든 ssh 공개 키 지문을 저장하십시오.

미리 DNSSEC 또는 DNS over SSL을 구현하십시오.
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org는 호스트 및 사용자 키 관리는 물론 PKI 인증서를 처리합니다. 또한 새 키가 생성 될 때 SSHFP DNS 레코드를 자동으로 업로드합니다.

SSSD (System Security Services Daemon)는 호스트 SSH 키를 캐시하고 검색하도록 구성 할 수 있으므로 응용 프로그램 및 서비스는 한 위치에서만 호스트 키를 찾아야합니다. SSSD는 ID 정보 제공자 중 하나로 FreeIPA를 사용할 수 있으므로 FreeIPA는 범용 중앙 집중식 키 저장소를 제공합니다. 관리자는 호스트 SSH 키 배포, 업데이트 또는 확인에 대해 걱정할 필요가 없습니다.

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html

— rjt
소스