Podczas konfiguracji yubikey do tego aby działało jako przechowywanie kluczy do ssh mobaxterm poinformował nie że działa w trybie 32 bitów i czy nie chce sie przełaczyć na 64bity. Wtedy zaczeły sie problemy z ssh-agent. Jednak w tym samym czasie zainstaloiwałem sobie pakiet do openpgpg i myślałem że to własnie to powodowało problemy:
ssh-add -L
error fetching identities: agent refused operation
Druga możliwość wykorzystania yubiko do logowania się do linux’a poprzez ssh to PIV.
Ogólnie poleca on na wykorzystaniu certyfiaktu przechowywanego na yubikey. Do wykoryztsania tego potrzebna jest aplikacja z yubikey Yubico PIV Tool (yubico-piv-tool) a do logowania biblioteka: libykcs11.so lub libykcs11.dll
Podczas próby uruchomienia logowania do ssh z kluczem yubikey poprzez fido napotkałem opis że nie działa z windows. Majac jakiś bład nie analizowałem dokładniej co to zonacza tylko myślałem że to własnie taki problem, jednak okazało sie to nie prawdą, wiec majac WSL Debian zaczałem próbowac najpier z nim. Napotkałem na samym początku problem z tym że Debian nie widział uzrądzeń po usb zatem zaczałem szukać i udał mi sie cos takiego. Czytaj dalej
Skoro juz mam cześciowo wdrożone yubikey, to szkoda nie skorzystać z opcji jaką daje czyli logowanie po ssh. Tutaj mamy 3 opcje: PIV, GPG i FIDO. Fido wydawało mi się najlepsze rozwiązanie więc zacząłem od tego, ale oczywiście dalej opisze następne rozwiązania.
Jak przygotowywałem sie do tego znalazłem gdzieś informację że po pierwsze wersja ssh musi być co najmniej 8.1 jak i windows nie wspiera tego, jednak udało mi sie to uruchomić na windows.
Na synology zaczałem robić dodatkowe kopie, jednak aby było bezpieczniej chciałm uzyć szyfrowania GPG. Do tego potrzebne jest klucz GPG, jednak fajnie było by mieć klucz prywatny z hasłem. Normalnie na linux wykonuje gpg – –full-generate-key i odpowiadałem na pytania. Jednak wersja na synology nie działa od ręki dosataję error:
gpg: agent_genkey failed: No pinentry
Key generation failed: No pinentry
EKS anywhere (EKSA) to kubernetes od AWS któey możemy uruchomić na własnych maszynach. MOzna także wykupić wsparcie. Uruchomić można na docekrze ( jako środowisko dev), na vshere i jako bare metal. Nie można jednak mieszać, ja jako opis wybiore sobie bare metal, jednak uruchomie to na proxmox. Do poprawnego działania zaleca się co najmniej 4 maszyny jako controlplane , z których 3 będą używane, a 4-ta bedzie wykorzystywana podczas upgrade. Workery także musi być najmniej jeden wiecej aby zrobić migrację. Można mieć kilka grup maszyn, np. taki jako storage, jako GPU, jako CPU itp. Dokumentacja Amazon EKS Anywhere
Poprzednio opisałem jak za pomocą serwisu podnieść proxmoxbmc, jednak coraz częściej pojawiają się kontenery, i tutaj też nie zabraknie konteneryzacji. Zatem można proxmoxbmc-docker . Co daje takie wykorzystanie no to że nic nie instalujemy, możemy podnieść to na każdej maszyny i będzie działało, o ile ma docker’a. Tak samo jak poprzednie warto, a nawet trzeba wykorzystać dodatkowe adresy IP na wirtualne interfejsy. Trzeba traktować takie IP jako IP do zarzadzania po BMC (iLO i inne konsole do zdalnego zarządzania serwerem). Wewnątrz kontenera nie musimy już pilnować porów, bo podczas uruchamiania kontenera mapujemy konkretne IP i konkretny port na port wewnątrz kontenera, tylko trzeba poprawnie mapować, dlatego zalecam napisać skrypt, lub inną automatyzacje, unikniemy jakiś nieścisłości i błędów w mapowaniu.
Za pomocą docker exec możemy dodawać, wyświetlać zarządzać.
Cel opisu to wstęp do tego jak wykorzystać eks anywhere bare metal viurtualki na proxmox. EKSA w topologii bare metal wykorzystuje tinkerbell, który to zarządza maszynami za pomocą BMC. Majać virtualke w proxmox (vShare także) nie mamy dostepu do wirtulki za pomocą BMC (IPMI) ale mamy dostep za pomoca API. Nie potrzebujemy całej fukncjonalności BMC tylko start,stop,restart,status. do tego wykorzystamy proxmoxbmc.
Od jakiegoś czasu zajmuje się EKS Anywhere, jest to wersja kuberntesa która jest w AWS, jednak ta wersja jest przeznacozna na serwery we własnej serwerowni. Nie erozpisując się za dużo o EKSA, zacząłem sobie w domowym lab stawiac własny klaster do testowania. Wykorzystuję wersję bare metal, która to wykorzytuje BMC do zarzadzania serwerami, jednak nie mam tylu serwerów dlatego bedę wirtualizował w proxmox, a łącznikiem bedzie serwis proxmoxbmc, jest tez wersja na VMware jednak koszty sa duże. No ale to później na tą chwilę skupmy sie jak to bedzie dizałało. Czytaj dalej
Jak mamy kilka maszyn i kilka krótkich zadań to nie potrzebny nam jest jenkins jako master i slave. Jednak jak już nam się rozrasa projekt można zlecać wykonanie pewnych zadań bezpośrednio na serwerze za pomocą klientów na zdalnych maszynach.