Skip to content

Artykuły oznaczone jako: ssh

Jak skonfigurować połączenie VPN przez SSH

Szukając informacji na temat ukrycia ruchu generowanego przez OpenVPN, natrafiłem także na sposób, który wykorzystuje do tego celu połączenie SSH. W efekcie jesteśmy w stanie upodobnić ruch VPN do tego, który zwykle służy do zarządzania zdalnymi systemami linux. Jako, że temat maskowania połączenia VPN jest kluczowy w walce z cenzurą internetu, to im więcej sposobów, by taki zabieg przeprowadzić, tym lepiej. Dlatego też postanowiłem odświeżyć nieco podlinkowany wyżej artykuł i sprawdzić czy jest on jeszcze aktualny. Wprawdzie nie dysponuję Ubuntu, a jedynie dystrybucją Debian ale raczej nie powinno być problemów z odwzorowaniem konfiguracji na tym systemie, choć artykuł jest dość leciwy już i pewnie trzeba będzie kilka rzeczy zaktualizować.

Czytaj cały wpis

DD-WRT: SSH port forwarding i panel aministracyjny

Firmware DD-WRT oferuje kilka sposobów na uzyskanie dostępu do naszego domowego routera. Poza graficznym panelem webowym, gdzie wszystko możemy sobie wyklikać, mamy jeszcze tekstowy telnet i SSH. DD-WRT jest nam w stanie także zaoferować SSH port forwarding. Ten mechanizm z kolei bardzo przydaje się w momencie, gdy chcemy uzyskać dostęp do routera przez panel administracyjny ale nie uśmiecha nam się wystawianie go na widok publiczny po niezabezpieczonym protokole HTTP. Z kolei serwer www posiadający zaimplementowany protokół SSL/TLS jest dość zasobożerny i jego zastosowanie średnio nadaje się w przypadku małych routerów. Za pomocą przekierowania portów SSH możemy uzyskać dostęp do lokalnej instancji panelu webowego omijając obydwa te powyższe problemy. Panel admina pozostaje schowany w sieci lokalnej, a my logujemy się do niego wykorzystując połączenie SSH.

Czytaj cały wpis

DD-WRT: Dostęp do routera (telnet, ssh, panel web)

Do routera posiadającego na pokładzie firmware DD-WRT możemy uzyskać dostęp na kilka sposobów. Ten najbardziej popularny, to oczywiście panel administracyjny dostępny z poziomu www, na który możemy się dostać wpisując w pasku adresu przeglądarki http://192.168.1.1/ . Niemniej jednak, to nie jest jedyna droga do zarządzania routerem. Standardowo również mamy aktywną usługę telnet. Dodatkowo możemy aktywować SSL/TLS w panelu admina oraz dorobić usługę SSH. W tym artykule omówimy sobie wszystkie te formy dostępu do routera.

Czytaj cały wpis

packet_write_wait: Connection to IP port 22: Broken pipe

Operowanie na VPS nie jest jakoś specjalnie trudne, zwłaszcza w przypadku, gdy mamy dostęp root i możemy logować się na serwer z wykorzystaniem protokołu SSH. Dalej to już zwykła linux'owa mechanika, która może być nieco inna, w zależności od tego, jaki dokładnie system operacyjny na tym VPS stoi. Czasami jednak, w pewnym momencie podczas połączenia możemy zostać rozłączeni z niewiadomych nam przyczyn. Niemniej jednak, zawsze, gdy ten problem występuje, w terminalu można zobaczyć komunikat: packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe . Przydałoby się zatem coś na ten stan rzeczy poradzić.

Czytaj cały wpis

Zdalny backup przy pomocy rsync, ssh i sudo

Mój VPS, jako, że jest dość tani, nie zawiera całej masy wynalazków. Jedną z tych bardziej użytecznych rzeczy jest backup danych na dysku VPS'a. OVH liczy sobie trochę grosza za usługę snapshot'ów. Dlatego też byłem zmuszony poszukać innego rozwiązania, które sprawiłoby, że kopia wszystkich ważnych plików byłaby zawsze poza granicami tego VPS. Najlepiej, gdyby te pliki były umieszczany na moim własnym komputerze, czy jakiejś stacji roboczej, która ma robić za taki backup'owy serwer. Problem w tym, że ciężko jest zsynchronizować sobie poprawnie katalogi na odległość, choć jest to możliwe przy pomocy ssh , rsync oraz sudo . Z tym, że mamy tutaj szereg problemów związanych z uprawnieniami do plików. No i oczywiście trzeba także uwzględnić inny port SSH. Trochę było z tym zamieszania ale ostatecznie udało się to zadanie rozwiązać.

Czytaj cały wpis

Klucze szyfrujące RSA w OpenWRT (ssh)

Klucze RSA w protokole SSH mogą być wykorzystane jako sposób identyfikacji danej osoby przy logowaniu się do zdalnego serwera. Te klucze zawsze występują w parach. Jeden prywatny, drugi publiczny. Pierwszy z nich jest znany tylko nam i powinien być trzymany w sekrecie i pilnie strzeżony. Klucz publiczny z kolei zaś jest przesyłany na każdy serwer SSH, z którym chcemy się połączyć. Gdy serwer jest w posiadaniu naszego klucza publicznego i widzi przy tym, że próbujemy nawiązać połączenie, używa on tego klucza, by wysłać do nas zapytanie (challange). Jest ono zakodowane i musi na nie zostać udzielona prawidłowa odpowiedź. Tej z kolei może udzielić ktoś, kto jest w posiadaniu klucza prywatnego. Nie ma innej opcji, by rozkodować wiadomość. Dlatego też nikt inny nie może udzielić na nią prawidłowej odpowiedzi. To rozwiązanie eliminuje wrażliwość na różne formy podsłuchu. Ten kto nasłuchuje nie będzie w stanie przechwycić pakietów zawierających hasło, bo ono nie jest nigdy transmitowane prze sieć. No i oczywiście jeśli chodzi o samo hasło, to odpadają nam ataki bruteforce pod kątem jego złamania. W tym wpisie postaramy się zaimplementować na routerze z OpenWrt system logowania oparty o klucze RSA.

Czytaj cały wpis

Dostęp do routera OpenWRT (telnet, ssh, sshfs)

Standardowa instalacja OpenWRT nie zawiera w sobie żadnego trybu graficznego czy też panelu www. Wszelkie operacje trzeba przeprowadzać przy pomocy terminala. Mimo to, OpenWRT daje nam kilka możliwości na uzyskanie dostępu do routera. Ten firmware ma zaimplementowaną obsługę protokołu telnet, który swoją drogą nie należy do bezpiecznych. Oprócz niego, mamy możliwość logowania się za pomocą protokołu SSH. Tutaj sprawa bezpieczeństwa ma się o wiele lepiej. Poza tym, można bardzo łatwo zaimplementować klucze szyfrujące połączenie eliminując tym samym dostęp oparty o wprowadzanie hasła przy logowaniu. Czy takie zabezpieczenia nam są potrzebne w domowych warunkach? Tę kwestię niech sobie każdy użytkownik rozważy sam. Dodatkowo, jeśli już wspomnieliśmy o protokole SSH, to warto poruszyć kwestię protokołu SSHFS, czyli możliwości zamontowania systemu plików routera lokalnie na komputerze. Daje nam to możliwość przeglądania takiego systemu plików jak zwykłego katalogu. No i mamy też uproszczoną edycję plików, która może odbywać się w trybie graficznym przy pomocy narzędzi, z których zwykle korzystamy na swoim PC. W tym wpisie rzucimy okiem na te poszczególne metody i przy pomocy każdej z nich spróbujemy uzyskać dostęp do routera.

Czytaj cały wpis

Szyfrowanie dźwięku przesyłanego przez sieć

PulseAudio to serwer dźwięku, który jest w stanie otrzymywać zapytania ze zdalnych lokalizacji. Wobec czego, możemy realizować przesyłanie dźwięku przez sieć i usłyszeć go tam, gdzie go sobie życzymy. Problem w tym, że taki dźwięk jest przesyłany przez sieć w formie niezaszyfrowanej. Dlatego też jesteśmy narażeni na podsłuchanie wszystkiego co mówimy do mikrofonu lub też tego co pojawia się w naszych głośnikach. Możemy jednak zabezpieczyć komunikację między klientem i serwerem dźwięku wykorzystując do tego połączenie SSH. W ten sposób cały sygnał dźwiękowy, jaki jest generowany przez danego hosta w sieci, zostanie wrzucony w szyfrowany kanał TLS i nikt nie będzie w stanie go zinterpretować. Ten wpis ma na celu przedstawienie sposobu na zaszyfrowanie dźwięku, bez którego większość z nas nie wyobraża sobie pacy przy komputerze.

Czytaj cały wpis

Szyfrowanie ruchu do Xserver'a przy pomocy SSH

W przypadku zaufanych sieci lokalnych, czy też kontenerów LXC, nie musimy zbytnio się troszczyć o bezpieczeństwo przesyłanych danych. Nikt nam przecież nie założy tutaj podsłuchu. Dlatego też we wpisie poświęconym konfiguracji Wine nie szyfrowaliśmy praktycznie żadnego ruchu sieciowego. Gdyby jednak zaszła potrzeba przesłania pakietów do zdalnego Xserver'a przez internet, to takie rozwiązanie naraziłoby nas na przechwycenie wszystkich danych. By zabezpieczyć się przed tego typu scenariuszem możemy zaszyfrować ruch do Xserver'a forward'ując wszystkie zapytania przy pomocy szyfrowanego tunelu TLS. Możemy to zrobić przy pomocy SSH i w tym wpisie postaramy się skonfigurować ten mechanizm.

Czytaj cały wpis

Uwierzytelniające klucze SSH

Klucze SSH mogą być wykorzystane jako sposób identyfikacji danej osoby przy logowaniu się do zdalnego serwera SSH. Te klucze zawsze występują w parach -- jeden prywatny, drugi publiczny. Pierwszy z nich jest znany tylko nam i powinien być trzymany w sekrecie i pilnie strzeżony. Klucz publiczny z kolei zaś jest przesyłany na każdy serwer SSH, z którym chcemy się połączyć. Gdy serwer jest w posiadaniu naszego klucza publicznego i widzi przy tym, że próbujemy nawiązać połączenie, używa on tego klucza by wysłać do nas zapytanie (challange) -- jest ono zakodowane i musi na nie zostać udzielona odpowiednia odpowiedź, a tej może dokonać ktoś, kto jest w posiadaniu klucza prywatnego. Nie ma innej opcji by rozkodować wiadomość, dlatego też nikt inny nie może udzielić na nią prawidłowej odpowiedzi. To rozwiązanie eliminuje wrażliwość na różne formy podsłuchu -- ten kto nasłuchuje nie będzie w stanie przechwycić pakietów zawierających hasło, bo ono nie jest nigdy transmitowane prze sieć. No i oczywiście jeśli chodzi o samo hasło -- odpadają nam ataki typu Brute Force pod kątem jego złamania.

Czytaj cały wpis

Strona 1 z 212