Generowanie kluczy SSH Ed25519 w PuTTY i konfiguracja na serwerach Linux/AIX

Klucze SSH to podstawa bezpiecznego połączenia z serwerami. Zaskakująco dużo osób nadal nie wykorzystuje tej możliwości lub generuje nadal klucze RSA. Tak więc ściągawka – jak wygenerować nowoczesną parę kluczy SSH Ed25519 w środowisku Windows przy użyciu PuTTY, a następnie skonfigurować je na zdalnym serwerze Linux lub AIX.

Ten tutorial pozwoli Ci całkowicie wyeliminować konieczność wpisywania hasła przy każdym logowaniu SSH, używając najnowocześniejszej technologii kryptograficznej.

Dlaczego Ed25519, a nie RSA?

Ed25519 to przyszłość SSH! Oto dlaczego warto porzucić RSA:

🚀 15x mniejszy klucz (68 vs 1024+ znaków)
Błyskawiczna generacja i weryfikacja
🛡️ Wyższe bezpieczeństwo przy mniejszym rozmiarze
🔒 Odporność na ataki timing i side-channel
Wspierany przez wszystkie nowoczesne systemy (OpenSSH 6.5+, 2014)

Porównanie kluczy:

# Ed25519 (nowoczesny)
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGQs7X9f8Vk... szydell@laptop-2025

# RSA (przestarzały)  
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDExample123VeryLongKeyHereAndItGoesOnAndOn... szydell@laptop-2025

1. Instalacja PuTTY i przygotowanie środowiska

Jeżeli jeszcze nie masz zainstalowanego PuTTY, pobierz pełny pakiet ze strony: https://www.putty.org/

Uwaga: Pobierz cały pakiet (MSI Installer, najpewniej 64bit), nie tylko putty.exe. Będziemy potrzebować dodatkowo PuTTYgen do generowania kluczy.

Po instalacji powinny być dostępne następujące programy:

  • PuTTY – klient SSH
  • PuTTYgen – generator kluczy
  • Pageant – agent kluczy SSH
  • PSCP/PSFTP – narzędzia do transferu plików

2. Generowanie pary kluczy Ed25519 w PuTTYgen

2.1 Uruchamianie PuTTYgen

Znajdź i uruchom PuTTYgen z menu Start lub z katalogu instalacji PuTTY.

2.2 Wybór typu klucza Ed25519

W głównym oknie PuTTYgen:

  1. W sekcji „Parameters” z dropdown menu „Type of key to generate” wybierz EdDSA
  2. W polu „Curve to use for generating this key” zostaw Ed25519 (domyślna opcja)
  3. Usuń/zignoruj wartość w polu „Number of bits” – Ed25519 ma stały rozmiar klucza (256 bitów, ale bezpieczeństwo jak RSA 4096!)
  4. Kliknij przycisk „Generate”

Dlaczego Ed25519? To najnowocześniejszy standard używany przez GitHub, GitLab i wszystkie wielkie firmy technologiczne. Oferuje maksymalne bezpieczeństwo przy minimalnym rozmiarze.

2.3 Generowanie entropii

Po kliknięciu „Generate” pojawi się pasek postępu, a PuTTYgen poprosi Cię o poruszanie myszką nad pustym obszarem okna.

Ed25519 generuje się błyskawicznie – wystarczy kilka sekund poruszania myszką!

2.4 Konfiguracja wygenerowanego klucza

Po zakończeniu generowania zobaczysz znacznie krótszy klucz publiczny – to normalne i właściwe dla Ed25519!

  1. Pole z kluczem publicznym
  2. Pole „Key comment” – wpisz tutaj opisową nazwę, np.: szydell@laptop-ed25519-2025
  3. Pole „Key passphrase” – wpisz tutaj silne hasło zabezpieczające klucz prywatny lub nie wpisuj, jeżeli nie chcesz podawać hasła do klucza przy logowaniu (mniej bezpieczna opcja).

Przykład komentarza: Użyj opisowej nazwy jak szydell@laptop-ed25519-2025 – pozwoli Ci to łatwo identyfikować klucze w przyszłości.

2.5 Zapisywanie kluczy

To jest kluczowy moment – zapisz oba klucze!

  1. Kliknij „Save public key” i zapisz jako id_ed25519.pub
  2. Kliknij „Save private key” i zapisz jako id_ed25519.ppk

Uwaga: PuTTY zapisuje klucze prywatne w formacie .ppk (PuTTY Private Key), który jest specyficzny dla tego narzędzia.

  1. BONUS: Zaznacz i skopiuj cały tekst z górnego pola (klucz publiczny) – przyda się za chwilę!

Przykład tego, co skopiujesz:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGQs7X9f8VkqZU5b2Pk8... szydell@laptop-ed25519-2024

3. Sprawdzenie kompatybilności serwera

Zanim przejdziemy dalej, sprawdźmy czy Twój serwer obsługuje Ed25519:

3.1 Sprawdzenie wersji SSH

Zaloguj się na serwer przez PuTTY (jeszcze hasłem) i wykonaj:

# Sprawdź wersję OpenSSH
ssh -V

# Sprawdź dostępne algorytmy kluczy
ssh -Q key

Ed25519 jest obsługiwany od:
OpenSSH 6.5+ (2014) – praktycznie wszystkie nowoczesne systemy
Linux: wszystkie aktualne dystrybucje
AIX 7.2+ z najnowszymi aktualizacjami
Stare systemy: jeśli masz OpenSSH starszy niż 6.5, użyj ECDSA P-256

Jeśli widzisz ssh-ed25519 na liście – jest dobrze! 🎉

4. Kopiowanie klucza publicznego na serwer docelowy

4.1 Logowanie na serwer przez PuTTY

Uruchom PuTTY i zaloguj się na swój serwer Linux/AIX przy użyciu hasła (jeszcze ostatni raz! 😉).

4.2 Tworzenie katalogu .ssh (jeśli nie istnieje)

# Sprawdź czy katalog .ssh istnieje
ls -la ~/.ssh

# Jeśli nie istnieje, stwórz go
mkdir ~/.ssh

# Ustaw odpowiednie uprawnienia (BARDZO WAŻNE!)
chmod 700 ~/.ssh

Dlaczego 700? Katalog .ssh może być dostępny tylko dla właściciela. Inne uprawnienia to poważny problem bezpieczeństwa.

4.3 Dodawanie klucza publicznego do authorized_keys

Teraz dodamy Twój klucz Ed25519 do pliku authorized_keys:

# Przejdź do katalogu .ssh
cd ~/.ssh

# Stwórz/edytuj plik authorized_keys
vi authorized_keys

4.4 Wklejanie klucza publicznego Ed25519

W edytorze:

  1. Wklej skopiowany wcześniej klucz publiczny (powinien zaczynać się od ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...)
  2. Jeden klucz = jedna linia – Ed25519 jest krótki, więc łatwo się mieści
  3. Zapisz i zamknij plik

Przykład zawartości pliku authorized_keys z kluczem Ed25519:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGQs7X9f8VkqZU5b2Pk8qJ3... szydell@laptop-ed25519-2024

4.5 Ustawianie uprawnień do pliku authorized_keys

To jest krytyczne dla bezpieczeństwa:

# Ustaw uprawnienia do odczytu tylko dla właściciela
chmod 600 ~/.ssh/authorized_keys

# Sprawdź poprawność uprawnień
ls -la ~/.ssh/

Serwer powinien zwrócić coś takiego:

drwx------ 2 szydell szydell 4096 Dec 15 10:30 .
drwxr-xr-x 3 szydell szydell 4096 Dec 15 10:29 ..
-rw------- 1 szydell szydell  98 Dec 15 10:30 authorized_keys

5. Konfiguracja PuTTY do używania klucza Ed25519

5.1 Konfiguracja połączenia w PuTTY

  1. Uruchom PuTTY
  2. W polu „Host Name” wpisz adres swojego serwera
  3. W lewym menu rozwiń „Connection”„SSH”„Auth”„Credentials”

5.2 Wskazanie klucza prywatnego Ed25519

W sekcji „Authentication parameters”:

  1. Kliknij „Browse…” obok pola „Private key file for authentication”
  2. Wybierz zapisany wcześniej plik id_ed25519.ppk
  3. Ważne: Upewnij się, że widzisz ścieżkę do pliku w polu tekstowym

5.3 Zapisanie sesji

Żeby nie konfigurować tego za każdym razem:

  1. Wróć do „Session” w lewym menu
  2. W polu „Saved Sessions” wpisz nazwę, np. moj-serwer-ed25519
  3. Kliknij „Save”

6. Połączenie z kluczem Ed25519

  1. Kliknij „Open” w PuTTY
  2. System powinien zapytać o passphrase do klucza prywatnego (nie hasło użytkownika!), lub nie pytać w ogóle jeżeli hasło nie zostało ustawione.
  3. Po wpisaniu passphrase powinno nastąpić zalogowanie bez podawania hasła użytkownika

Przegraj (uszkodzony) dysk na dysk używając Linuxa

Scenariuszy do rozwiązania tego tematu jest sporo. Przetrenowałem ostatnio dwa.
A zaczęło się od wyzwania – dostałem stary dysk HDD, który trzeba było sklonować na SSD. Dysponowałem laptopem i jednym adapterem SATA<->USB. Niestety nie mogłem przez to przegrać danych bezpośrednio z dysku na dysk.

Podejście pierwsze – Zrób spakowaną kopię dysku do pliku, a następnie wypakuj na nowe urządzenie.

Zdecydowałem się na pakowanie w locie, ponieważ chciałem, aby obraz klonowanego dysku zajmował możliwie mało miejsca. Mam bardzo dobre doświadczenia z pakowaniem danych programem zstd. Postanowiłem więc z niego skorzystać. Stworzenie spakowanej kopii dysku do pliku:

$  zstd -16 -v -T0 </dev/sdX >/katalog/backup.zst
(-16 <- poziom kompresji, -v <- opowiadaj co robisz, -T0 <- policz ile jest cpu w komputerze i używaj ich)

Wypakowanie na nowy dysk:

$ zstdcat -v /katalog/backup.zst >/dev/sdX

    Wszystko by było super, gdyby nie okazało się, że dysk źródłowy ma bad sectory.

    Podejście drugie – lekko uszkodzone źródło

    Podejście drugie – Skorzystaj z ddrescue

    W moim przypadku źródłowy dysk został wyjęty z działającego komputera. Założyłem więc, że utrata kilku sektorów danych nikomu nie zaszkodzi. Postanowiłem użyć ddrescue – narzędzia, które potrafi ponowić próbę odczytu danych (-r3 <- trzykrotnie), ale też zignorować błędy i kopiować dalej to co warte uratowania. Nowa komenda to:

    $ ddrescue -d -r3 /dev/sdX /katalog/backup.img /katalog/backup.logfile

    A następnie wgrałem tak przygotowany obraz na nowy dysk:

    $ ddrescue -f /katalog/backup.img /dev/sdX /katalog/clone.logfile

    Mission accomplished 🙂

    Benchmark karty graficznej na Linuksie z użyciem superposition

    Chcesz zweryfikować jak wydajnie działa twoja karta graficzna na Linuksie? W 2024 polecam Unigine Superposition od unibenchmark. Oczywiście ten benchmark jest dostępny w wersji natywnej dla systemu linux.

    Benchmarkowanie karty graficznej wymaga poprawnej konfiguracji systemu. Pamiętaj o konieczności instalacji driverów.

    W celu zainstalowania superposition pobierz go z tego adresu https://benchmark.unigine.com/superposition. a następnie uruchom plik Unigine_Superposition-x.x.run. Program wypakuje się do podkatalogu z którego go uruchomisz. Stworzy też skrót na pulpicie, z którego można go odpalać.

    Jak używać? Jeżeli testowane GPU jest to jedyna karta w Twoim komputerze, to najzwyczajniej odpal benchmark.

    Przy kilku kartach graficznych sprawdź ich numery, np. korzystając z vulkaninfo. Zapewne numer 0 to będzie Twoją zintegrowaną kartą graficzną, potem kolejny numer lub numery to karty dodatkowe, z akceleracją 3d.

    Gdy chcesz przetestować kartę NVIDIA, uruchom benchmark definiując wcześniej zmienne środowiskowe __GLX_VENDOR_LIBRARY_NAME i __NV_PRIME_RENDER_OFFLOAD. W RENDER_OFFLAD podajemy numer karty odczytany z vulkaninfo.

    __GLX_VENDOR_LIBRARY_NAME=nvidia __NV_PRIME_RENDER_OFFLOAD=1 ./Superposition

    Dla karty AMD, należy zmienną DRI_PRIME z numerem karty odczytanym z vulkaninfo. W moim przypadku było to:

    DRI_PRIME=2 ./Superposition

    Oczywiście powyższe komendy należy wpisywać w konsoli. Jeżeli jednak nie lubisz takiego podejścia, to możesz zedytować skrót, który superposition założyło na pulpicie. Na KDE wygląda to tak:

    Zapełniony /boot na Fedorze?

    Fedora i wiele innych dystrybucji zakłada przy instalacji dedykowaną partycję /boot. Nie jest ona jakoś przesadnie wielka, bo i nie musi. Gdy jednak wgrywamy aktualizacje na bieżąco, może dojść do sytuacji w której dojdzie do jej przepełnienia. Przy próbie aktualizacji systemu komendą dnf może to wyglądać jak poniżej:

    Error Summary
    -------------
    Disk Requirements:
       At least 29MB more space needed on the /boot filesystem.
    

    Co więc zrobić gdy /boot ma twoim jest pełny? Komenda poniżej skasuje wszystkie kernele inne niż ten na którym pracujesz:

    sudo dnf remove --oldinstallonly -y

    A może nie chcesz kasować wszystkich na wypadek konieczności powrotu do starszej wersji? Możesz skasować bez np. dwóch najnowszych:

    dnf remove --oldinstallonly --setopt installonly_limit=2 kernel

    Komendy te możesz zastosować też na Amazon Linux 2023, Nobara Linux, czy Red Hat Enterprise Linux od wersji 8 w górę.

    Logo Linux Fedora
    Fedora Linux

    Nobara Linux Logo
    Nobara Linux

    logo programu Podman

    docker/podman search

    docker search – przydatna funkcjonalność, do przeszukiwania repozytoriów.

    Osobiście używam główne do znalezienia dostępnych kontenerów UBI od red hata. 🙂

    docker search registry.access.redhat.com/ubi

    Inne używane czasami zastosowanie, to wyszukanie przygotowywanych przez fedoraproject kontenerów np. w danej wersji fedory:

    [root@laPtak ~]# podman search registry.fedoraproject.org/f39
    NAME                                                 DESCRIPTION
    registry.fedoraproject.org/f39/flatpak-kde5-runtime  
    registry.fedoraproject.org/f39/flatpak-kde5-sdk      
    registry.fedoraproject.org/f39/flatpak-kde6-runtime  
    registry.fedoraproject.org/f39/flatpak-kde6-sdk      
    registry.fedoraproject.org/f39/flatpak-runtime       
    registry.fedoraproject.org/f39/flatpak-sdk  

    Tak znalezione kontenery można pobrać później korzystając z komendy docker/podman pull.

    Moduły nvidia nie ładują się

    Po reinstalacji systemu na Fedora 38, zainstalowałem jak zawsze drivery nvidii. Niestety tym razem okazało się, że po reboocie moduły się nie załadowały, a próba skorzystania z karty graficznej o większej mocy kończy się błędami, w których przewijało się słowo 'key’, oraz

    X Error of failed request:  BadValue (integer parameter out of range for operation)

    Przyczyna? Nieoczywista. Włączyłem secure boot, a moduły kernela nie były podpisane.

    Weryfikacja:

    [root@laPtak ~]# mokutil --sb-state
    SecureBoot enabled

    Naprawa:

    sudo dnf remove kmod-nvidia-*
    sudo dnf install akmod-nvidia
    
    

    Następnie wykonaj instrukcję z pliku:

    /usr/share/doc/akmods/README.secureboot
    Logo Linux Fedora
    Logo projektu Let's Encypt i firmy OVH

    SSL/TLS z Let’s Encrypt dla domen w OVH.

    Let’s Encrypt ma plugin dla OVH, skorzystamy więc z niego w poniższym tutorialu. Opisuje w nim krok po kroku jak skonfigurować automatyczne generowanie i odświeżanie certyfikatów z wykorzystaniem dns-01 challenge.

    Instrukcja ta ma zastosowanie tylko gdy Twoja domena hostowana jest przez OVH, wykorzystywać bowiem będziemy API tej firmy.

    Pokazane rozwiązanie pozwala na generowanie certyfikatów dla pojedynczych domen, oraz wildcardów.

    Żeby było jeszcze ciekawiej, skorzystamy z oficjalnego obrazu certbot/dns-ovh, także tutorial ten można zastosować praktycznie na każdym linuxie z dockerem lub podmanem. No i przy okazji jest szansa, że będzie przez jakiś czas aktualny. 😉

    1. Generowanie credentiali w OVH

    Na stronie https://api.ovh.com/createToken/ musimy wypełnić formularz w celu wygenerowania danych używanych później do tworzenia i kasowania wpisów dns. Zgodnie z dokumentacją pluginu certbot-dns-ovh, by móc potwierdzić bycie właścicielem domeny na potrzeby uzyskania certyfikatu Let’s Encrypt, będziemy potrzebować dostępu do następujących metod udostępnionych przez API OVH:

    • GET /domain/zone/*
    • PUT /domain/zone/*
    • POST /domain/zone/*
    • DELETE /domain/zone/*

    Tak wygląda formularz, który wypełniłem dla swojego rozwiązania:

    OVH API, Creating API Keys for your script

    Klikamy na 'Create keys’, jeżeli macie skonfigurowane 2FA OVH poprosi o zatwierdzenie akcji, a rezulatem będzie tabelka zawierająca:

    1. Script name
    2. Script Description
    3. Application Key
    4. Application Secret
    5. Consumer Key

    Notujemy z boku te wartości, będą za chwilkę potrzebne.

    2. Konfiguracja certbota

    Kolejny krok polega na stworzeniu pliku zawierającego dane pozwalające na autentykację w api OVH. Muszą się w nim znaleźć cztery kluczowe informacje – dns_ovh_endpoint, dns_ovh_application_key, dns_ovh_application_secret, dns_ovh_consumer_key.

    Ja założyłem ten plik w /etc/certbot/ovh-secrets.conf. Pamiętajcie, że raczej nie chcecie, żeby ktoś mógł tworzyć, czy kasować subdomeny w waszym imieniu, także zabezpieczcie ten pliczek. Powiedzmy, że wystarczy chmod 0600 /etc/certbot/ovh-secrets.conf.

    Przykładowy plik konfiguracyjny:

    dns_ovh_endpoint = ovh-eu
    dns_ovh_application_key = 7rPawafweAJYWNvhH
    dns_ovh_application_secret = 4SFtGD012npocan90nc0qkTWBflirSEf8oo
    dns_ovh_consumer_key = Et3lLNe2fthx3MeMFaHe3ssoS71qQZHZ
    
    Jeżeli przygotowujesz konfigurację dla infrastruktury zarządzanej przez OVH w Ameryce Północnej, parametr dns_ovh_endpoint powinien mieć wartość ovh-ca. 

    3. Katalogi, uprawnienia, selinux

    Przygotuj potrzebne do działania katalogi i ustaw odpowiednie uprawnienia. W tym tutorialu przyjmuję, że certbot będzie uruchamiany jako root i chcemy trzymać certyfikaty w głównej strukturze systemu (/etc, /var).

    mkdir /etc/letsencrypt /var/lib/letsencrypt /var/log/letsencrypt
    chmod 0700 /etc/letsencrypt /var/lib/letsencrypt /var/log/letsencrypt
    

    3.1 SELinux?

    Na Fedorze SELinux zablokował mi certbota przy próbie zapisu do powyższych katalogów. Jako, że będzie do nich pisać tylko ta aplikacja, ustawiłem/dodałem im kontekst container_file_t.

    # semanage fcontext -a -t container_file_t '/etc/letsencrypt'
    # restorecon -v /etc/letsencrypt/
    # semanage fcontext -a -t container_var_lib_t /var/lib/letsencrypt
    # restorecon -v /var/lib/letsencrypt
    # semanage fcontext -a -t container_file_t /var/log/letsencrypt
    # restorecon -v /var/log/letsencrypt
    

    3.2 Logrotate

    Jak można się domyślić po tym, że zakładamy dedykowany katalog w /var/log, będziemy zbierać logi. Logi zbyt długo trzymane to zło, także dodaj sobie do katalogu /etc/logrotate.d pliczek certbot, którego zawartość to:


    Dzięki temu będziemy trzymać logi przez 60 dni, no i log będzie 'łamany’ codziennie. Co oczywiste chcemy też starsze logi pakować, a użyjemy do tego komendy xz.

    4. Pierwsze uruchomienie

    Podman czy Docker?

    To zależy… Ja pracuję na Fedorze, lubię podmana i w tutorialu będę używał komendy podman.

    Co gdy używasz Dockera?
    Składnia jest identyczna, także zamień słówko podman na docker i wszystko będzie działać bez problemu. 🙂

    podman run \
     --rm \
     --name letsencrypt \
     -v /etc/certbot/ovh-secrets.conf:/ovh-secrets.conf \
     -v /etc/letsencrypt:/etc/letsencrypt \
     -v /var/lib/letsencrypt:/var/lib/letsencrypt \
     -v /var/log/letsencrypt:/var/log/letsencrypt \ 
     certbot/dns-ovh:latest certonly \
       --non-interactive \
       --agree-tos -m twój@email.pl \ 
       --dns-ovh
       --dns-ovh-credentials /ovh-secrets.conf \
       --dns-ovh-propagation-seconds 10 \
       -d example.com -d *.example.com -d innadomena.pl

    Ło panie, a dłuższej tej komendy się nie dało? Przeanalizujmy linia po linii co tu się dzieje:

    1. podman run – uruchom kontener (możesz zmienić na docker run, jeżeli używasz dockera)
    2. –rm – posprzątaj po zakończeniu życia kontenera
    3. –name letsencrypt – kontener ma się nazywać letsencrypt
    4. -v ścieżka_na_serwerze:ścieżka_w_kontenerze – te pliki i katalogi z serwera będą dostępne w kontenerze. Tam gdzie sobie zażyczyliśmy.
    5. certbot/dns-ovh:latest certonly – uruchamiamy najnowszą wersję kontenera dns-ovh. To w nim zainstalowany jest certbot, wraz z naszym pluginem do ovh. Instruujemy certbota, że ma działać w trybie 'certonly’.
    6. –non-interactive – nie chcemy być zbyt rozmowni i odpowiadać na pytania
    7. –agree-tos -m twój@email.pl – zgadzamy się na licencję i podajemy swojego maila, żeby Let’s Encrypt wiedziało z kim gadać na temat domen, którym wystawi certyfikat. W praktyce mail jest używany do powiadomienia, że certyfikat niedługo wygaśnie.
    8. –dns-ovh – odpal challenge dns01 z wykorzystaniem pluginu dns-ovh
    9. –dns-ovh-credentials /ovh-secrets.conf – plugin musi wiedzieć jak się zalogować do OVH, także pokazujemy mu gdzie leży przygotowany przez nas config.
    10. –dns-ovh-propagation-seconds 10 – halt! Dajmy ovh 10 sekund, żeby się zdążyła dodać domena.
    11. -d, -d, -d, -d itd. – Lista domen dla których chcemy dostać certyfikaty.

    Przykładowy log:

    # podman run --rm --name letsencrypt -v /etc/certbot/ovh-secrets.conf:/ovh-secrets.conf -v /etc/letsencrypt:/etc/letsencrypt -v /var/lib/letsencrypt:/var/lib/letsencrypt certbot/dns-ovh:latest certonly --agree-tos -m mój@email.pl  --dns-ovh --dns-ovh-credentials /ovh-secrets.conf --dns-ovh-propagation-seconds 10 -d example.com -d *.example.com
    
    Requesting a certificate for example.com and example.com
    Waiting 10 seconds for DNS changes to propagate
    
    Successfully received certificate.
    Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
    Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
    This certificate expires on 2021-10-28.
    These files will be updated when the certificate renews.
    
    NEXT STEPS:
    - The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.
    Saving debug log to /var/log/letsencrypt/letsencrypt.log
    
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    If you like Certbot, please consider supporting our work by:
     * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
     * Donating to EFF:                    https://eff.org/donate-le
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    5. Mamy certyfikat, co dalej?

    Zapewne po coś ten certyfikat był ci potrzebny. Apache httpd? Nginx? Haproxy? W tym tutorialu nic o nich nie będzie, ale tak. To są programy w których możesz użyć uzyskane właśnie certy.

    5.1 Odnawianie

    Po przeczytaniu loga na 100% (jak nie na 100000!) rzuciła ci się w oczy informacja, że certyfikaty trzeba odnawiać, i są raczej dość krótko ważne. Co z tym zrobić?

    Stwórz sobie pliczek /usr/local/bin/certbot_renew.sh (albo o innej nazwie!) i nadaj mu prawa do wykonywania (chmod +x /usr/local/bin/certbot_renew.sh).
    Do środka wrzuć wywołanie certbota w trybie 'renew’, oczywiście w stylu dns-ovh. Żeby mieć pewność, że korzystam z najnowszej wersji kontenera dns-ovh, dorzuciłem jeszcze podman pull na początku:


    Odpalamy testowo:

    # vi /usr/local/bin/certbot_renew.sh
    # chmod +x /usr/local/bin/certbot_renew.sh
    # /usr/local/bin/certbot_renew.sh
    Trying to pull docker.io/certbot/dns-ovh:latest...
    Getting image source signatures
    ...
    Copying blob 0b99e4c5dcd1 [--------------------------------------] 0.0b / 0.0b
    Copying config be6f9c73b8 done  
    Writing manifest to image destination
    Storing signatures
    be6f9c73b8127bdd5983728deba3644efffb6826ff4d9be6757b2cf60c4aef5f
    
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Processing /etc/letsencrypt/renewal/example.com.conf
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Certificate not yet due for renewal
    
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    The following certificates are not due for renewal yet:
      /etc/letsencrypt/live/example.com/fullchain.pem expires on 2021-10-28 (skipped)
    No renewals were attempted.
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Saving debug log to /var/log/letsencrypt/letsencrypt.log
    

    5.2 systemd service i timer

    Mamy już działający skrypcik, który gdy będzie czas odnowi certyfikaty. Wypadałoby teraz go uruchamiać cyklicznie. Cron jest trochę passe, także treningowo zróbmy to przy użyciu systemd.

    Stwórz plik /etc/systemd/system/certbot_renew.service:


    Następnie timer, który będzie go uruchamiać (/etc/systemd/system/certbot_renew.timer):


    Pozostaje nam już tylko przeładować ustawienia i włączyć timer:

    # systemctl daemon-reload
    # systemctl enable certbot_renew.timer 
    Created symlink /etc/systemd/system/timers.target.wants/certbot_renew.timer → /etc/systemd/system/certbot_renew.timer.
    

    Podsumowanie i aftercare Let’s Encrypt + OVH

    Raz zdefiniowany proces odświeżania certyfikatów powinien być bezobsługowy, pamiętajmy jednak, że dobrze jest czasem zajrzeć do logów:

    • journalctl -u certbot_renew.service
    • cat /var/log/letsencrypt/letsencrypt.log

    No i na szczęście Let’s encrypt jest o tyle miłe, że w razie czego ostrzeże mailowo, gdy odnowienie certa nie wykona się o czasie.

    Logo Windows 10

    Czas do zablokowania ekranu, Windows 10

    To totalne wariactwo, ale okazuje się, że standardowo w Windows 10 nie ma opcji pozwalającej na ustawienie po jakim czasie ma się zablokować ekran. Na szczęście da się ją włączyć w rejestrze.
    Jak więc ustawić czas do zablokowania ekranu? Odpalamy regedit’a i szukamy klucza:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\7516b95f-f776-4464-8c53-06167f40cc99\8EC4B3A5-6868-48c2-BE75-4F3044BE88A7

    Następnie w parametr Attributes ustawiamy na 2. Standardowo będzie tam 1. W rezultacie odblokuje nam się opcja 'Limit czasu wyłączenia ekranu blokady konsoli’. Znaleźć ją można też bardzo prosto, ścieżka to:

    Panel sterowania -> Sprzęt i dźwięk -> Opcje zasilania -> Edytowanie ustawień planu -> Zmień zaawansowane ustawienia zasilania

    W nowo otwartym okienku, szukamy na liście rozwijanej:

    Ekran -> Limit czasu wyłączenia ekranu blokady konsoli

    I wreszcie możemy ustawić sobie taki czas, jaki nam odpowiada.

    Ściana z czerwonej cegły, a za nią monitor. Obok napis firewalld

    firewalld – przekierowywanie portów

    Lubię firewalld. Nie zawsze jednak pamiętam składnię firewall-cmd.
    Szybka notatka jak zestawić przekierowanie portu na inne ip i port.

    Uruchom jako root:

    # firewall-cmd --permanent --zone=public --add-forward-port=port=80:proto=tcp:toport=8080:toaddr=10.1.1.10

    Rezultatem tej komendy będzie ustanowienie przekierowania z portu 80(port) twojej maszyny, na port 8080(toport) maszyny o adresie 10.1.1.10(toaddr). Jeżeli chcesz przekierować porty wewnątrz jednego hosta, pomiń część 'toaddr’.

    Co dalej? Standardowo:

    # firewall-cmd --reload
    # firewall-cmd --list-all

    Pamiętaj, że samo przekierowanie portu może nie wystarczyć. Musisz go mieć otwartego. W tym celu wykonaj dodatkowo komendę:

    # firewall-cmd --add-port=80/tcp --permanent
    # firewall-cmd --reload

    I zweryfikuj czy pojawia się na liście otwartych portów:

    #firewall-cmd --list-all

    Przekierowanie oczywiście można też usunąć.
    Wystarczy zamienić w komendzie dodawania słówko add na remove:

    # firewall-cmd --permanent --zone=public --remove-forward-port=port=80:proto=tcp:toport=8080:toaddr=10.1.1.10
    

    Firewalld powinien ogłosić sukces, a nam pozostaje tylko załadować zmiany do pamięci komendą firewall-cmd –reload.