Nie dodawaj klucza hosta do znanych hostów dla SSH

111

Chcę połączyć się z hostem za pośrednictwem SSH, ale nie chcę, aby nazwa hosta była dodawana do mojego ~/.ssh/known_hosts.

Jak mogę to zrobić?

ssh hosts

— Albert
źródło

99

-o "UserKnownHostsFile /dev/null"

powinno działać.

— Albert
źródło

3

Działa zgodnie z przeznaczeniem, ale zawsze zgłasza: „Ostrzeżenie: na stałe dodano„ nazwę hosta, ip ”(RSA) do listy znanych hostów”. Zrobiłem to odejść z: 2> i 1 | grep -v "^Warning: Permanently added"

— Guillaume Boudreau

3

dodaj -o „LogLevel ERROR” i nie będzie już narzekał na Ostrzeżenia

— John,

1

Uwaga: prośba o ukrycie tego komunikatu „Ostrzeżenie: na stałe dodano„ nazwę hosta, ip ”(RSA) do listy znanych hostów.” został zgłoszony do opiekunów bugzilla.mindrot.org/show_bug.cgi?id=2413

— Ben Creasy

2

Rurowanie do greppołączy stdout i stderr; także status wyjścia może ulec zmianie. Jeśli używasz bash, to będzie lepiej użyć podstawienia procesowego, aby pozbyć się komunikatu: ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]. Pozwoli to uniknąć potoku, a tym samym odpowiednich zmian w obsłudze statusu wyjścia.

— Alex O

1

@John W tych komentarzach lepiej jest użyć jednej z pozostałych metod, w przeciwnym razie wprowadzasz lukę w zabezpieczeniach ze względu na możliwość ukrycia innych, niepowiązanych ostrzeżeń

— Jon Bentley

97

Jeśli chcesz tego zachowania, ponieważ pracujesz z serwerami w chmurze (AWS EC2, Rackspace CloudServers itp.) Lub stale udostępniasz nowe obrazy w Vagrant, możesz chcieć zaktualizować konfigurację SSH zamiast dodawać aliasy bash lub więcej opcji na wiersz poleceń.

Rozważ dodanie czegoś takiego:

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

Używaj tak restrykcyjnych wyrażeń regularnych dla hosta, jak to możliwe, aby być bezpiecznym.
Ustawienie LogLevel na CICHY spowoduje, że Ostrzeżenie, o którym wspomniał Guillaume, nie będzie się wyświetlać

— Cclark
źródło

Naprawdę powinieneś spróbować nie w pełni wyłączać StrictHostKeyChecking, więc odpowiedź cclark jest świetnym kompromisem do pracy z serwerami w chmurze.

— Alex Recarey

Okazało się to bardzo pomocne, gdy korzystałem z Shipit (narzędzie do wdrażania JavaScript) przeciwko Vagrant. Nie mogłem łatwo odczytać parametrów, które Shipit przekazywał do SSH, więc to pozwoliło mi ominąć narzędzie i powiedzieć mu, co zrobiłem, i nie chciałem, żeby to zapamiętało.

— John Munsch,

1

LogLevel jest tym, czego szukałem. Ma tę dodatkową zaletę, że nie wyświetla powiadomienia skonfigurowanego przez firmę podczas uruchamiania skryptów! (Pracuję teraz z

— błędem loglevel

W jakim pliku mam to dodać?

— Wim Deblauwe

To jest twój plik konfiguracyjny SSH. W systemie Linux lub macOS plik zwykle znajduje się w katalogu o nazwie .ssh w katalogu domowym i nosi nazwę config - ~ / .ssh / config

— cclark

8

Mam ochotę dodać klucz hosta do znanych hostów (według mnie ludzie prowadzący te usługi są przynajmniej wystarczająco inteligentni, aby zachować spójność kluczy hostów między komputerami obsługującymi tę samą nazwę hosta), a następnie włączyć StrictHostKeyChecking, wyłączyć CheckHostIP i logowanie za pomocą LogLevel ERROR zapewni najlepsze wrażenia bez uszczerbku dla bezpieczeństwa. (Ok, bez CheckHostIP musisz zaufać DNS, który jest ogromną luką bez szeroko rozpowszechnionego DNSSEC lub czegoś podobnego; ale na razie zamiatamy to pod dywan).

Korzystam z pliku znanego hosta tylko do odczytu, więc muszę coś zrobić lub otrzymuję niekończące się ostrzeżenia o niemożności dodawania wpisów do znanych hostów.

Czego używam:

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

Chciałbym, aby te usługi publikowały klucze hostów SSH na swoich stronach internetowych za pośrednictwem HTTPS, dzięki czemu mogę je jawnie skopiować bez konieczności łączenia się i potencjalnie narażając się na atak MITM.

— Kyle Rose
źródło

7

W przypadku pojedynczej sesji ssh użyj tego

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

— Quanlong
źródło

4

Nie dodaje to nic nowego do zaakceptowanej odpowiedzi na pytanie, które ma 5 lat.

— JakeGould

5

sugeruję

LogLevel ERROR

koniec

LogLevel QUIET

więc nadal pojawia się komunikat „Nie można rozwiązać nazwy hosta” i inne podobne błędy

— kiloforce
źródło

powinieneś być w stanie zaufać swoim połączeniom SSH, imho. Nie tylko cicho mów o swoich zagrożeniach.

— sylvainulg

3

Zależy naprawdę. Mamy środowiska programistyczne, które są burzone i przebudowywane co tydzień, ich rekordy A pozostają takie same, ale klucz hosta jest generowany za każdym razem, gdy jest budowany. Nie możemy utrwalić kluczy hosta, ponieważ rekord A jest po prostu zdefiniowany w bazie danych na podstawie nazwy środowiska, a nazwy środowiska można w dowolnym momencie usunąć lub utworzyć nowe, więc powyższe obejście jest naprawdę przydatne.

— Alex Berry

2

Czy próbowałeś wyłączyć StrictHostKeyChecking? Możesz to zrobić za pomocą -oopcji lub w pliku konfiguracyjnym ~/.ssh/config.

— jneves
źródło

Już tego używam. Ale ma inny efekt: obniża rygor sprawdzania klucza hosta. To znaczy, gdy host jest nieznany, nadal łączy się, gdy wyłączysz tę opcję. W ten sposób nadal oszczędza hosta. Ale myślę, że znalazłem właściwe rozwiązanie (patrz moja odpowiedź).

— Albert

0

Przydatne okazały się następujące wpisy .ssh / config (LAN z DHCP i DNS):

 CheckHostIP no

 Host *.*
 CheckHostIP yes

Rezultatem jest to, że lokalne nazwy komputerów „zora” lub „goron” nie sprawdzą dynamicznie przypisanych adresów IP, ale www.mycompany.com lub node42.planetlab.com nadal będą potwierdzać swoje statyczne adresy IP.

— sylvainulg
źródło