Menu

Česky

BredySoft

K čemu to je?

Představ si, že máš hromadu serverů a hromadů klientů, kterými se připojuješ k té hromadě serverů. Pro každého klienta bys měl mít vygenerovaný jeden pár klíčů a na každém serveru pak mít nahraný seznam všech public klíčů, kterými si na ně chceš připojovat. Na každý server tedy musíš nakopírovat tento soubor a to pokaždé, když tam přidáš, nebo smažeš nějaký klíč.

A tak mě napadlo, jestli by to šlo nějak spravovat centrálně. Jako že strýček google nenašel nic rozumně jednoduchého, napsal jsme si to sám. Je to napsané jako několik scriptů v bashi, nic složitého

Jak to nainstalovat?

  • Jednoduše, například tak, že celý projekt nakopíruju do nějaké složky v /usr/local, například /usr/local/sshman
  • Ujistím se že všechny soubory v /usr/local/sshman/src jsou spustitelné a vlastní je root (všechno by měl vlastnit root)
  • Vytvořím symlink v /usr/local/bin/sshmanager který ukazuje na /usr/local/sshman/src/sshmanager
  • Otevřu si config: /etc/ssh/sshd_config a dopíšu tam následující řádky:
    AuthorizedKeysCommand /usr/local/bin/sshmanager
    AuthorizedKeysCommandUser root
  • a nakonec otočíme ssh démona: service ssh restart

Tak a máme nainstalováno. Jen pozor, pokud tam lezeš přes ssh, nemělo by ti teď spadnout spojení. Kdyžtak se ta část s úpravou sshd_config dá přesunout až nakonec. Protože sshd momentálně nepůjde, neboť nám chybí nastavení

Jak to nastavit?

Nejprve je třeba vybrat centrální místo. To klidně může být nějaký veřejný webhosting, kde si vytvoříš složku, kam pak nakopíruješ patřičný soubor, který bude dostupný z internetu. Není třeba se bát, že by ho někdo zákeřně změnil, aby se dostal do tvých strojů, protože ten soubor bude pochopitelně podepsaný.

Pokud ještě nemáš takové místo připravené

  • Na nějakém důvěryhodném stroji si vyrob složku.
  • na tom stroji bys měl mít nainstalovaný sshmanager (tento projekt)
  • napiš: /usr/local/sshman/src/easysetup mojeklice - místo mojeklice si napiš co chceš
  • skript vytvoří soukromý klíč (mojeklice.key) a veřejný klíč (mojeklice.pub) a dále pak soubor do kterého nakopíruje tvé authorized_keys a ještě ti tam vygeneruje další klíč, jehož soukromou část uloží do mojeklice.id_rsa - tohle není povinnost tam mít, ale jde o to, abys tam vůbec něco měl, pokud authorized_keys nemáš vůbec založený nebo prázdný.
  • nakonec ti ten soubor zabalí a vznikne mojeklice.gz.sign, což je onen podepsaný centrální soubor, který si uploaduješ na svůj webhosting.

Když budeš chtít později obsah souboru změnit a přidat tam nějaké další klíče, nebo je smazat, tak uděláš následující

  • upravíš soubor mojeklice
  • napiseš sshmanager pack mojeklice mojeklice.key - samozřejmě, musíš mít k dispozici ten soukromý podepisovací klíč
  • Otestuješ, že je to správně zabaleno sshmanager test mojeklice.gz.sign - předpokládá, že máš sshmanager správně nastaven
  • a opět uploadujes mojeklice.gz.sign na webovku

Pokud už máš takové místo připravené

Budeš potřebovat URL toho místa. Dále pak veřejnou část podepisovacího klíče, např. mojeklice.pub

  • otevřeš /usr/local/sshman/conf/sshmanager.conf
  • Změníš položku SOURCE_URL na tu URL, kam sis vystavil ten gz.sign soubor
  • Změníš cestu na PUBLIC_KEY - to předpokládá, že ten veřejný klíč nakopíruješ na ten cílový stroj někam, kde k němu má sshmanager přístup. Nabízí se přímo složka conf, takže pak stačí napsat $CONFIGPATH místo cesty
    SOURCE_URL=http://blablabla..../mojeklice.gz.sign
    PUBLIC_KEY="$CONFIGPATH/mojeklice.pub"

Všechno nastaveno, testujeme...

Když je to nastavené, můžeme to testnout

    $ sudo sshmanager root

Při správné funkci by se měl objevit obsah toho podepsaného souboru. Jiného uživatele než root nezkoušej, protože ve výchozím stavu to poskytuje jen klíče pro root. Nesmí tě taky zarazit, že ve výsledku se mohou objevit i klíče z rootovského authorized_keys. To je správná funkce, umožňuje to lokálně dodat další klíče nezávisle na centrální správě.

Použití

Jakmile to je odzkoušeno, ověříme, že sshd_config je nastaven správně a ssh démon restartován, zkusíme se přihlásit přes ssh na stroj jako root. Pakliže máme správnou identitu a správné klíče, mělo by to chodit!

Možnosti další konfigurace

Centrální konfigurace

Soubor s klíčema umožňuje další vychytávky kromě úložiště ssh klíčů. Samozřejmě se předpokládá, že na každém řádku je jeden klíč a zpravidla ve formě ssh-rsa /rozsypaný_čaj/ jméno. Kromě toho lze do tohoto souboru dávat konfigurační příkazy. Momentálně existují dva

  • user:
  • host:

Každý příkaz musí být na samostatné řádce a musí být přepsán přesně tak jak je uvedeno, bez mezer před příkazem a bez mezer před dvojtečkou (za dvojtečkou mezera povolená je). Platnost každého příkazu začíná následujícím řádkem a končí buď na konci souboru, nebo novým použitím téhož příkazu s jinými argumenty.

Příkaz user: umožňuje určit, pro jakého uživatele se budou importovat následující ssh klíče. Lze napsat víc uživatelů a odděluje se to mezerou. Nebo lze napsat all a tím se myslí všichni uživatelé. A nebo lze napsat uživatele s vykřičníkem, pak vybraný uživatel je ze seznamu vynechán

Příklady

    user: franta lojza root
    user: all
    user: all !root

Jenom pozor, že se to vždy vyhodnocuje zleva doprava. Takže záleží na pořadí all !root znamená, že všichni kromě root. Avšak !root all způsobí, že nejprve se root vypne a následně se povolí všichni (včetně roota)

Příkaz host: funguje naprosto stejně, pouze se vztahuje na hostname stroje

Příklady

    host: dev db master production
    host: all
    host: all !master

Kromě toho lze do obou příkazů vložit libovolnou přesnou specifikaci uživatele na konkrétním stroji

Příklad

    user: all
    host: all !master !franta@dev

to znamená, že následující klíče se importují všem uživatelům na všecho strojích, kromě master a kromě uživatele franta na stroji dev

Příklad

    user: root franta@dev
    host: all

to znamená, že následující klíče se importuju rootům na všech strojích, a zárověn uživatel franta na stroji dev.

Konfigurace na konkrétním stroj

Na některých strojích a na jejich účtech je občas potřeba s klíči zacházet jinak, než je jen prostě skopírovat do authorized_keys. Například pro přístup do svn přes ssh tunel je třeba aby v authorized_keys byly uvedeny nějaké další příkazy. Tohle lze samozřejmě vyřešit tak, že to napíšeme přímo do těch klíčů v centrálním souboru, ale mimojiné to lze řešit i tak, že ke konkrétnímu účtu napíšeme, nebo připojíme filtr. Filtr se definuje souborem

    $HOME/.ssh/sshmanager_filter

Soubor musí být spustitelný. Pokud existuje, pro každý řádek v centrálním soubor, který by se měl importovat do authorized_keys se provede tento filter tak, že se vyvolá s dvěma argumenty: <ssh-line> a <$HOME>. Předpokládá se, že filtr vypíše na standardní výstup upravenou ssh-line, která se pak naimportuje do authorized_keys</ssh-line>

Takto je zatím definovaný svnfilter, který upravuje ssh-line tak, aby patřičný účet bylo možné použít jako tunel pro subversion. Použití je následující

  • vytvoříme link třeba v /home/svn/.ssh/sshmanager_filter ukazující na /usr/local/sshman/src/svnfilter
  • vytvoříme link v /home/svn/repositories ukazující na root složku svn repozitářů

kdokoliv má nyní klíč povolený v centrálním souboru klíčů pro účet svn na konkrétním stroji, ten obdrží tunel ssh+svn a může vesele verzovat.

Co je třeba ještě vědět

Cache

Aby se při každém přihlášení nelezlo na web, ukládají se naimportované klíče do cache. Ta se nachází v /usr/local/sshman/cache TTL cache najdeš v configu. To má třeba za následek, že změna klíčů v centrálním souboru se nemusí projevit ihned, pokud se cache sestavila těsně před změnou.

Failstate - co když se něco podělá.

Podělat se mohou dvě věci. Jednak server ztratí přístup k centrálnímu úložišti. Nebo někdo do centrálního úložiště nakopíruje nepodepsaný soubor, nebo jej změní, takže podpis přestane platit. V tom případě se bere poslední stav z cache tak dlouho, dokud to někdo neopraví


MongoDB Logo MongoDB