Archiwum kategorii: Linux

Rozwiązanie problemu z tokenami OTP w KeePassXC z KeePass 2

O tym, że posiadanie menadżera haseł jest czymś (wydawałoby się w naszym środowisku) oczywistym – wiedzą chyba wszyscy. Nawet te osoby, które na co dzień z takich narzędzi nie korzystają. Kwestia bezpieczeństwa, złożoności haseł i posiadania do każdego serwisu innego hasła jest podstawą „życia” w sieci. Użytkownicy dzielą się na różne obozy, związane z różnymi narzędziami tego typu. Począwszy od rozwiązań płatnych, jak i bezpłatnych; tych opartych o chmurę i tych offline. Każde jednak pomaga nam w gromadzeniu haseł.

Od wielu lat (z przerwami na LastPass) używam narzędzia o nazwie KeePass 2. Jest to bezpłatny menadżer haseł, który posiada liczne forki na różne platformy. Pół roku temu zrezygnowałem również na rzecz KeePass z Google Authenticator dla tokenów OTP. Uważam to tym samym za jedną z lepszych decyzji do tej pory – nie dlatego, że KeePass jest niezastąpiony, czy chcę coś złego na temat GAuth napisać. Po prostu jest to mega wygodne, gdzie w jednym programie mam dostęp do hasła i tokenu.

Nie dalej, jak przedwczoraj chciałem zmienić swojego sprawdzonego KeePassa na KeePassXC, który ma zdecydowanie współcześniejszy design, działa szybciej, a co najważniejsze jest multiplatformowy – jeden program, na róże systemy, ta sama funkcjonalność. No i napotkałem na problem:
Klucze zapisane w KeePass 2 nie generują tokenów w KeePassXC…

Krótki research i okazało się, że jeden z drugim programem nie rozumie nawzajem kluczy zapisanych w polach o nazwie TimeOtp-Secret-Base32 dla KeePass 2, oraz otp dla KeePassXC.

Klucz OTP zapisany w KeePass 2, nie działający na KeePassXC

Klucz OTP zapisany w KeePass 2, nie działający na KeePassXC

Rozwiązanie? Wystarczy zduplikować klucz, ale pod nazwą otp. W tym celu klikamy prawym przyciskiem myszy na wpis / TOTP / Ustaw TOTP / wklejamy wartość klucza do pola. Tyle :)

I bez większego problemu będziemy mieć teraz tokeny na KeePass 2, KeePassXC oraz na KeePass2Adndroid – którego z kolei planuję w przyszłości wymienić na KeePassDX – zdecydowanie najładniejszy fork KP na Androida. Natomiast ma jeszcze problemy w funkcjonalności, których nie ma KP2A.


KeePass, jako alternatywa dla Google Authenticator, czyli 2-step Verification

Przyznam się bez bicia, że do niedawna jeszcze korzystałem z Google Authenticator, do podwójnej weryfikacji (tzw. 2-step Verification, aka. 2fa). Gdzieś z tyłu głowy siedzi sobie myśl, by uwolnić się od Google, ile tylko się da, a dodatkowo GAuth ma pewien problem – nie da się zrobić kopii zapasowej kluczy. Już raz utraciłem dostęp do kont i musiałem go odzyskiwać. Jedyna opcja na kopię, to przeniesienie kluczy na inne urządzenie i potem powrót na urządzenie właściwe.

To było takim zapalnikiem by poszukać innego rozwiązania. Pierwszym wyborem miał okazać się Aegis Authenticator. W zasadzie tylko dlatego, że rozwiązywał problemy/braki, które posiadał GAuth, czyli:

  1. Możliwość zrobienia kopii zapasowej (nie bez powodu #1 na liście);
  2. Nie jest od Google i/lub jest OpenSource;

Ale gdzieś pomiędzy komentarzami, przewinął się KeePass. I tutaj było moje zdziwienie, bo z ów menadżera haseł korzystam z mniejszymi, lub większymi przerwami od bardzo dawna. Nie wiedziałem, że posiada on taką funkcję wbudowaną. Dodatkowo dzięki niemu jest możliwość korzystania z haseł jednorazowych bezpośrednio na komputerze, z pominięciem telefonu. Rozwiązanie o tyle genialne w swojej prostocie, że:

  1. Nie potrzebuję telefonu by się zalogować;
  2. Jak zgubię telefon, nie tracę dostępu do kont;
  3. Mam bazę w kilku miejscach (czytaj bezpieczeństwo).

Wziąłem się więc za pełną migrację z GAuth na KeePass.


Niedziałające WiFi na starym laptopie z Debianem 10.10

Na dnie szafy spoczywał u mnie stary laptop MaxData. Z racji na to, że Windows XP jest mocno po terminie, a laptop w takowy fabrycznie był wyposażony, to pozostało mi zainstalować jakiegoś pingwinka. Wielkiego pola do manewru tutaj też nie było, ponieważ działa on jeszcze na 32 bitowej architekturze. Wstępnie miał tam stanąć {{Ubuntu}}, lecz x86 porzucili w 2018 roku (owszem jest jeszcze LTS 18.04). Stanęło na {{Debian|Debiana}}, który wspiera jeszcze x86. Jeden jedyny problem, jaki napotkałem w trakcie konfiguracji, to niedziałające WiFi. Co też po krótkim researchu udało się ogarnąć.

Włączenie repozytoriów non-free

Pierwsza rzecz do zrobienia – włączenie repozytoriów non-free. Problemem bowiem okazuje się sterownik, który nie wspiera tak starego modułu WiFi. No i oczywiście potrzeba połączyć się kabelkiem z siecią ;).

sudo nano /etc/apt/sources.list
deb http://deb.debian.org/debian buster main contrib non-free
deb-src http://deb.debian.org/debian buster main contrib non-free
 
deb http://deb.debian.org/debian-security/ buster/updates main contrib non-free
deb-src http://deb.debian.org/debian-security/ buster/updates main contrib non-free
 
deb http://deb.debian.org/debian buster-updates main contrib non-free
deb-src http://deb.debian.org/debian buster-updates main contrib non-free
sudo apt update
sudo apt upgrade

Instalacja „starego” sterownika

sudo apt install firmware-iwlwifi

Tyle. Ma działać.


Instalacja WireGuard na Ubuntu 19.10

Po kilku latach korzystania z {{VPS}} na {{OpenVZ}} u ViPower.pl – nadszedł czas na zmiany. Po pierwsze, zmiana usługodawcy – i tutaj padło na OVH.pl. Po drugie, postanowiłem zmienić system wirtualizacji na {{Kernel-based_Virtual_Machine|KVM}}. Po trzecie, w związku z przenosinami, chciałem zmienić dystrybucję z {{CentOS}} na {{Ubuntu}}. A po czwarte i ostatnie, skoro już wszystko konfigurowałem od zera, naszło mnie na zmianę {{OpenVPN}} na {{WireGuard}}, o którym czytałem sporo dobrego.

Konfiguracja i instalacja {{WireGuard|WireGuarda}} to czysta poezja. W przeciwieństwie do {{OpenVPN}} nie było żadnych kombinacji i komplikacji. Tym bardziej, że w moim przypadku tunel działa zarówno w celu przekierowywania całego ruchu przez serwer, jak i tworzenia sieci wewnętrznej. Jedyne problemy, na jakie napotkałem, dotyczyły wyłącznie konfiguracji firewalla i przekierowywania przez niego ruchu. Wszystkie opisy, jakie znajdywałem, nie rozwiązywały mojego problemu. Pomocny okazał się mój wpis sprzed lat z konfiguracji OpenVPN i te same reguły dla iptables.


Ubuntu 16.10 jako główny OS, podejście xxx

Lat temu kilka, porzuciłem Windowsa, jako mój główny system operacyjny, na rzecz Ubuntu, Mandrivy oraz openSUSE. Tak przez dwa lub więcej lat. Później nadszedł czas, że powróciłem do Windowsa, bowiem W7 miał wszystko, co potrzebowałem i działał bezproblemowo. Czego o Linuksie nigdy powiedzieć tego nie mogłem – sprawiało mi to frajdę, że coś tam trzeba było zrobić.

W roku pańskim 2017 postanowiłem dać szansę pingwinkowi. Postawiłem na Ubuntu, który to postrzegany jest za najbardziej user friendly. Rozwija się najszybciej i w dobrym (wg mnie) kierunku. Cóż rzec mogę… zachwycił mnie od pierwszego wejrzenia, po instalacji i aktualizacji.