<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Raspbian on Morfitronik</title>
    <link>https://morfikov.github.io/tags/raspbian/</link>
    <description>Recent content in Raspbian on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Sat, 13 Nov 2021 13:26:00 +0100</lastBuildDate><atom:link href="https://morfikov.github.io/tags/raspbian/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Wsparcie dla WiFi w initramfs/initrd by odszyfrować LUKS przez SSH bezprzewodowo</title>
      <link>https://morfikov.github.io/post/wsparcie-dla-wifi-w-initramfs-initrd-by-odszyfrowac-luks-przez-ssh-bezprzewodowo/</link>
      <pubDate>Sat, 13 Nov 2021 13:26:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/wsparcie-dla-wifi-w-initramfs-initrd-by-odszyfrowac-luks-przez-ssh-bezprzewodowo/</guid>
      <description>&lt;p&gt;W poprzednim artykule, który traktował o &lt;a href=&#34;https://morfikov.github.io/post/odszyfrowanie-luks-przez-ssh-z-poziomu-initramfs-initrd-na-raspberry-pi/&#34;&gt;odszyfrowaniu kontenera LUKS przez SSH z poziomu
initramfs/initrd na Raspberry Pi&lt;/a&gt;, została poruszona kwestia adresacji IP, która w opisanym tam
rozwiązaniu miała pewne ograniczenia. Chodziło o to, że połączenie SSH do RPI mogło być realizowane
jedynie przez przewodowy interfejs sieciowy &lt;code&gt;eth0&lt;/code&gt; . Trzeba było zatem się zastanowić nad
rozwiązaniem, które umożliwiłoby korzystanie również z bezprzewodowego interfejsu WiFi, tj.
&lt;code&gt;wlan0&lt;/code&gt; . Celem niniejszego wpisu jest pokazanie w jaki sposób można dorobić wsparcie dla
połączeń WiFi w naszej malinie, tak by szło odszyfrować kontener LUKS przez SSH, w sytuacji gdy z
jakiegoś powodu nie chcemy lub też nie możemy korzystać z przewodowego interfejsu sieciowego tego
minikomputera z zainstalowanym system RasPiOS/Raspbian.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Odszyfrowanie LUKS przez SSH z poziomu initramfs/initrd na Raspberry Pi</title>
      <link>https://morfikov.github.io/post/odszyfrowanie-luks-przez-ssh-z-poziomu-initramfs-initrd-na-raspberry-pi/</link>
      <pubDate>Fri, 12 Nov 2021 23:13:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/odszyfrowanie-luks-przez-ssh-z-poziomu-initramfs-initrd-na-raspberry-pi/</guid>
      <description>&lt;p&gt;Od paru dni bawię się swoim Raspberry Pi w kontekście zaszyfrowania jego systemu RasPiOS/Raspbian.
O ile samo &lt;a href=&#34;https://morfikov.github.io/post/jak-zaszyfrowac-raspberry-pi-raspios-raspbian-luks/&#34;&gt;zaszyfrowanie tego minikomputera przy pomocy mechanizmu LUKS&lt;/a&gt; nie było jakoś
specjalnie trudne, to trzeba było pomyśleć nad rozwiązaniami mającymi ułatwić otworzenie takiego
zaszyfrowanego kontenera przy starcie systemu. Póki co udało się wypracować w miarę zadowalające
&lt;a href=&#34;https://morfikov.github.io/post/wykorzystanie-nosnika-usb-jako-klucz-do-odszyfrowania-raspberry-pi/&#34;&gt;rozwiązanie wykorzystujące dedykowane urządzenia USB w roli klucza&lt;/a&gt;, bez którego system się nie
uruchomi. Są jednak i inne rozwiązania, które mogą nam pomóc odszyfrować system RPI bez potrzeby
fatygowania się do pomieszczenia i wtykania w jej port USB jakiegoś pendrive. Mowa o zaprzęgnięciu
usługi SSH, która by została uruchomiona w fazie initramfs/initrd, chwilę przed wpisaniem hasła do
kontenera LUKS. Takie rozwiązanie wymaga jednak zainstalowania innego serwera SSH, tj. Dropbear,
pogodzenia go z serwerem OpenSSH oraz też trzeba odpowiednio przygotować sam obraz initramfs/initrd.
Po pomyślnym skonfigurowaniu systemu, będziemy się logować do Raspberry Pi przez SSH i wpisywać
hasło do kontenera LUKS, a jeśli to hasło będzie prawidłowe, to system zostanie odszyfrowany i
uruchomiony.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Wykorzystanie nośnika USB jako klucz do odszyfrowania Raspberry Pi (LUKS)</title>
      <link>https://morfikov.github.io/post/wykorzystanie-nosnika-usb-jako-klucz-do-odszyfrowania-raspberry-pi/</link>
      <pubDate>Thu, 11 Nov 2021 05:32:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/wykorzystanie-nosnika-usb-jako-klucz-do-odszyfrowania-raspberry-pi/</guid>
      <description>&lt;p&gt;Ostatnio udało mi się &lt;a href=&#34;https://morfikov.github.io/post/jak-zaszyfrowac-raspberry-pi-raspios-raspbian-luks/&#34;&gt;zaszyfrować swojego Raspberry Pi 4B przez wdrożenie kontenera LUKS&lt;/a&gt; i
upchnięcie w nim wszystkich danych z partycji &lt;code&gt;/&lt;/code&gt; zainstalowanego w tym urządzeniu systemu
RasPiOS/Raspbian. To jednak nie był koniec pracy, bo taki zaszyfrowany system na RPI ma szereg wad.
Tym główniejszym uniedogodnieniem jest wpisywanie hasła na początku fazy boot, by pełny start
systemu był w ogóle możliwy. Sytuacja się komplikuje, gdy do naszego minikomputera nie mamy
podłączonego monitora i/lub klawiatury. Ten zaistniały problem można rozwiązać na kilka sposobów,
np. przez zaprzęgnięcie do pracy dodatkowego nośnika USB w celu umieszczenia na nim pliku klucza
(keyfile). Niemniej jednak, można pójść o krok dalej i wykorzystać samo urządzenie jako klucz i gdy
takiego pendrive nie podłączymy do portu USB naszej maliny, to system nam się nie uruchomi. Te dwa
rozwiązania są bardzo podobne do siebie ale to drugie jest nieco bardziej odporne na ewentualne
problemy ze skasowaniem pliku klucza, co może nam się przytrafić, gdy taki pendrive jest
wykorzystywany w roli regularnego nośnika danych przechowującego dla niepoznaki jakieś pliki. Tak
czy inaczej oba te sposoby zostaną opisane w niniejszym artykule.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak zaszyfrować Raspberry Pi (RasPiOS/Raspbian, LUKS)</title>
      <link>https://morfikov.github.io/post/jak-zaszyfrowac-raspberry-pi-raspios-raspbian-luks/</link>
      <pubDate>Sun, 07 Nov 2021 22:17:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-zaszyfrowac-raspberry-pi-raspios-raspbian-luks/</guid>
      <description>&lt;p&gt;Ostatnio napisał do mnie pewien osobnik, który miał dość spory problem z zaszyfrowaniem swojego
Raspberry Pi. Po wymianie kilku maili zacząłem tracić rozeznanie w całej tej sytuacji i doszedłem
do wniosku, że najwyraźniej zaszyfrowanie systemu maliny nie jest rzeczą trywialną. Postanowiłem
zatem rzucić okiem na swojego RPI i sprawdzić czy są tutaj faktycznie jakieś odstępstwa od
tradycyjnego szyfrowania na bazie LUKS w stosunku do szyfrowania spotykanego w pierwszej lepszej
dystrybucji linux&#39;a, takiej jak Debian czy Ubuntu. Pobrałem więc ze strony Raspberry Pi najnowszy
obraz systemu RasPiOS/Raspbian, wrzuciłem go na kartę SD przy pomocy &lt;code&gt;dd&lt;/code&gt; i okazało się, że w
zasadzie większych problemów z zaszyfrowaniem mojej maliny nie było. Przyznać trzeba, że informacje
na temat szyfrowania RPI, które można spotkać na internetach, są w przeważającej większości bardzo
słabej jakości i mam wrażenie, że pisane przez osoby, które nie do końca się zainteresowały
poruszanym przez siebie zagadnieniem. Postanowiłem zatem na przykładzie mojego Raspberry Pi 4B
opisać w miarę dokładny sposób od początku do końca jak przeprowadzić cały ten proces szyfrowania
danych na karcie SD, którą podpinamy do naszego minikomputera.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Chroot do 32-bit systemu ARM z poziomu 64-bit linux&#39;owego hosta</title>
      <link>https://morfikov.github.io/post/chroot-do-32-bit-systemu-arm-z-poziomu-64-bit-linuxowego-hosta/</link>
      <pubDate>Sun, 07 Nov 2021 10:20:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/chroot-do-32-bit-systemu-arm-z-poziomu-64-bit-linuxowego-hosta/</guid>
      <description>&lt;p&gt;Eksperymentując ostatnio z moją maszynką Raspberry Pi 4B, zaszła potrzeba, by zejść do systemu
RasPiOS/Raspbian przy pomocy mechanizmu chroot. Problem w tym, że system wyrzuca  komunikat:
&lt;code&gt;chroot: failed to run command ‘/bin/bash’: Exec format error&lt;/code&gt; . Niby wszystko jest na swoim
miejscu ale ta widoczna wyżej wiadomość nie chce zniknąć uniemożliwiając tym samym dalszą zabawę z
RPI. Okazało się, że winna jest tutaj architektura CPU. Mój laptop działa pod kontrolą 64-bitowego
Intel&#39;owskiego procesora (x64, x86-64, AMD64), na którym uruchomiony jest również 64-bitowy Debian
linux. Z kolei Raspberry Pi ma 64-bitowy procesor ARM (ARMv8-A) działający pod kontrolą 32-bitowego
systemu operacyjnego. Te dość spore rozbieżności sprawiają, że nie damy rady skorzystać z chroot,
przynajmniej nie bez zaprzęgnięcia do tego celu emulatora QEMU.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
