Archiv pro rubriku: Linux

Vlastní certifikační autorita pro přihlašování k SSH

Při přihlašování k SSH jste jistě již mockrát viděli hlášku, jako je tato:

Většinou ji napoprvé bezmyšlenkovitě potvrdíme a všímáme si jí pouze v případě, že se objeví znovu. Značí to, že je něco špatně. Jak se ale této hlášce vyhnout úplně? Ověřování fingerprintu jistě nechceme vypnout, to by nebylo moc bezpečné 🙂 Jak tedy na to jinak? Založíme si pro SSH vlastní CA!

Nejprve si musíme vygenerovat podepisovací klíč.

Příkaz nám vygeneroval dva soubory ca.ed25519 a ca.ed25519.pub. Ukážu zde pouze generování pro algoritmus ED25519, pro jiné algoritmy je postup obdobný.

Nyní potřebujeme veřejný klíč serveru, ke kterému se budeme přihlašovat. Ten pak podepíšeme a podepsaný klíč nahrajeme zpět na server.

Nyní bude potřeba říct o novém certifikátu SSH serveru. Přidáme do /etc/ssh/sshd_config jeden řádek a restartujeme SSH.

Nyní můžeme na všech počítačích, které se potřebují k serveru přihlašovat, přidat do ~/.ssh/known_hosts veřejný klíč naší nové CA.

SSH se již nebude ptát na potvrzení fingerprintu. Pokud soubor přidáváe na počítač, ze kterého jste certifikáty kopírovali, máte již cílový server v known_hosts přidaný. Musíme jej tedy ještě vymazat.

Jak bezpečně distribuovat hesla v gitu

Pokud už jste někdy rozcházeli deployment aplikace pomocí gitu, asi jste narazili na problém, jak na produkční server bezpečně dostat hesla. Mít je v plaintextu v GITu moc bezpečné není 🙂 Přesto ale je způsob, jak je v gitu mít bezpečně – zašifrovat je. Jak to udělat a jak je při deploymentu do produkce rozšifrovat?

Pokud nemáte, nainstalujte si na produkčním server GPG. Na Unbuntu/Debian se to dělá takto:

Pro generování klíčů budeme potřebovat hodně entropy, doporučuji tedy nainstalovat i Haveged, viz. můj minulý článek.

Nyní se potřebujeme přepnout pod uživatele, pod kterým probíhá deployment. V mém případě je to uživatel web. Pod tímto uživatelem vygenerujeme základní keypair. Důležité: nezadávejte při generování klíčů žádné heslo, jen volbu potvrďte entrem.

Teď když máme vygenerovaný keypair, vyexportujeme veřejný klíč, nejlépe do souboru:

To by bylo pro produkční server zatím vše. Nyní si na našem vývojovém stroji vygenerujeme keypair stejně jako na produkčním serveru. Tentokrát ale doporučuji zadat heslo, na které se se vás GPG při šifrování a dalších operacích bude ptát. Poté importujeme veřejný klíč produkčního serveru.

Importovaný klíč podepíšeme, tím řekneme GPG, že důvěřujeme jeho původu:

Teď přijde ta hlavní část. Zašifrujeme veřejným klíčem produkčního serveru konfigurační soubor s hesly:

Zašifrovaný soubor .gpg pak můžeme bez problémů commitnout do gitu. Bez privátního klíče produkčního serveru jeho obsah nikdo nepřečte. Na produkčním serveru pak v deployment procesu nastavíme rozšifrování tohoto souboru pomocí privátního klíče, který už na serveru máme.

Jak zrychlit generování certifikátů v linuxu

Při generování certifikátů systém potřebuje tzv. entropy. Kolik jej systém aktuálně má můžete zjistit tímto příkazem:

Protože se entropy získává především z uživatelského vstupu, je s ním na serveru trochu problém. Tenhle problém řeší Haveged. Jak to celé pracuje je hezky vysvětleno v článku How to Setup Additional Entropy for Cloud Servers Using Haveged.

Jak vytvořit Ubuntu image pro SmartOS

Po nějaké době vás přestane bavit instalovat všechny nové VPS z ISO image. Nastal čas vytvořit si image pro imgadm. Jak na to?

Vytvoříme si prázdný VPS:

Stáhneme instalační ISO a nabootujeme z něj VPS:

Získáme info o VNC a připojíme se na něj:

Nyní nainstalujeme Ubuntu (nebo jiný OS) jak jsme zvyklí. U ubuntu ještě doporučuji pomocí F4 zvolit volbu „Install a minimal virtual machine“.

Po instalaci uděláme aktualizaci systému a reboot:

Po rebootu odstraníme staré kernely:

Volitelně také můžeme vyhodit hlavičkové soubory, které ve většině případů nejsou potřeba, ale aktualizují se zbytečně s každým kernelem:

Můžeme doinstalovat nějaké balíky. Rozhodně ale nesmíme vynechat balík acpid:

Můžeme také některé přebytečné balíky vyhodit:

Dále nainstalujeme sdc-vmtools:

P5ihlásíme se přes VNC a ostraníme uživatele, kterého jsme vytvořili při instalaci systému:

Připravíme VPS na vypnutí:

Rootovi můžeme nyní odebrat heslo:

Shodíme VPS a vratíme se do SmartOS:

Vytvoříme z VPS image:

A VPS smažeme:

Pro image potřebujeme vytvořit dsmanifest:

UUID pro creator_uuid a vendor_uuid si můžete vygenerovat příkazem uuid.

Máme image a dsmanifest, teď image můžeme nainstalovat:

A teď z image konečně vytvoříme VPS:

Nemá smysl dávat disku větší size, než je size image. Disk se stejně vytvoří podle image. Prozatím to řeším pomocí GParted. Jakmile budu vědět, jak to zautomatizovat, napíšu o tom další článek. Nebo můžete někdo poradit v diskuzi pod článkem 🙂

Dodatek: dá se to řešit takto:

Jak přejmenovat soubor, aby tak po upgradu balíčku zůstal

Asi už vás někdy napadlo nějaký nešikovný název programu v linuxu přejmenovat. To ale obvykle přináší jeden malý problém. Je potřeba to udělat po každém upgradu onoho programu. Distribuce založené na Debianu (tedy i Ubuntu) na to mají naštěstí fígl. Program dpkg-divert vám dovolí přejmenovat nebo nalinkovat soubor jinam a ten bude po upgradu balíku takto udržován.

Příkaz pak vypadá např. takto:

  • Parametr –local zajistí, že přejmenování zůstane pro všechny verze balíčku
  • Parametr –divert říká, jak se bude program jmenovat
  • Parametr –rename zajistí přejmenování místo nalinkování souboru
  • Parametr –add říká, který soubor vlastně přejmenováváme

Možnosti nasazení CEPH s ProxmoxVM a Ubuntu VPS

CEPH je velice zajímá technologie kombinujcí object storage, block storage a filesystem.

One Object Storage: The Ceph Object Store, called RADOS, is the object storage component for CephFS filesystems, Ceph RADOS Gateways, and Ceph Block Devices.

Many Storage Interfaces: You can use CephFS, Ceph RADOS Gateway, or Ceph Block Devices in your deployment. You may also use all three interfaces with the same Ceph Object Store cluster! There’s no reason to build three different storage clusters for three different types of storage interface!

Use Commodity Hardware!: You can deploy Ceph with commodity hardware. You don’t need to purchase proprietary storage or networking hardware commonly used in SAN systems.

Při testech jsem zjistil následující:

  • Pro testy je potřeba minimálně dvou OSD (nodů pro ukládání dat)
  • ProxmoxVE 2.2 kernel nemá modul rbd
  • Ubuntu virtual kernel nemá modul rbd
  • Proxmoxu ještě nějakou chvíli potrvá, než CEPH zařadí do svých balíků, zdali vůbec

CEPH si určitě zaslouží sledovat a testovat dál, ale v současném stavu bych jej v kombinaci s Proxmoxem nedoporučoval, pokud nechcete sami kompilovat a udržovat balíky.