Czy naprawdę bezpieczne jest połączenie z serwerem przez SSH z hoteli podczas podróży?

Czy połączenie z serwerem korzystającym z SSH z hoteli podczas podróży jest naprawdę bezpieczne?

Serwer :
- CentOS 7
- Autoryzacja tylko za pomocą klucza RSA - Odmowa autoryzacji hasła
- Niestandardowy port

Stacja robocza :
- Ubuntu 14
- hasło użytkownika
- hasło do użycia klucza RSA (metoda standardowa)

Może dobrym pomysłem będzie przechowywanie połowy prywatnego klucza RSA na pamięci USB i automatyczne (według skryptu) dodanie tej połowy do ~ / .ssh / private_key przed podłączeniem?

Internet będzie przez sieć WIFI w hotelach lub kablówkę w wynajętym mieszkaniu.

UPD
Przepraszam, że na początku jestem niejasny. Mam na myśli bezpieczeństwo w dwóch aspektach:

Bezpieczeństwo tylko połączenia SSH przez niezaufaną sieć.
Bezpieczeństwo komputera z kluczem niezbędnym do połączenia SSH - jeśli zostanie skradziony, jak chronić serwer ...

security physical-security

— Siergiej Serow
źródło

Jaki pół klucza RSA? Publiczna część klucza hosta ssh? Połowa prywatnej części klucza SSH użytkownika?

— andol

połowa mojego prywatnego klucza RSA oczywiście :) i automatycznie przez skrypt, aby dodać tę połowę do ~ / .ssh / private_key przed połączeniem z serwerem.

— Sergey Serov

Jesteś już bezpieczniejszy niż większość ludzi, ponieważ używasz Linuksa. Ponieważ korzystasz z najnowszych wersji, powinieneś mieć nowe wersje OpenSSH, które obsługują silniejsze szyfrowanie. Po przejściu na tecmint.com/5-best-practices-to-secure-and-protect-ssh-server możesz grać ograniczając się do silniejszego szyfrowania, takiego jak stribika.github.io/2015/01/04/secure-secure- shell.html

— pisklęta

@ laski „bezpieczniejsze niż większość ludzi, ponieważ używasz Linuksa” to głupia rzecz do powiedzenia. SSH to SSH, niezależnie od tego, czy działa w systemie Linux, Unix (Mac) lub Windows. I moglibyśmy wskazać na wiele bardzo poważnych wad bezpieczeństwa w Linuksie w najnowszej historii (Heartbleed, ktoś?). Mówiąc tylko, zostawmy głupie wojny płomieniowe na linii bocznej tam, gdzie należą, ponieważ odwracają uwagę od rzeczywistych pytań i problemów. Dzięki! ;-)

— Craig

@ laski Chyba właśnie to starałem się przekazać. Wiele problemów związanych z bezpieczeństwem we wszystkich systemach operacyjnych, a Microsoft poczynił ogromne postępy od czasu, gdy kilka lat temu rozpoczął inicjatywę „godnego zaufania przetwarzania danych”. Po prostu myślę, że „jesteś bezpieczniejszy, ponieważ Linux” odwraca rozmowę od aktualnego problemu ( z szacunkiem); ;-)

— Craig

Odpowiedzi:

Tak więc, odnośnie nawiązania połączenia ssh przez jawnie niezaufane połączenie.

Zakładając, że masz już wpis ~ / .ssh / known_hosts z poprzedniego połączenia, tak, powinieneś być w stanie połączyć się bez obawy o to, czy sieć jest bezpieczna czy nie. To samo dotyczy sytuacji, gdy masz inne sposoby weryfikacji klucza hosta ssh.

Jeśli nigdy wcześniej nie łączyłeś się z serwerem, ani nie masz żadnego innego sposobu weryfikacji klucza hosta ssh, możesz bardziej uważać na sieć, której używasz do połączenia.

— andol
źródło

Dziękuję Ci!! Czy połączenie SSH z serwerem jest bezpieczne, nawet za pośrednictwem publicznego Wi-Fi?

— Sergey Serov

W rzeczywistości ta odpowiedź dotyczy każdej sytuacji, w której chcesz ssh do zdalnego serwera, a żadna część ścieżki nie jest pod twoją pełną kontrolą (więc praktycznie wszystko oprócz ssh-s do świeżo zainstalowanego hosta lokalnego lub za pośrednictwem kabla krzyżowego )

— Hagen von Eitzen

Warto zauważyć, że jeśli klient nie zna klucza hosta, pełny atak MITM będzie możliwy, jeśli zostanie użyte uwierzytelnianie hasłem. Ale jeśli używane jest uwierzytelnianie oparte na kluczach, osoba atakująca będzie mogła podszyć się pod serwer. Atakujący nie będzie mógł także uwierzytelnić się na prawdziwym serwerze. W takim przypadku atakującemu trudno jest przekonująco podszyć się pod serwer, dlatego możesz zauważyć, że coś jest nie tak, zanim będzie za późno. Krótko mówiąc: uwierzytelnianie za pomocą klucza publicznego jest znacznie bezpieczniejsze niż uwierzytelnianie za pomocą hasła .

— kasperd

@kasperd: Cóż, jeśli klient łączący ma włączone przekazywanie agentów, nawet uwierzytelnianie za pomocą klucza publicznego może zapewnić pełną obsługę MITM. Ale tak, uwierzytelnianie za pomocą klucza publicznego jest zdecydowanie lepsze niż zwykłe hasła, każdego dnia.

— andol

@kasperd: Cóż, mogę łatwo wyobrazić sobie kogoś, kto po prostu odkrywa przekazywanie agentów, ale nie do końca go rozumie, umieszczając coś w rodzaju „Host * \ n \ tForwardAgent yes” w ~ / .ssh / config. Ludzie robią

— różne

W drugiej części pytania wydaje się, że martwisz się o kradzież notebooka, a wraz z nim prywatnych kluczy do logowania SSH bez hasła na serwerach.

Należy pamiętać, że można to łatwo rozwiązać (problem z kluczami prywatnymi), przechowując klucze prywatne „zaszyfrowane” za pomocą „hasła”: można je początkowo zaszyfrować, generując za pomocą narzędzia ssh-keygen , podając hasło na końcu proces generowania lub, jeśli już je masz bez skryptów, użyj narzędzia ssh-keygen z -popcją. Gdy klucz zostanie zaszyfrowany, przy każdym logowaniu zostaniesz poproszony o wprowadzenie odpowiedniego hasła i ... jeśli jest poprawny, wszystko przebiegnie normalnie.

Ponadto, jeśli nie chcesz wprowadzać hasła za każdym razem, gdy uruchamiasz klienta ssh, możesz użyć ssh-agent : może śledzić w pamięci niezaszyfrowane klucze prywatne. Możesz po prostu uruchomić ssh-add, wskazując na plik zawierający zaszyfrowany klucz, a po zapytaniu o hasło, klucz jest dodawany do zestawu zarządzanego przez ssh-agent. Następnie za każdym razem, gdy klient SSH wymaga klucza chronionego hasłem, agent ssh transparentnie przekazuje powiązany niezaszyfrowany klucz prywatny klientowi ssh. Zatem dla ciebie nie trzeba wchodzić w to interaktywnie.

Pamiętaj, że ssh-agent może zarządzać dużą ilością kluczy, i oczywiście możesz „dostroić” swój notebook / pulpit, aby uruchomić ssh-addnarzędzie (w celu wypełnienia zestawu kluczy ssh-agent) podczas logowania / uruchamiania.

Ponadto, jeśli ktoś ukradnie Twój laptop, twoje klucze prywatne prawdopodobnie nie są jedyną „wrażliwą” treścią, którą będziesz rozdawać: pamiętaj, że przy dzisiejszych dystrybucjach komputerów stacjonarnych z systemem Linux BARDZO łatwo jest skonfigurować notebooka opartego na „zaszyfrowanym” "system plików ( /homejako starter, ale całość w /razie potrzeby). Więc proszę, rozważ to również.

Wszystkie powyższe, oczywiście, NIE mają zastosowania, jeśli NIE polegasz na SWOIM WŁASNYM notatniku.

PS: co do możliwości przechowywania dwie połówki klucz prywatny na różnych nośnikach: Ja zdecydowanie porad można nie to zrobić, jak utrzymywanie dwóch kawałków wrażliwej zawartości w niezaszyfrowanej formie jest znacznie, znacznie gorzej, niż utrzymywanie dwóch pełne kopie całej zawartości, zaszyfrowane!

— Damiano Verzulli
źródło

Na pierwszą część twojego pytania odpowiada już poprzednia odpowiedź. Zgodnie z twoją drugą częścią, polecam dodać drugi czynnik do twojego logowania ssh przy użyciu pam_google_authenticator. Jest to dość łatwa konfiguracja i konfiguracja w dowolnej dystrybucji. W przypadku kradzieży klucza prywatnego, który nosisz, nie mogą zalogować się na twój serwer bez hasła TOTP jednorazowego z Google-Authenticatora.

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7

— Arul Selvan
źródło