SIEĆ
Sieci linuksowe (uniksowe), zarówno te lokalne, jak i rozległe (np. Internet), działają w oparciu o ten sam protokół - TCP/IP, chociaż nie jesteśmy do niego ograniczeni i gdy zachodzi taka potrzeba, Linux może obsługiwać inne protokoły (np. IPX)
Sieć utworzona w oparciu o TCP/IP jest siecią typu peer to peer, czyli równorzędną, co oznacza, że żaden komputer nie jest w niej wyróżniony. Komputer w sieci TCP/IP jest jednoznacznie identyfikowany przez własny niepowtarzalny adres, zwany adresem IP (IP - Internet Protocol).
Do przeprowadzenia niniejszego ćwiczenia potrzebne nam będą dwa komputery: nasz i drugi skonfigurowany analogicznie (patrz tutaj). Nazwiemy go tower.dom.org.pl i nadamy mu adres IP 192.168.100.2 Pozostałe dane naszej ćwiczebnej sieci są następujące:
adres sieci: 192.168.100.0
adres rozgłoszeniowy sieci: 192.168.100.255
netmaska sieci: 255.255.255.0
prefiks adresu IP dowolnego węzła sieci: 192.168.100.
Przestrzeń adresowa tak określonej sieci odpowiada klasie C, czyli możemy przyłączyć do niej maksymalnie 254 komputery o adresach IP od 192.168.100.1 do 192.168.100.254
Dystrybucja Red Hat dostarcza semigraficzne narzędzie do konfiguracji sieci netconf, w którym możemy ustawić wszystkie interesujące nas parametry. Jeśli wszystko wykonaliśmy prawidłowo podczas instalacji nie ma potrzeby korzystania z netconf. Jeżeli jednak będziemy musieli to zrobić, to w celu zmiany nazwy komputera i jego adresu IP wybieramy z menu (netconf) pozycję: Basic host information.
Sprawdźmy, czy nasze komputery (crasz i tower) są fizycznie przyłączone do sieci. Włączmy je i zalogujmy się na każdym jako root
Sprawdzamy funkcjonowanie sieci (ping)
Zasiadamy przy konsoli komputera crash. Pierwsze sprawdzenie polega na tym, czy jesteśmy w stanie transmitować pakiety. Używamy do tego celu polecenia ping, które korzystając z odpowiednich mechanizmów TCP/IP wysyła raz po raz pakiet do wskazanego hosta (komputera), który powinien go natychmiast odesłać z powrotem. Mierzony jest odcinek czasu od wysłania do powrotu pakietu oraz sporządzona prosta statystyka pakietów wysłanych i zwróconych.
# ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.3 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.3 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.3 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.3 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.3 ms
--- localhost ping statistic ---
5 packets transmitted, 5 packets received, 0% pockets loss
round-trip min/avg/max = 0.1/0.2/0.3 ms
[root@crash /root]# ping 127.0.0.1
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.3 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.2 ms
--- 127.0.0.1 ping statistic ---
5 packets transmitted, 5 packets received, 0% pockets loss
round-trip min/avg/max = 0.2/0.2/0.3 ms
[root@crash /root]# _
Polecenie ping przerywamy ([CTRL]+[c]) za każdym razem, gdyż inaczej będzie w nieskończoność wysyłało pakiety. Adres 127.0.0.1 i jego alias localhost odpowiadają naszemu (lokalnemu) komputerowi (tzw. pętli zwrotnej) i są to wartości standardowe zarezerwowane do celów diagnostycznych. Dla dowolnego innego komputera będą takie same.
Gdy localhost działa, możemy wyjść na świat, czyli wywołać komputer tower:
# ping 192.168.100.2
PING localhost (192.168.100.2): 56 data bytes
64 bytes from 192.168.100.2: icmp_seq=0 ttl=64 time=0.5 ms
64 bytes from 192.168.100.2: icmp_seq=1 ttl=64 time=0.5 ms
64 bytes from 192.168.100.2: icmp_seq=2 ttl=64 time=0.5 ms
64 bytes from 192.168.100.2: icmp_seq=3 ttl=64 time=0.5 ms
64 bytes from 192.168.100.2: icmp_seq=4 ttl=64 time=0.5 ms
64 bytes from 192.168.100.2: icmp_seq=5 ttl=64 time=0.5 ms
64 bytes from 192.168.100.2: icmp_seq=6 ttl=64 time=0.5 ms
--- 192.168.100.2 ping statistic ---
7 packets transmitted, 7 packets received, 0% pockets loss
round-trip min/avg/max = 0.4/0.4/0.5 ms
[root@crash /root]# _
Gdy sprawdzimy, że sieć zapewnia transmisję pakietów pomiędzy komputerami crash i tower, możemy przystąpić do konfiguracji NFS.
Konfigurujemy NFS
NFS (Network File System), czyli sieciowy system plików jest mechanizmem, dzięki któremu do naszego drzewa katalogów możemy zamontować katalog z systemu plików dowolnego innego komputera w sieci. Jest to sytuacja analogiczna do montowania dyskietki czy CD-ROM-u. Jeżeli w zdalnym katalogu będą pliki, możemy je wykorzystać do naszych celów. Jeśli katalog będzie pusty, wykorzystamy go jako dodatkową przestrzeń dyskową. Ogólnie, zdalny katalog staje się integralną częścią naszego systemu plików, możemy więc (mając odpowiednie prawa dostępu) także uruchomić na przykład znajdujący się na nim oprogramowanie.
Zdalny komputer, który udostępnia nam swoje zasoby, nazywamy serwerem NFS, my zaś jesteśmy klientem NFS. Konfiguracja serwera NFS sprowadza się do wskazania, które katalogi będzie można udostępnić i komu. W tym przypadku "komu" nie dotyczy konkretnych użytkowników, lecz nazw (adresów IP) odległych komputerów.
Oprogramowanie niezbędne do funkcjonowania serwera NFS znajduje się na dwóch pakietach RPM (portmap i nfs-server). Oprogramowanie klienta znajduje się w pakiecie nfs-server-clients. Jeżeli instalowaliśmy system zgodnie z zaleceniami dotyczącymi instalacji Red Hat'a, mamy wszystkie trzy pakiety zainstalowane. Dlatego też sami możemy udostępnić swoje zasoby innym i stać się serwerem NFS. W maszym przykładzie pozostajemy tylko skromnym klientem, a jako serwer NFS skonfigurujemy komputer tower.
Pierwszym krokiem będzie modyfikacja pliku konfiguracyjnego /etc/hosts na wszytkich (my mamy tylko dwa) komputerach naszej sieci. Plik ten zawiera adresy IP i odpowiadające im nazwy wszystkich komputerów w naszej sieci i jego zawartość będzie identyczna u wszystkich. Obejrzyjmy ten plik:
# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain
192.168.100.1 crash.dom.org.pl crash
[root@crash /root]# _
Powyższa zawartość została wpisana przez program instalacyjny w trakcie instalacji systemu. Każdy wiersz dotyczy innego komputera (hosta). Musi zawierać jego adres IP, pełną nazwę wraz z domeną oraz ewentualnie inne nazwy. Nazw może być kilka, oddzielonych od siebie spacjami. Jest oczywiste, że używane w całej sieci nazwy muszą być jednoznaczne i niepowtarzalne.
Musimy tylko dopisać następującą linię dotyczącą komputera tower:
192.168.100.2 tower.dom.org.pl tower
Teraz modyfikujemy plik /etc/hosts w komputerze tower. Najprawdopodobniej będzie wymagał tylko dodania informacji o naszym komputerze (crash). Jak widać, dla większej sieci można taki plik wykonać tylko raz, a następnie przekopiować go na pozostałe komputery.
Drugim krokiem będzie modyfikacja pliku konfiguracyjnego /etc/exports w komputerze tower (serwerze NFS). Jest to właściwa konfiguracja naszego serwera. Udostępnimy katalog /mnt/cdrom oraz specjalnie założony nowy katalog /wymiana. Po modyfikacji plik exports będzie wyglądał następująco:
# cat /etc/exports
/wymiana crash(rw)
/mnt/cdrom crash(ro)
[root@tower /root]# _
Zapis "crash(rw)" oznacza, że crash może montować dany katalog jako system plików do odczytu i zapisu (rw - read/write). Zapis "crash(ro)" oznacza, że crash może montować dany katalog jako system plików tylko do odczytu (ro - read only).
Pamiętajmy jednak o istnienie praw dostępu. Jeżeli chcemy, aby klient NFS mógł kasować i tworzyć pliki w katalogu wymiana, musi mieć do niego wszystkie prawa dostępu. Brak prawa pisania do katalogu wymiana oznacza tylko możliwość modyfikowania już istniejących w nim plików. Nadając odpowiednie prawa do katalogu /wymiana możemy ograniczać lub rozszerzać uprawnienia klienta. W naszym przypadku nadamy pełne prawa pisząc na konsoli tower:
# chmod 777 /wymiana
[root@crash /root]# _
Ponieważ nasza sieć ma tylko dwa komputery, plik exports jest nieco banalny. Wyobraźmy sobie, że istnieje jeszcze trzeci komputer o nazwie desktop, któremu chcemy udostępnić jedynie katalog /wymiana i to tylko do odczytu. Wówczas nasz hipotetyczny plik exports wyglądałby tak:
/wymiana crash(rw) desktop(ro)
/mnt/cdrom crash(ro)
Powinniśmy teraz zresetować (reboot) oba komputery, aby zmiany plików konfiguracyjnych odniosły skutek. Po ponownym zalogowaniu na crash sprawdzimy, czy wszystko działa jak należy. Zaczniemy od polecenia ping tower i gdy wszystko będzie w porządku, sprawdzimy możliwości montowania:
# showmount -e tower
Export list for tower:
/mnt/cdrom crash.dom.org.pl
/wymiana crash.dom.org.pl
[root@crash /root]# _
Polecenie showmount pokazuje możliwości montowania z wyspecyfikowanego hosta (w naszym przypadku tower), czyli co i kto może montować. Na tym moglibyśmy zakończyć ćwiczenie. Wypada jednak jeszcze wspomnieć o istnieniu narzędzia do konfiguracji sieci, które zwalnia nas od ręcznego wyszukiwania i modyfikowania plików konfiguracyjnych. Aby się z nim zapoznać, wywołujemy je poleceniem:
#netconf
Modyfikacja pliku /etc/hosts odpowiada pozycji menu Misc: Information about other hosts.
Modyfikacja pliku /etc/exports odpowiada pozycji menu Server tasks: Exported file system (NFS).
Montujemy sieciowy system plików
Skoro wszystko działa, zamontujemy katalog /wymiana z komputera tower jako nasz katalog /mnt:
# mount -t nfs tower:/wymiana /mnt
[root@crash /root]# ls /mnt
hdimage.drdos703.eva
[root@crash /root]# cp /mnt/hd* /var/lib/dosemu
[root@crash /root]# cp dosemu.bat /mnt
[root@crash /root]# ls /mnt
hdimage.drdos703.eva dosemu.bat
[root@crash /root]# _
Polecenie mount poznaliśmy już przy okazji montowania CD-ROM-u. Tutaj posługujemy się taką samą składnią, z tym że montowany system plików to NFS ("nfs"), a jako "urządzenie" występuje katalog /wymiana w komputerze tower ("tower:/wymiana"). Następnie skopiowaliśmy plik hdimage.drdos703.eva znaleziony w zdalnym katalogu do naszego katalogu /var/lib/dosemu. Skopiowaliśmy także plik dosemu.bat do zdalnego katalogu (czyli w drugą stronę).
Udostępnimy teraz zdalnie CD-ROM. Włóżmy płytkę do czytnika w komputerze tower i zamontujmy. Następnie przejdźmy do konsoli komputera crash:
# mount -t nfs tower:/mnt/cdrom /mnt/cdrom
mount: mount point /mnt/cdrom does not exist
[root@crash /root]# mount -t nfs tower:/mnt/cdrom /home/crash1
[root@crash /root]# _
Sprawdźmy (ls /home/leszek1), czy mamy dostęp do CD-ROM-u. Oto komentarz do tego co się stało. Sytem odmówił zamontowania w katalogu /mnt/cdrom ponieważ już zajeliśmy cały katalog /mnt jako punkt montowania katalogu /wymiana z tower. Zamontowaliśmy zatem katalog /mnt/cdrom z tower do /home/crash1. Ogólnie to nie jest dobrym pomysłem, ale ponieważ jesteśmy jedynym użytkownikiem naszego komputera i nie logowaliśmy się jeszcze w tej sesji jako crash1, zatem możemy sobie na to wyjątkowo pozwilić. Generalnie należy się bezwzględnie wystrzegać przyjmowania jako punktów montowania katalogów domowych użytkowników.
Teraz zamknijmy (halt) system na komputerze tower,a na crash wydajmy polecenie:
# ls /mnt
NFS server tower not responding, still trying
_
Musimy czekać aż system na komputerze tower zostanie ponownie uruchomiony, wówczas nasze połączenie NFS zostanie automatycznie odtworzone, co możemy sprawdzić później po uruchomieniu ponownym komputera tower.
Aby odzyskać kontrolę na zawieszoną konsolą, zalogujmy się jako root na innej konsoli wirtualnej (np. [lewy ALT] + [F3]). Sprawdzimy (ps) numer (PID) procesu i usuniemy go poleceniem:
# kill -s 9 PID
gdzie jako PID wpisujemy konkretny numer procesu (np. 735) uzyskany poleceniem ps.
Demontujemy NFS
Do zdemontowania zdalnego katalogu nie potrzebujemy żadnych specjalnych zabiegów. Korzystamy ze znanego już polecenia umount:
# umount /mnt
[root@crash /root]# umount /home/crash1
[root@crash /root]# _
To wszystko. Pozbyliśmy się w ten sposób obu zdalnych katalogów.
Instalujemy system poprzez NFS
Załóżmy, że do naszej sieci złożonej z dwóch komputerów (crash i tower) chcemy dołączyć trzeci, który będzie nazywał się powiedzmy desktop. W komputerze tym musimy najpierw zainstalować Linuksa (dystrybucja Red Hat 5.2), niestety komputer desktop nie jest wyposażony w czytnik CD-ROM.
Instalacji dokonamy wykorzystując czytnik CD-ROM komputera tower oraz mechanizm NFS. Najpierw wykonamy startową dyskietkę instalacyjną oraz wybierzemy kolejny adres IP komputera desktop, czyli 192.168.100.3. Następnie zmodyfikujemy pliki /etc/hosts i /etc/exports w komputerze tower, dodając w nich informację o desktop. W pliku /etc/hosts dodamy linię:
192.168.100.3 desktop.dom.org.pl desktop
W pliku /etc/exports uzupełnimy linię dotyczącą CD-ROM do postaci:
/mnt/cdrom mono(ro) desktop(ro)
Zrestartujemy (reboot) komputer tower i po ponownym załadowaniu systemu, zalogujemy się jako root, włożymy do czytnika dystrybucyjny CD-ROM i zamontujemy w standardowym punkcie montowania (/mnt/cdrom).
Teraz instalujemy fizycznie w komputerze desktop kartę sieciową oraz podłączamy ją do okablowania sieciowego (tak, aby istniało połączenie z tower). W naszym przypadku jest to karta D-Link DE-530CT+ oparta na układzie Digital 21041.
Do napędu A: włóżmy startową dyskietkę instalacyjną i zresetujemy komputer desktop. Po pojawieniu się znaku gotowości:
boot:
wciskamy [Enter]. Musimy poczekać aż pojawi się powitalny ekran i dalej będziemy prowadzeni przez program instalacyjny. Między polami na ekranie programu instalacyjnego poruszamy się za pomocą klawisza [Tab] bądź klawiszy kursora. Przejście do następnego ekranu (z zatwierdzeniem dokonanych wyborów, dokonujemy przez podświetlenie OK i naciśnięcie [Enter]). Rezygnacja zachodzi po wybraniu Cancel i [Enter].
Wybieramy kolejno:
język dystrybucji (Choose a Language): English
typ klawiatury (Keyboard Type): us
źródło instalcji (Installation Method): NFS image
Po wciśnięciu [Enter] program instalacyjny spróbuje znaleźć kartę sieciową. Jeżeli mu się to powiedzie, pojawi się komunikat w rodzaju:
Probe
A Digital 21040 (Tulip) card has been found on your system.
Po zatwierdzeniu pojawi się ekran Boot Protocol. Wybieramy: Static IP addres. Na następnym ekranie (Configure TCP/IP) wypełniamy tylko pole IP addres wpisując tam sdres naszego komputera desktop: 192.168.100.3. Pozostałe pola na ekranie zostaną wypełnione automatycznie (nie modyfikujemy ich). Po zatwierdzeniu pojawi się komunikat Host name - Determining host name and domain ... - musimy tu cierpliwie poczekać.
Na kolejnym ekranie (Configure Network) wypełniamy pola Domain name: dom.org.pl i Host name: desktop.dom.org.pl. Pozostałe pola pozostawiamy nie wypełnione. Wreszcie pojawi się ekran NFS Setup. W polu NFS server name wpisujemy adresy IP komputera tower (czyli 192.168.100.2) a w polu Red Hat directory puntk montowania CD-ROM-u w komputerze tower, czyli: /mnt/cdrom. Po zatwierdzeniu powinien się pojawić ekran Installation Path.
Kontynuujemy instalacje zgodnie z opisem instalacji Red Hat'a.
Najsłabszym punktem takiej instalacji jest rozpoznanie karty sieciowej przez program instalacyjny. Najbardziej prawdopodobne przyczyny niepowodzenia mogą być trzy:
karta sieciowa jest niesprawna (rzadko)
karta sieciowa jest prawidłowo zainstalowana - występuje konflikt sprzętowy (przerwanie, adres obsługi)
jądro systemu nie obsługuje danego modelu karty.
Jak się nazywam? (hostname)
Nawet jeśli nie zdarzyło się nam zapomnieć, jak się nazywamy, to mogliśmy zapomnieć jak nazywa się nasz komputer. Wtedy wystarczy go o to zapytać:
# hostname
crash.dom.org.pl
[root@crash /root]# _
Polecenie hostname wydaje się zbędnym gadżetem. Ma jednak sens przy zdalnych logowaniach, gdy czasami dobrze się upewnić, gdzie tak naprawdę trafiliśmy. W tym przypadku użyliśmy hostname z poziomu root-a, ale polecenie to jest dostępne dla każdego innego (zwykłego) użytkownika.
Prawa dostępu w NFS
Zalogujmy się na innej konsoli wirtualnej jako crash1 i przeprowadźmy eksperyment:
$ cd /mnt
[crash1@crash /mnt]$ touch mojplik
touch: mojplik: Permission denied
[crash1@crash /mnt]$ ls -ld
drwxr-xr-x 4 root root 1024 Apr 8 15:03 .
[crash1@crash /mnt]$ cd~
[crash1@crash /crash1]$
Użytkownik crash1 nie może utworzyć w katalogu /mnt pliku (mojplik), gdyż brakuje mu do tego prawa pisania do katalogu /mnt.
Przjdźmy na konsolę wirtualną gdzie zainstalowany jest root i zamontujmy jeszcze raz katalog /wymiana z komputera tower. Pamiętajmy jednak, że żaden użytkownik, nie może "znajdować" się w katalogu /mnt, gdyż wówczas system zgłosi go jako zajęty i odmówi zarówno montowania, jak i demontowania:
# mount -t nfs tower:/wymiana /mnt
[root@crash /root]# _
Teraz powróćmy na konsolę użytkownika crash1 i spróbujemy jeszcze raz:
$ cd /mnt
[crash1@crash /mnt]$ touch mojplik
[crash1@crash /mnt]$ ls -l
-r--r--r-- 1 nobody nobody 2192 May 2 22:35 dosemu.bat
-rwxr-xr-x 1 root root 7739008 Feb 26 01:23 hdimage.drdos703.eva
-rw-rw-r-- 1 crash1 crash1 0 May 3 08:31 mojplik
[crash1@crash /mnt]$ ls -ld
drwxrwxrwx 4 root root 1024 May 3 08:19 .
[crash1@crash /mnt]$ _
Pamiętajmy, że katalog /wymiana w tower ma nadane wszystkie prawa dla wszystkich (777). Widzimy zatem co się stało: /mnt w crash ma teraz prawa takie jak /wymina w tower.
Przejdźmy do konsoli tower i zmieńmy prawa dostępu do katalogu /wymiana:
# chmod 700 /wymiana
[root@crash /root]# _
Powróćmy do crash. Aby uwzględnić zmianę praw, jaka zaszła, na tower zdemontujemy i zamontujemy ponownie katalog /wymiana:
# umount /mnt
[root@crash /root]# mount -t nfs tower:/wymiana /mnt
[root@crash /root]# _
i zobaczymy na konsoli użytkownika crash1 co się zmieniło
$ cd /mnt
bash: /mnt: Permission denied
[crash1@crash crash1]$ ls -ld /mnt
drwx------ 4 root root 1024 May 3 08:19 /mnt
[crash1@crash /mnt]$ _
Straciliśmy wszystkie prawa do /mnt i nie możemy nawet się do niego dostać. Ale skoro root jest właścicielem katalogu i ma do niego wszystkie prawa, możemy spróbować:
# cd /mnt
[root@crash /root]# touch mojplik2
touch: mojplik2: Permission denied
[root@crash /root]# chmod 777 /mnt
chmod: /mnt: Operation not permitted
[root@crash /root]# _
To prawda, że root jest właścicielem katalogu /mnt, ale jest to root z tower, a nie root z crash. Bowiem teraz /mnt jest tylko punktem montowania i tak naprawdę reprezentuje katalog /wymiana z tower. Użytkownicy z crash (także root) są dla katalogu wymiana z tower tylko zwykłymi użytkownikami i w tej chwili żadne prawa im nie przysługują.
Wnioski są warte zapamiętania. Montując zdalny katalog uzyskujemy prawa dostępu do niego takie, jakie ma on we własnym systemie. Nie możemy ich zmienić. Pozwala to administratorowi zdalnego sytemu (serwer NFS) na dodatkową kontrolę nad udostępnionymi zasobami.
Zdalne logowanie (telnet)
W poprzednim ćwiczeniu nabiegaliśmy się nieco pomiędzy dwoma komputerami. Okazuje się, że nie byłoby to wcale konieczne, gdybyśmy wydali polecenie:
# telnet tower
Trying 192.168.100.2...
Connected to tower.dom.org.pl.
Escape character is '^]'.
Red Hat Linux relase 5.1 (Manhattan)
Kernel 2.0.35 on an i586
login: _
Otrzymaliśmy zaproszenie do zalogowania się na komputerze tower. Wystarczy teraz podać nazwę i hasło użytkownia systemu tower.
Polecenie telnet umożliwia zalogowanie się na odległym komputerze i pracowanie na nim dokładnie tam samo jak na naszym. Kończymy pracę poleceniem:
exit
Zamiast nazwy naszego zdalnego komputera często podajemy wprost jego adres IP, na przykład w naszym (tower) przypadku byłoby to:
# telnet 192.168.100.2
Takie bezwzględne wywołanie uniezależnia nas od mechanizmów przechowywania nazw, które mogą z różnych powodów nie działać lub być błędnie skonfigurowane. W naszej małej sieci lokalnej to raczej nie może się zdarzyć, ale logowaniach w rozległej sieci - tak.
Usługa telnet w dystrybucji Red Hat jest tak domyślnie skonfigurowana, że nie umożliwia zalogowanie wprost jako root (nawet gdy podamy prawidłowe hasło), dając "przebiegły" komunikat o błędzie:
Login incorrect
login: _
Jest to proste zabezpieczenie przeciwko hakerom. Można je obejść, logując się najpierw jako zwykły użytkownik, a następnie uzyskując uprawnienia root-a poprzez polecenie su.
Drufie zabezpieczenie to limitowany czas na zalogowanie się do systemu. Jeżeli nie uczynimy tego w ciągu minuty - połączenie zostanie zerwane i otrzymamy komunikat:
login: Login timed out after 60 seconds
Connections closed by foreign host.
1