SSH의 known_hosts에 호스트 키를 추가하지 마십시오

111

SSH를 통해 호스트에 연결하고 싶지만 호스트 이름을 my에 추가하고 싶지 않습니다 ~/.ssh/known_hosts.

어떻게해야합니까?

ssh hosts

— 앨버트
소스

99

-o "UserKnownHostsFile /dev/null"

작동해야합니다.

— 앨버트
소스

3

의도 한대로 작동하지만 항상 다음과 같이보고합니다. "경고 : 알려진 호스트 목록에 'hostname, ip'(RSA)를 영구적으로 추가했습니다." 나는 그것을 멀리 가버 렸다 : 2> & 1 | grep -v "^Warning: Permanently added"

— 기 illa 부데요 우

3

-o "LogLevel ERROR"를 추가하면 더 이상 경고 메시지가 표시되지 않습니다.

— John

1

참고 : "경고 : 알려진 호스트 목록에 'hostname, ip'(RSA)를 영구적으로 추가했습니다." 메인테이너에보고 된 bugzilla.mindrot.org/show_bug.cgi?id=2413

— 벤 크리시

2

배관 grep은 stdout과 stderr을 병합합니다. 또한 종료 상태가 변경 될 수 있습니다. 사용하는 경우 bash,이 메시지를 없애 공정 대체를 사용하는 것이 더 좋을 것입니다 ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]. 파이프와 출구 상태 처리의 해당 변경을 피합니다.

— Alex O

1

@John이 의견에 다른 방법 중 하나를 사용하는 것이 좋습니다. 그렇지 않으면 관련이없는 다른 경고를 숨길 가능성으로 인해 보안 결함이 발생합니다

— Jon Bentley

97

클라우드 서버 (AWS EC2, Rackspace CloudServers 등)로 작업 중이거나 Vagrant에서 지속적으로 새 이미지를 프로비저닝하고 있기 때문에이 동작을 원할 경우 bash 별칭이나 옵션을 추가하는 대신 SSH 구성을 업데이트 할 수 있습니다 명령 줄.

다음과 같은 것을 추가하십시오 :

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET

호스트의 정규식을 최대한 엄격하게 사용하여 보안을 유지하십시오.
LogLevel을 QUIET으로 설정하면 기 illa이 언급 한 경고가 나타나지 않습니다.

— 클락
소스

실제로 StrictHostKeyChecking을 완전히 비활성화하지 않아야하므로 cclark의 대답은 클라우드 서버 작업에 큰 타협입니다.

— Alex Recarey

Vagrant에 대해 Shipit (JavaScript 배포 도구)을 사용할 때 이것은 매우 도움이되었습니다. Shipit이 SSH로 전달하는 매개 변수를 쉽게 얻을 수 없었기 때문에 도구를 회피하고 내가 한 일과 기억하지 않는 것을 말할 수있었습니다.

— John Munsch

1

LogLevel은 내가 찾고있는 것입니다. 스크립트를 실행할 때 회사에서 구성한 알림을 표시하지 않는 이점이 있습니다! (나는 지금 로그 레벨 오류로 실행 중입니다)

— Anshu Prateek

어떤 파일에 이것을 추가합니까?

— Wim Deblauwe

이것은 SSH 구성 파일입니다. Linux 또는 macOS에서 파일은 일반적으로 홈 디렉토리 내의 .ssh 디렉토리에 있고 이름은 config-~ / .ssh / config

— cclark

8

나는 known_hosts에 호스트 키를 추가하고 (이 서비스를 실행하는 사람들은 적어도 동일한 호스트 이름을 제공하는 컴퓨터간에 호스트 키를 일관되게 유지할만큼 똑똑합니다) StrictHostKeyChecking을 켜고 CheckHostIP를 끄고, LogLevel ERROR로 로깅하면 보안을 유지하면서 최상의 경험을 얻을 수 있습니다. (OKHostIP가 없으면 DNS를 신뢰할 필요가 있습니다. 이는 DNSSEC 또는 이와 유사한 것이없는 거대한 격차 구멍입니다. 그러나 우리는 당장 그 양탄자 아래에서 그것을 쓸어 버릴 것입니다.)

읽기 전용 known_hosts 파일을 사용하므로 무언가를 수행해야하거나 known_hosts에 항목을 추가 할 수 없다는 경고가 계속 표시됩니다.

내가 사용하는 것 :

Host github.com *.github.com
StrictHostKeyChecking yes
CheckHostIP no
LogLevel ERROR

이 서비스가 HTTPS를 통해 웹 사이트에 SSH 호스트 키를 게시하기를 원하므로 먼저 연결하지 않고 명시 적으로 복사하여 MITM 공격에 노출 될 수 있습니다.

— 카일 로즈
소스

7

단일 ssh 세션의 경우 다음을 사용하십시오.

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host

— Quanlong
소스

4

이것은 5 살짜리 질문에 대한 답에 새로운 것을 추가하지 않습니다.

— JakeGould

5

나는 제안한다

LogLevel ERROR

위에

LogLevel QUIET

여전히 "호스트 이름을 확인할 수 없습니다"및 기타 오류가 표시됩니다.

— 킬로 포스
소스

SSH 연결을 신뢰할 수 있어야합니다 (imho). 단지 당신의 위험에 대해 침묵하지 마십시오.

— sylvainulg

3

정말 다릅니다. 우리는 매주 찢어지고 재 구축되는 개발 환경을 가지고 있으며 A 레코드는 동일하게 유지되지만 호스트 키는 생성 될 때마다 생성됩니다. A 레코드는 환경 이름을 기준으로 데이터베이스에 정의되어 있고 환경 이름은 언제라도 폐기되거나 새 이름이 만들어 질 수 있으므로 호스트 키를 유지할 수 없으므로 위의 해결 방법이 정말 유용합니다.

— Alex Berry

2

비활성화하려고 했습니까 StrictHostKeyChecking? -o옵션 또는 구성 파일을 사용하여 수행 할 수 있습니다 ~/.ssh/config.

— jneves
소스

나는 이미 그것을 사용하고 있습니다. 그러나 다른 효과가 있습니다. 호스트 키 검사의 엄격 성을 줄입니다. 즉, 호스트를 알 수없는 경우 해당 옵션을 비활성화해도 여전히 연결됩니다. 따라서 여전히 호스트를 저장합니다. 그러나 올바른 해결책을 찾았습니다 (내 대답 참조).

— Albert

0

다음 .ssh / config 항목이 유용한 것으로 나타났습니다 (DHCP 및 DNS가있는 LAN).

 CheckHostIP no

 Host *.*
 CheckHostIP yes

결과 로컬 시스템 이름 "zora"또는 "goron"은 동적으로 할당 된 IP 주소를 확인하지 않지만 www.mycompany.com 또는 node42.planetlab.com은 여전히 정적 IP를 확인합니다.

— 실바 인
소스