Infrastruktura PKI na podstawie SSH

Infrastruktura kluczy publicznych (ang. Public Key Infrastructure, w skrócie PKI) jest podstawą współczesnej kryptografii. Miałem już styczność z wieloma osobami z branży IT, które kompletnie nie czuły o co właściwie w tym chodzi.Myślę, że poniższy tekst napewno się komuś przyda oraz, że warto mu poświęcić 5 minut. Spróbuję się maksymalnie streścić

Klucze symetryczne i niesymetryczne

Większość szyfrowanych kanałów transmisji wykorzystuje jednocześnie klucze niesymetryczne jak i symetryczne.

Zaletą kluczy symetrycznych (takich jak AES, Blowfish czy DES) jest szybkość szyfrowania/deszyfrowania przy stosunkowo niskim obciążeniu procesora.

Wadą kluczy symetrycznych jest etap nawiązania transmisji. Jeśli oba komputery nie posiadają tego samego klucza do szyfrowania/deszyfrowania wiadomości – klucz taki musiałby być wysłany z jednego z nich do drugiego drogą nieszyfrowaną. Taką wymianę klucza można byłoby łatwo podsłuchać. Następnie, korzystając z tak zdobytego klucza – można podsłuchać resztę transmisji (taki atak nosi nazwę Man In The Middle).

Dlatego właśnie pojawiły się klucze niesymetryczne (np. stosowany standardowo w protokole ssh – algorytm RSA). Klucz niesymetryczny składa się z dwóch części – publicznej i prywatnej. Posiadacz części publicznej klucza jest w stanie zaszyfrować wiadomość. Posiadacz klucza prywatnego – może taką wiadomość odszyfrować. Proste. Dodatkowo – na podstawie klucza publicznego jesteśmy w stanie zweryfikować odcisk klucza (fingerprint) – jeśli się zgadza, wiemy, że rozmawiamy z właściwym serwerem.

Klucze w praktyce

Serwery Linuxowe na których pracuje usługa ssh mają również wygenerowane swoje klucze. Autentykacja może być różnoraka, jednak do najpopularniejszych należą – para użytkownik-hasło oraz łączenie się z wykorzystaniem kluczy.

Wykorzystanie haseł jest proszeniem się o kłopoty. Warto przesiąść się na klucze. Jak to zrobić?

Wygenerujmy sobie klucz. W obecnych czasach warto zaznaczyć, że chcemy mieć klucz 4096-bitowy, będzie się generował dłużej, ale będzie bezpieczniejszy. Warto też ustawić hasło dla klucza.

nme@notebook ~ $ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nme/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nme/.ssh/id_rsa.
Your public key has been saved in /home/nme/.ssh/id_rsa.pub.
The key fingerprint is:
12:30:87:ca:06:81:d8:5a:32:41:81:4c:3a:74:33:a9 nme@notebook
The key's randomart image is:
+--[ RSA 4096]----+
|XO.++..          |
|X.+.++           |
|oB..  .          |
|.E+    .         |
| .    . S        |
|       .         |
|                 |
|                 |
|                 |
+-----------------+
nme@notebook ~ $

W katalogu .ssh pojawiły się dwa pliki id_rsa – będący naszym kluczem prywatnym oraz id_rsa.pub – czyli klucz publiczny.
Klucza publicznego nie trzeba specjalnie strzec. Ważne, aby nasz klucz prywatny nie dostał się w cudze ręce.

Po co ten obrazek w ASCII? Abyśmy nie musieli weryfikować znak po znaku naszych kluczy. Jeśli chcemy odczytać fingerprint klucza, wydajemy komendę:

ssh-keygen -l

Jeśli chcemy zobaczyć odcisk wraz z obrazkiem ASCII – wydajemy:

ssh-keygen -lv

Okej. Powiedzmy, że mamy klucze i serwer na który chcielibyśmy się łączyć za ich pomocą. Musimy umieścić zawartość naszego klucza publicznego w pliku .ssh/authorized_keys na serwerze docelowym. Możemy to zrobić komendą:

nme@notebook ~ $ ssh-copy-id serwer:
The authenticity of host 'serwer (x.x.x.x)' can't be established.
RSA key fingerprint is fe:2b:6b:71:6f:81:ef:07:74:89:72:e7:ef:ab:f8:62.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'serwer,x.x.x.x' (RSA) to the list of known hosts.
Password:
nme@notebook ~ $

teraz możemy już normalnie się zalogować:

nme@notebook ~ $ ssh serwer
nme@serwer ~ $

W pliku .ssh/authorized_keys możemy trzymać dowolną ilość kluczy.

Dobrą praktyką jest generowanie kluczy prywatnych na każdej stacji roboczej z której łączymy się na inne maszyny. W wypadku gdy np. ktoś ukradnie nam jedną z tych maszyn – wystarczy usunąć dane klucze z plików authorized_keys serwerów, do których mamy dostęp.

Skoro już opanowaliśmy klucze – warto wyłączyć autoryzację do naszych serwerów za pośrednictwem par użytkownik-hasło. Robimy to edytując plik /etc/ssh/sshd_config – weryfikujemy ustawienia:

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Restart sshd we współczesnych Ubuntu czy RedHatach wykonujemy komendą:

sudo service ssh restart

Kiedy wyłączymy już logowanie na pary użytkownik-hasło i pozostawimy jedynie logowanie na klucze:

nme@notebook ~ $ ssh serwer
Permission denied (publickey).
nme@notebook ~ $

Gdzie poza SSH stosowane są jeszcze klucze?

Infrastruktura kluczy publicznych (PKI) stosowana jest również przykładowo w HTTPS czy w sieciach bezprzewodowych – WPA2 (AES). Klucze niesymetryczne stosowane są do nawiązania transmisji między klientem i serwerem – celem wymiany klucza symetrycznego, a następnie transmisja jest już oparta o klucz symetryczny.

Znajomość ogólnych zasad działania PKI jest bardzo praktyczna również w przypadku, jeśli przymierzamy się do wykorzystania OpenPGP czy certyfikatów SSL, które możemy traktować jak wyższe stopnie zaawansowania

Wprowadzenie do systemu kontroli wersji Mercurial

Poniższy tekst jest jedynie wprowadzeniem do pracy z Mercurialem. Osoby które chcą pogłębić swoją wiedzę w zakresie tego tematu – zachęcam do przeczytania darmowej książki dostępnej w Internecie – Mercurial: The Definitive Guide.

Aby pracować na Mercurialu musimy go najpierw zainstalować. Dla systemu Windows Mercurial jest jedną wygodną do zainstalowania paczką. Informację jak zalecam to zrobić pod Ubuntu, zamieściłem tu: Instalacja Mercurial z GUI TortoiseHG pod Ubuntu 9.04.

Konfiguracja wstępna

Zanim rozpoczniemy pracę z Mercurialem, należy w swoim katalogu domowym utworzyć plik .hgrc w którym konfigurujemy swojego użytkownika. Plik ten powinien zawierać następującą treść:

[ui]
username = Imie Nazwisko < konto@domena.pl >

Pod Linuxem lub Unixem warto również ustawić zmienną środowiskową EDITOR wskazującą na nasz
ulubiony edytor. W moim wypadku, w pliku .bashrc w katalogu domowym
musiałem dodać na końcu linijkę:

export EDITOR="vim"

W tym momencie możemy już przystąpić do pracy.

Tworzenie repozytorium

Załóżmy, że jesteśmy w katalogu testy.

Utwórzmy w nim plik notatki.txt zawierający jedną linijkę tekstu:

To są moje notatki

Utwórzmy też katalog dokumenty, a w nim umieśćmy plik do-zrobienia.txt zawierający następującą treść:

[ ] Zrobić przelewy za październik
[ ] Podać do Energetyki stan licznika

Struktura plików i katalogów wygląda zatem następująco:

user@host testy $ ls
dokumenty  notatki.txt
user@host testy $ ls dokumenty/
do-zrobienia.txt

Możemy w tym momencie utworzyć sobie repozytorium Mercuriala. Przechodzimy zatem do katalogu testy i wydajemy komendę:

user@host testy $ hg init

W katalogu powinien pojawić się podkatalog .hg

Co teraz możemy zrobić? Dostępne komendy pojawią się po wydaniu komendy hg bez parametrów:

user@host testy $ hg
Mercurial Distributed SCM

basic commands:

 add        add the specified files on the next commit
 annotate   show changeset information by line for each file
 clone      make a copy of an existing repository
 commit     commit the specified files or all outstanding changes
 diff       diff repository (or selected files)
 export     dump the header and diffs for one or more changesets
 forget     forget the specified files on the next commit
 init       create a new repository in the given directory
 log        show revision history of entire repository or files
 merge      merge working directory with another revision
 parents    show the parents of the working directory or revision
 pull       pull changes from the specified source
 push       push changes to the specified destination
 remove     remove the specified files on the next commit
 serve      export the repository via HTTP
 status     show changed files in the working directory
 update     update working directory
 view       start interactive history viewer

use "hg help" for the full list of commands or "hg -v" for details

Jeśli chcemy uzyskać większą ilość komend, należy uruchomić polecenie
hg help.

Zobaczmy status naszego katalogu. Możemy napisać hg status, jednak można też zastosować skróconą wersję komendy:

user@host testy $ hg st
? dokumenty/do-zrobienia.txt
? notatki.txt

Widzimy, że system Mercurial widzi dwa pliki. Przed ich nazwami figuruje znak pytajnika, co oznacza, że Mercurial nie do końca wie, co to za pliki.

Dodawanie plików do repozytorium

Do dodawania plików do repozytorium służy komenda hg add [nazwa pliku], przy czym nazwa pliku jest parametrem opcjonalnym. Jeśli jej nie podamy – Mercurial doda wszystkie nieznane pliki w naszym katalogu i podkatalogach do repozytorium.
Dodajmy nasze pliki do repozytorium.

user@host testy $ hg add
adding dokumenty/do-zrobienia.txt
adding notatki.txt

podglądając status widzimy:

user@host testy $ hg st A dokumenty/do-zrobienia.txt A notatki.txt

Zatwierdzanie i weryfikowanie zmian

możemy w tym momencie zatwierdzić zmiany:

user@host testy $ hg commit

W tym momencie uruchomi się nam edytor w którym uzupełniamy pierwszą linię. Pozostałe zostały zasugerowane przez Mercuriala:

utworzone repozytorium

HG: Enter commit message.  Lines beginning with 'HG:' are removed.
HG: Leave message empty to abort commit.
HG: --
HG: user: Imie Nazwisko 
HG: branch 'default'
HG: added dokumenty/do-zrobienia.txt
HG: added notatki.txt

Jeśli chcemy którąś z tych linii pozostawić, powinniśmy usunąć HG: sprzed wpisu.

Po zapisaniu pliku, jeśli Mercurial znajdzie choć jedną linię opisu (czyli w naszym wypadku tekst “utworzone repozytorium”), zapisze to jako nową wersję (revision).

Możemy podejżeć zmiany:

user@host testy $ hg st
user@host testy $

Jak widać, nie ma żadnych. Zobaczmy zatem historię:

user@host testy $ hg log
changeset:   0:996ae301b615
tag:         tip
user:        Imie Nazwisko 
date:        Tue Oct 13 08:40:12 2009 +0200
summary:     utworzone repozytorium

user@host testy $

Dokonajmy jakiejś zmiany w pliku dokumenty/do-zrobienia.txt, powiedzmy, że teraz wygląda tak:

[x] Zrobić przelewy za październik
[ ] Podać do Energetyki stan licznika

Sprawdzając status widzimy:

user@host testy $ hg st
M dokumenty/do-zrobienia.txt
user@host testy $

Możemy też podejżeć co zostało zmienione:

user@host testy $ hg diff
diff -r 996ae301b615 dokumenty/do-zrobienia.txt
--- a/dokumenty/do-zrobienia.txt	Tue Oct 13 08:40:12 2009 +0200
+++ b/dokumenty/do-zrobienia.txt	Tue Oct 13 08:46:21 2009 +0200
@@ -1,2 +1,2 @@
-[ ] Zrobić przelewy za październik
+[x] Zrobić przelewy za październik
 [ ] Podać do Energetyki stan licznika
user@host testy $

Zatwierdzę teraz zmiany, sprawdzę status i historię:

user@host testy $ hg commit
user@host testy $ 

user@host testy $ hg st
user@host testy $ 

user@host testy $ hg log
changeset:   1:155c93da6b65
tag:         tip
user:        Imie Nazwisko 
date:        Tue Oct 13 08:48:01 2009 +0200
summary:     aktualizacja

changeset:   0:996ae301b615
user:        Imie Nazwisko 
date:        Tue Oct 13 08:40:12 2009 +0200
summary:     utworzone repozytorium

user@host testy $

Usuwanie plików z repozytorium

Teraz usunę plik notatki.txt:

user@host testy $ hg remove notatki.txt
user@host testy $ ls
dokumenty
user@host testy $

Zatwierdzę zmiany i zobaczę historię. Ograniczę sobie przy okazji historię do dwóch najaktualniejszych zmian:

user@host testy $ hg commit
user@host testy $ hg log -l 2
changeset:   2:ec95d15664fb
tag:         tip
user:        Imie Nazwisko 
date:        Tue Oct 13 08:51:36 2009 +0200
summary:     usunięte notatki

changeset:   1:155c93da6b65
user:        Imie Nazwisko 
date:        Tue Oct 13 08:48:01 2009 +0200
summary:     aktualizacja

user@host testy $

Zdecydowałem jednak, że przywrócę plik notatki. Cofnę zatem ostatniego commita komendą rollback, zobaczę jaki
jest status i przywrócę plik notatki.txt:

user@host testy $ hg rollback
rolling back last transaction
user@host testy $ hg log
changeset:   1:155c93da6b65
tag:         tip
user:        Imie Nazwisko 
date:        Tue Oct 13 08:48:01 2009 +0200
summary:     aktualizacja

changeset:   0:996ae301b615
user:        Imie Nazwisko 
date:        Tue Oct 13 08:40:12 2009 +0200
summary:     utworzone repozytorium

user@host testy $ hg st
R notatki.txt
user@host testy $ ls
dokumenty
user@host testy $ hg revert notatki.txt
user@host testy $ ls
dokumenty  notatki.txt
user@host testy $

Myślę, że jako wprowadzenie, taki opis wystarczy

Mercurial w Eclipse IDE

Środowisko programistyczne Eclipse jest jednym z najlepszych spośród tych dostępnych za darmo. Osobiście preferuję vim’a, ale większość programistów przywykło do większych luksusów

Eclipse jest dostępny zarówno pod Windows jak i pod Linuxem. Jego instalacja w systemie Microsoftu jest dość prostą czynnością.

W Linux Ubuntu, Eclipse jest niby też dostępny w standardowej dystrybucji, ale mnie osobiście nigdy nie udało się go z sukcesem uruchomić ze standardowej paczki. Tym z Was, którzy chcą z niego skorzystać pod Ubuntu zachęcam do pobrania Eclipse z ich strony, następnie rozpakowanie go do docelowego katalogu, a na koniec ręczne stworzenie skrótu.

Eclipse zostało stworzone w Javie i w zamyśle jest IDE służącym do tworzenia aplikacji właśnie w tym języku. Dzięki zaawansowanemu systemowi rozszerzeń możliwe jest jednak jego wykorzystanie do tworzenia aplikacji w innych językach. Właśnie ten mechanizm umożliwi nam również uzupełnienie Eclipse’a o system kontroli wersji.

Aby mieć możliwość z korzystania z Mercuriala, konieczna będzie jego instalacja w systemie. Dla systemu Microsoft Windows można go pobrać z tej strony. Dodatkowo warto zainstalować TortoiseHG. Kroki opisujące instalację pod Linux Ubuntu wraz z TortoiseHG opisałem tutaj.

Wtyczka Mercurial-Eclipse

Aby za pomocą środowiska Eclipse posługiwać się systemem kontroli wersji Mercurial, konieczne będzie dodanie jego repozytorium do dostępnych źródeł w Eclipse. W tym celu wybieramy Help / Install new software… / Add… i podajemy:

name: Mercurial Eclipse
location: http://www.vectrace.com/eclipse-update/

Osobiście testowałem plugina w wersji 1.4.1286 – zainstalował się i działał prawidłowo.

Po zainstalowaniu, plugin poprosi o restart środowiska Eclipse. Kiedy już Eclipse zacznie ponownie działać, powinniśmy mieć dostęp do nowej funkcjonalności.

Dość ważną kwestią jest na początku zaglądnięcie do ustawień Mercuriala – Window / Preferences, wybieramy Team / Mercurial. Należy tutaj podać Mercurial Username w postaci Imię nazwisko <adres@email>. Zaleciłbym również zaznaczenie opcji Automatically associate Mercurial with new projects containing hg repository.

Jeśli chodzi o zakładanie repozytorium dla istniejącego już projektu – w Eksploratorze workspace wybieramy projekt, naciskamy prawy klawisz myszy, następnie Team / Share project – tam wybieramy Mercurial i na następnej stronie wizarda Use project root.

Jeśli repozytorium już było założone – trzeba zaglądnąć do projektu podobnie jak przy tworzeniu nowego repozytorium, wybrać Share project, a na końcu Use existing .hg repository.

W tym momencie możemy już korzystać z bardziej urozmaiconej zawartości popup menu Team