Płynniejszy przepływ pracy w celu obsługi błędów weryfikacji hosta SSH?

Jest to prosty problem, z którym wszyscy się spotykamy i prawdopodobnie rozwiązujemy go ręcznie bez zastanowienia.

Gdy serwery się zmieniają, są ponownie przydzielane lub adresy IP są ponownie przydzielane, otrzymujemy poniżej komunikat weryfikacyjny hosta SSH. Jestem zainteresowany usprawnieniem przepływu pracy w celu rozwiązania tych błędów identyfikacji ssh.

Biorąc pod uwagę następujący komunikat, zazwyczaj vi /root/.ssh/known_hosts +434usuwam ( dd) linię naruszającą.

Widziałem, że programiści / użytkownicy innych organizacji usuwają cały swój known_hostsplik z frustracji widząc tę ​​wiadomość. Chociaż nie posuwam się tak daleko, wiem, że istnieje bardziej elegancki sposób, aby sobie z tym poradzić.

Napiwki?

[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.

Możesz użyć ssh-keygenpolecenia, aby usunąć określone wpisy według hosta:

ssh-keygen -R las-db1

Jeśli nie masz tego polecenia, zawsze możesz użyć sed:

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

Jako użytkownik marionetki moją metodą rozwiązania tego problemu jest fakt, że mój serwer marionetek zbiera klucze hosta SSH i publikuje je we wszystkich moich systemach, które wykonują połączenia SSH.

W ten sposób nie muszę się martwić o ich usunięcie. Dziewięćdziesiąt dziewięć procent czasu, w którym marionetka biegała i aktualizowała mi klucze, ponieważ mam agentów działających co trzydzieści minut. Wyjątki są dla mnie bardzo rzadkie, więc nie mam nic przeciwko szybkiej edycji znanych hostów w całym systemie, jeśli nie chcę czekać.

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,
  }

}

Chciałbym dodać sugestię, która może pomóc w bardzo szczególnych przypadkach, w których bezpieczeństwo ma mniejsze znaczenie.

Mam środowisko laboratoryjne z często instalowanymi maszynami. Za każdym razem, gdy to się dzieje, generowane są nowe klucze hosta (prawdopodobnie mógłbym gdzieś zapisać klucz hosta i ustawić go w skrypcie poinstalacyjnym).

Ponieważ bezpieczeństwo nie stanowi dla mnie problemu w tym środowisku laboratoryjnym, a klucze zmieniają się tak często, w pliku .ssh / config mam następujące elementy:

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

Zapewnia to, że połączenie z moimi komputerami laboratoryjnymi nigdy więcej nie spowoduje tego błędu, a mój klient ssh po prostu połączy się bez sprawdzania klucza hosta.

Jest to coś, co powinieneś zrobić tylko wtedy, gdy bezpieczeństwo nie ma dla ciebie żadnego znaczenia, ponieważ stawia cię to w trudnej sytuacji do ataku typu man-in-the-middle.

Zgodnie z informacją o wersji openssh 5.6 nie musisz już używać kluczy hostów:

Uwierzytelnianie oparte na hoście może teraz używać kluczy hosta certyfikatu. Klucze urzędu certyfikacji muszą zostać określone w pliku znanego_hosta przy użyciu znacznika @ cert-Authority zgodnie z opisem w sshd (8).

Ostrzeżenie : jak dotąd nie słyszałem o nikim, kto używałby tej funkcji w produkcji. Używaj na własne ryzyko (ale uważam, że programiści openssh są wystarczająco paranoiczni, aby nie wypuszczać takiej zabójczej funkcji bez wielu testów i audytu kodu).

SSHFP DNS ResourceRecord może pomóc w zależności od tego, ile twój klient ssh z niego korzysta. Przechowuj tam wszystkie odciski palców kluczy publicznych ssh wraz z nazwą hosta.

Wcześniej należy zaimplementować DNSSEC lub DNS przez SSL.
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org obsługuje zarządzanie kluczami hosta i użytkownika, a także certyfikaty PKI. Automatycznie przesyła również rekordy DNS SSHFP po utworzeniu nowych kluczy.

Demon usług bezpieczeństwa systemu (SSSD) można skonfigurować do buforowania i pobierania kluczy SSH hosta, dzięki czemu aplikacje i usługi muszą szukać kluczy hosta tylko w jednym miejscu. Ponieważ SSSD może wykorzystywać FreeIPA jako jednego z dostawców informacji o tożsamości, FreeIPA zapewnia uniwersalne i scentralizowane repozytorium kluczy. Administratorzy nie muszą się martwić dystrybucją, aktualizacją lub weryfikacją kluczy SSH hosta.

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