MySQLdump z wykluczeniem kilku baz danych, przesyłany z kompresją przez SSH na 2’gi host:

mysql -u root -p$PASS -e 'show databases' | perl -ne 'print unless /\b(?:mysql|information_schema|Database)\b/' | xargs mysqldump -u root -p$PASS --master-data=2 --single-transaction -B | gzip -c | ssh login@2host.com 'cat > ~/mysql.sql.gz'

N

iektóre oprogramowanie jako wyjście dla błędów wykorzystuje jedynie konsolę, której zawartość nie koniecznie widać podczas sesji SSH. Użycie urządzenia vcs (ang. virtual console memory) pozwala zmienić ten scenariusz. Podczas sesji SSH wystarczy wydać polecenie:

# cat /dev/vcs1

Pokaże nam to zawartość pierwszej konsoli. Możemy również spojrzeć na kolejne wirtualne terminale za pomocą cyfr 2,3 itd. W większości centr danych, gdzie łączność jest utrzymywana za pomocą zdalnych terminali, KVM over IP lub Serial over LAN, czy innych rozwiązań jest to jeden z szybszych sposobów na podgląd aktualnych zdarzeń na konsoli. W dodatku – jeżeli zależny nam na monitorowaniu wszystkich zdarzeń zdalnego serwera możemy przekierować wszystkie informacje na szóstą konsolę: *.* /dev/tty6 i cyklicznie ją sprawdzać (wyjście nie uzupełnia na bieżąco nowych linii): watch -n 1 cat /dev/vcs6.

W

dobie takich wynalazków jak Firesheep lub innego rodzaju natręctw kradnących nasze cyfrowe tożsamości trzeba być ostrożnym przy łączeniu się z różnymi sieciami – szczególnie Hotspotami. Masowe tworzenie lub łączenie się z sieciami przez rasowe tunele VPN nadal pozostaje komfortem dostępnym nie dla wszystkich. Nie wszystkie serwery linuksowe dające nam dostęp do powłoki oferują tego typu usługi. Na szczęście większość z nich umożliwia nam łączenie się przez SSH. I w tym momencie wkracza sshuttle.
[ czytaj całość… ]

A

ktualnie istnieje wiele otwartych sieci Wi-Fi, czyli tzw. Hotspotów. Problemem hotspotów jest częsty brak zapewnienia odpowiedniego szyfrowania i izolacji poszczególnych klientów. Dlatego w tego rodzaju sieciach najczęściej dochodzi do podsłuchiwania ruchu sieciowego, a tym samym przejęcia danych autoryzacyjnych do poczty, czy różnych serwisów społecznościowych lub bankowych, w których podczas trwania procesu uwierzytelniania – ruch między naszą przeglądarką lub klientem pocztowym, a serwerem nie zawsze jest (cały czas) szyfrowany.
[ czytaj całość… ]

P

rzedstawiony hack jest tłumaczeniem “Quick Logins with ssh Client keys” z książki “Linux Servers Hacks” autorstwa Rob’a Flickenger’a udostępnionym on-line (Hack #66) na stronie http://hacks.oreilly.com. Do tłumaczenia zostało dodane także parę informacji od tłumacza.
[ czytaj całość… ]

P

rzedstawiony hack jest tłumaczeniem “Using rsync over ssh” z książki “Linux Servers Hacks” autorstwa Rob’a Flickenger’a udostępnionym on-line (Hack #38) na stronie http://hacks.oreilly.com. Do tłumaczenia zostało dodane także parę informacji od tłumacza.
[ czytaj całość… ]

W

szyscy używamy / korzystamy z połączeń SSH. Dzięki temu protokołowi jesteśmy w stanie w bezpieczny sposób łączyć się z inną maszyną i wykonywać na niej w zdalny sposób komendy. Jesteśmy także w stanie przesyłać bezpiecznie pliki (SCP), a nawet tworzyć o niebo bezpieczniejszą alternatywę dla FTP (RSSH + SCPOnly), czy tworzyć szyfrowane tunele itp. Jednak wiele osób nie zdaje sobie sprawy z tego, iż chociaż SSH szyfruje przesyłane dane to dla atakującego wcale nie jest problemem podsłuchać Naszą sesję. Podsłuchiwanie to z powodu szyfrowania sesji przybiera trochę inny kształt: atakujący może symulować serwer, z którym chcemy się połączyć. Dzięki symulowaniu serwera będzie w stanie Nas “podsłuchiwać”, ponieważ chociaż dane są szyfrowane to de fakto będą one przechodziły (lub adekwatnie od intencji atakującego — dochodziły) przez “niepowołaną” maszynę. Jest to tzw. atak typu Man-In-The-Middle. Artykuł ten ma na celu przybliżenie sposobu ochrony Naszej szyfrowanej sesji SSH dzięki kluczom identyfikacyjnym serwera.
[ czytaj całość… ]