From Łukasz Graczykowski
(Difference between revisions)
|
|
Line 72: |
Line 72: |
| By wygenerować klucz należy wykonać polecenie <code>ssh-keygen</code>, można podać hasło do klucza, ale na dziś sobie to darujemy. Polecenie to wykonujemy na komputerze, z którego chcemy się zalogować. | | By wygenerować klucz należy wykonać polecenie <code>ssh-keygen</code>, można podać hasło do klucza, ale na dziś sobie to darujemy. Polecenie to wykonujemy na komputerze, z którego chcemy się zalogować. |
| | | |
- | Polecenie ssh-keygen stworzyło dwa pliki: | + | Polecenie ssh-keygen tworzy dwa pliki: |
| | | |
- | * .ssh/id_rsa.pub — zawiera klucz publiczny | + | * <code>.ssh/id_rsa.pub</code> — zawiera klucz publiczny |
- | * .ssh/id_rsa — zawiera klucz prywatny | + | * <code>.ssh/id_rsa </code>— zawiera klucz prywatny |
| Plik $HOME/.ssh/authorized_keys zawiera listę kluczy publicznych, po jednym w każdej linii. Klucz prywatny powiązany z dowolnym z tych kluczy publicznych może posłużyć do logowania się do serwera. | | Plik $HOME/.ssh/authorized_keys zawiera listę kluczy publicznych, po jednym w każdej linii. Klucz prywatny powiązany z dowolnym z tych kluczy publicznych może posłużyć do logowania się do serwera. |
| | | |
- | '''Uwaga!''' Zarówno folder $HOME/.ssh/ oraz pliki w środku muszą mieć uprawnienia do czytania tylko przez użytnownika (np. chmod 600). | + | '''Uwaga!''' Zarówno folder <code>$HOME/.ssh/</code> oraz pliki w środku muszą mieć uprawnienia do czytania tylko przez użytnownika (np. chmod 600). |
| | | |
- | '''Uwaga 2!''' Postępowanie - generujemy na komputerze, z którego się logujemy, klucz prywatny i publiczny. Klucz publiczny wysyłamy na komputer, na który chcemy się zalogować (do folderu ~/.ssh). W komputerze, na który chcemy sie zalogować kopiujemy zawartość klucza publicznego do pliku authorized_keys. | + | '''Uwaga 2!''' Postępowanie - generujemy na komputerze, z którego się logujemy, klucz prywatny i publiczny. Klucz publiczny wysyłamy na komputer, na który chcemy się zalogować (do folderu <code>~/.ssh</code>). W komputerze, na który chcemy sie zalogować kopiujemy zawartość klucza publicznego do pliku <code>authorized_keys</code>. |
| | | |
| ===Zadanie 2=== | | ===Zadanie 2=== |
Revision as of 12:21, 13 December 2016
Zadania
Zadanie 1
Wyłączyć logowanie ssh dla użytkowników foo oraz root.
Zmiana interfejsu sieciowego
Wyłączamy maszyny wirtualne.
Settings -> Network Adapters -> Attached to: Bridged Adapter, eth0.
Startujemy maszyny.
Serwer ssh
SSH to standard protokołów komunikacyjnych, które umożliwiają:
- Bezpieczną zdalną pracę na komputerze podłączonym do Internetu
- Bezpieczne logowanie za pomocą pary kryptograficznych kluczy
- Tworzenie bezpiecznych tuneli pozwalających na np. omijanie niektórych firewalli.
Konfiguracja serwera ssh
Konfiguracja serwera mieści się w katalogu /etc/ssh/sshd_config
(proszę nie pomylić z ssh_config — bez d w środku).
By zapoznać się z tym co można skonfigurować w tym pliku, proszę przejrzeć stronę manuala: man sshd_config
.
Zadanie 1
Wyłączyć logowanie ssh dla użytkowników foo oraz root.
Po wykonaniu zmian należy zrestartować serwer wykonując polecenie:
sudo service ssh restart
Logowanie za pomocą klucza
Logowanie na zdalną maszynę
Logowanie na zdalną maszynę:
ssh username@ip
Przy pierwszym logowaniu pojawi się ostrzeżenie:
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
Mówi ono że:
Nie łączyliście się z tym serwerem do tej pory i sygnatura tego serwera nie znajduje się w rejestrze.
System SSH nie ma pewności, że połączyliście się z właściwym serwerem - w pliku known_hosts zabrakło sygnatury serwera (moglibyśmy ją tam np. zawczasu dodać). W takim wypadku komputer zwykle pyta (1) czy na pewno chcemy się połączyć z nieznanym serwerem, oraz (2) czy od razu dodać jego sygnaturę do rejestru.
Działanie logowania za pomocą klucza
Klient generuje parę kluczy, zwanych publicznym i prywatnym, klucze te (bez wchodzenia w szczegóły) pozwalają na wykonanie kryptograficznego podpisu jakiejś wiadomości. Klucz prywatny pozwala na podpisanie wiadomości, a publiczny na weryfikację poprawności podpisu. Mając klucz publiczny nie da się ani podpisać wiadomości, ani uzyskać klucza prywatnego.
Procedura logowania za pomocą klucza wygląda tak:
- Klient i serwer negocjują połączenie 1 do 1, którego nikt nie może podsłuchać.
- Serwer udowadnia klientowi, że jest tym serwerem do którego klient chciał się połączyć (patrz wyżej)
- Klient wysyłą prośbę: chcę zalogować się jako użytkownik taki a taki.
- Serwer odpowiada: w takim razie podpisz mi ten losowy ciąg znaków.
- Klient swoim kluczem prywatnym podpisuje ów losowy ciąg znaków.
- Serwer znajduje odpowiedni klucz publiczny i sprawdza podpis.
Klucze mają następujące przewagi nad hasłami:
- Bezpieczne hasła są bardzo trudne do zapamiętania. Klucze są zapamiętywane przez komputer, więc mogą zawierać więcej “losowości”.
- Hasło jest wysyłane w tekście jawnym na serwer, w autoryzacji kluczem publicznym w komunikacji nie pojawiają się dane które pozwalają na autoryzację.
- Hasło trzeba podawać przy każdym kolejnym logowaniu, istnieją natomiast dość standardowe metody bezpiecznego przechowywania kluczy ssh w pamięci ram komputera (hasło do klucza podaje się tylko raz przy logowaniu na komputer; my na zajęciach będziemy używali kluczy bez hasła)
Instalacja swojego klucza na serwerze
By wygenerować klucz należy wykonać polecenie ssh-keygen
, można podać hasło do klucza, ale na dziś sobie to darujemy. Polecenie to wykonujemy na komputerze, z którego chcemy się zalogować.
Polecenie ssh-keygen tworzy dwa pliki:
-
.ssh/id_rsa.pub
— zawiera klucz publiczny
-
.ssh/id_rsa
— zawiera klucz prywatny
Plik $HOME/.ssh/authorized_keys zawiera listę kluczy publicznych, po jednym w każdej linii. Klucz prywatny powiązany z dowolnym z tych kluczy publicznych może posłużyć do logowania się do serwera.
Uwaga! Zarówno folder $HOME/.ssh/
oraz pliki w środku muszą mieć uprawnienia do czytania tylko przez użytnownika (np. chmod 600).
Uwaga 2! Postępowanie - generujemy na komputerze, z którego się logujemy, klucz prywatny i publiczny. Klucz publiczny wysyłamy na komputer, na który chcemy się zalogować (do folderu ~/.ssh
). W komputerze, na który chcemy sie zalogować kopiujemy zawartość klucza publicznego do pliku authorized_keys
.
Zadanie 2
Zalogować się na maszynę wirtualną za pomocą klucza ssh.
Instalacja firewalla
Firewall to oprogramowanie pozwalające na kontrolę pakietów IP przetwarzanych przez maszynę.
W systemach GNU/Liunux firewall jest częścią jądra systemu i można go kontrolować za pomocą polecenia iptables, polecenie to jednak nie jest bardzo przyjazne, więc poznamy bardzo prostą nakładkę na iptables: mianowicie program ufw.
Zadanie 3
Proszę zainstalować firewall ufw, a następnie korzystając z informacji z man ufw:
- Wyłączyć możliwość wykonywania połączeń przychodzących
- Zweryfikować brak możliwości podłączania się z serwerem ssh
- Umożliwić łączenie się na port 22 (port SSH)
- Zweryfikować że ssh działa
- Wyłączyć firewall ufw.
Instalacja serwera i klienta NFS
NFS to sieciowy system plików, w zasadzie jeden z wielu siecowych systemów plików, przykłady innych to:
- Samba (protokół współdzielenia plików i innych rzeczy w Windowsach)
- Lustre (klastrowy system plików)
Instalacja serwera NFS
By zainstalować narzędzia nfs należy zainstalować dwie paczki: nfs-kernel-server oraz nfs-common, pierwsza służy do udostępniania katalogów, druga do montowania katalogów już udostępnionych.
Zadanie 4
Proszę:
Konfiguracja NFS jest dostępna w katalogu /etc/exports, korzystając z man exports udostępnić katalog /home/<<waszlogin>>/foo
dla całego laboratorium (tj. dla sieci 192.168.1.0/24), do odczytu i zapisu
- Zamontować sobie katalog który udostępnił jakaś koleżanka/kolega i następnie zapisać coś w tym katalogu.
Do montowania plików i katalogów służy polecenie mount <skąd> <dokąd>, <dokąd> musi być istniejącym katalogiem lokalnym. <skąd> w przypadku nfs ma postać server:/ścieżka.
Uwaga! Po zmianie pliku /etc/exports należy zrestartować serwer nfs (/etc/init.d/nfs-kernel-server restart) oraz wykonać: /etc/init.d/rpcbind restart