2013-02-01 20 views
10

Staramy się usprawnić automatyzację niektórych procesów serwera; używamy Fabric. Przewiduję, że będę musiał zarządzać wieloma hostami, a to oznacza, że ​​połączenia SSH muszą być wykonywane na serwerach, które wcześniej nie były używane przez SSH. Jeśli tak się stanie, SSH zawsze prosi o weryfikację połączenia, które przerwie automatyzację.Jak przekazywać opcje SSH za pomocą Fabric?

Pracowałem nad tym problemem, w tym samym procesie, używając opcji -o stricthostkeychecking=no dla polecenia SSH, którego używam do synchronizowania kodu z rsync, ale będę również musiał użyć go podczas połączeń z siecią Fabric.

Czy istnieje sposób przekazywania specyficznych dla ssh opcji Fabric, w szczególności tej, którą wymieniłem powyżej?

Odpowiedz

8

Odpowiedź jest krótka:

  1. Dla nowych gospodarzy, nic nie jest potrzebne. env.reject_unknown_hosts domyślnie False
  2. Dla znanych hostów ze zmienionymi kluczami, env.disable_known_hosts = True zdecyduje się kontynuować łączenie ze zmienionymi hostami.

Czytaj Ye Olde docs: http://docs.fabfile.org/en/1.5/usage/ssh.html#unknown-hosts

Biblioteka paramiko jest w stanie ładowania zapasową pliku known_hosts, a następnie porównać dowolny host to łączy się z tym mapowaniem. Ustawienia są dostępne w celu ustalenia, co się dzieje, gdy nieznany host (host, którego nazwa lub IP nie znajduje się w known_hosts) jest widziany:

  • Odrzuć: klucz hosta jest odrzucane, a połączenie nie zostanie dokonane . Powoduje to wyjątek Python, który zakończy sesję Fabric z komunikatem, że host jest nieznany.
  • Dodaj: nowy klucz hosta zostanie dodany do listy znanych hostów w pamięci, połączenie zostanie nawiązane, a wszystko będzie działać normalnie. Zauważ, że to nie modyfikuje twojego znanego pliku hosts_hosts!
  • Zapytaj: jeszcze nie zaimplementowano na poziomie Fabric, jest to opcja biblioteki paramiko, która powodowałaby, że użytkownik był pytany o nieznany klucz i czy go zaakceptować.

czy odrzucić lub dodaj hosty jak wyżej, jest regulowana w Fabric poprzez opcję env.reject_unknown_hosts, co jest fałszywe domyślnie dla dobra na wygodę. Uważamy, że jest to ważna kompromis między wygodą i bezpieczeństwem w zakresie ; każdy, kto czuje, że jest inaczej, może łatwo modyfikować swoje pliki fabfiles na poziomie modułu, aby ustawić env.reject_unknown_hosts = True.

http://docs.fabfile.org/en/1.5/usage/ssh.html#known-hosts-with-changed-keys

Znane gospodarze z zmienionych kluczy

Punktem śledzenia klucz/papilarnych SSH jest tak, że można wykryć ataki typu man-in-the-middle: Jeśli przekierowań atakująca Twój ruch SSH na komputer pod jego kontrolą i udaje, że jest to oryginalny serwer docelowy, a klucze hosta nie są zgodne.Tak więc domyślne zachowanie SSH (i jego implementacja w języku Python) to natychmiast przerwać połączenie, gdy host poprzednio zarejestrowany w known_hosts nagle zaczyna wysyłać nam inny klucz hosta.

W niektórych skrajnych przypadkach, takich jak niektóre wdrożenia EC2, możesz chcieć zignorować ten potencjalny problem. Nasza warstwa SSH, w momencie pisania, nie daje nam kontroli nad tym dokładnym zachowaniem, ale możemy pominąć , po prostu pomijając ładowanie znanych_hostów - jeśli lista hostów jest porównywana z pustą, wtedy nie ma problem. Ustaw env.disable_known_hosts na True, jeśli chcesz tego zachowania; domyślnie jest to False , aby zachować domyślne zachowanie SSH.

Ostrzeżenie Włączenie opcji env.disable_known_hosts pozostawi cię szeroko otwartymi na ataków man-in-the-middle! Należy zachować ostrożność.

+0

Doskonale, dziękuję bardzo! –

Powiązane problemy