Domácí stránka Variable computing Prague

Pojem "GNU/Linux" slučuje Linux (jádro operačního systému) a svobodný software v jeden svobodný operační systém. Zkratka GNU je rekurzivní akronym a znamená "GNU is not Unix". Projekt GNU je dílem Free Software Foundation (Nadace pro svobodný software), kterou založil Richard M. Stallman. Kernel Linux naprogramoval finský programátor Linus Torvalds. Lidé z Nadace pro svobodný software od základů znova naprogramovali obdoby proprietárního Unixového software a dali jeho zdrojové kódy k dispozice komunitě (proto ono "GNU is not Unix" - "GNU není Unix").

Jelikož však s jádrem operačního systému, které vyvíjela Nadace pro svobodný software nastaly potíže (koncepce jádra, které vyvíjí je naprosto rozdílná od Torvaldsova), bylo rozhodnuto, že bude použit Torvaldsův kernel Linux jako kernel pro nový - svobodný - operační systém. Vznikl GNU/Linux! Je též třeba dodat, že jakákoliv distribuce GNU/Linuxu je GNU/Linuxem do té míry, do které jsou programy v ní obsažené svobodným software.

V poslední době se však zapomíná na zásadní význam Nadace pro svobodný software i na poselství zkratky GNU. To je dáno mimo jiné i tím, že lidé o GNU mnoho nevědí. Také krátké heslo "Linux" je asi lépe medializovatelnější a jsou zde i tlaky ze strany firem, které vytářejí distribuce GNU/Linuxu a ze strany hnutí Open Source. Některé z těchto distribucí obsahují již bohužel i proprietární - komerční - software. Pokud tento proprietární software nainstalujete, nemůžete již svůj OS nazývat pouze "GNU/Linux". Nemůžete jej však nazývat ani "Linux", neboť "Linux" je pouze jádro.

Doporučujte tedy firmám i jednotlivcům, kteří do GNU/Linuxových distribucí zařazují proprietární software, aby tento software alespoň formálně "vyřadili" z této distribuce. Ať třeba tvrdí: "Dáváme Vám k dispozici GNU/Linuxovou distribuci. Nadto Vám na zvláštním CD dáváme k dispozici následující proprietární software, který není součástí GNU/Linuxu: …" a podobně. Jedině takto přísným rozlišováním se nám možná v budoucnu podaří GNU/Linux uchovat v té podobě, ve které jej máme rádi - ve SVOBODNÉ podobě! Zbývá jen zvolat následující…

Plaintextové soubory v DOSu mají řádky ukončeny sekvencí dvou znaků CRLF, což znamená „Carriage Return“ a „Line Feed“, neboli česky „návrat hlavičky“ a „odřádkování“ (na tiskárně, je to pozůstatek z doby, kdy ještě výstup z počítače vedl na nějaké tiskové zařízení). V Unixu oproti tomu jsou řádky ukončeny pouze znakem LF. Pokud DOSový soubor chceme číst v Unixu, nejspíše zjistíme, že obsahuje na kocích řádků nevzhledné dva znaky ^M. To je právě onen CR, který musíme odstranit a udělat tak z DOSového souboru soubor Unixový. Existuje mnoho nástrojů, pomocí nichž bychom takového výsledku mohli dosáhnout, ale jako zdaleka nejlepší se mi jeví řádkový editor sed, který se k tomuto účelu vysloveně hodí. Jako další alternativy poslouží docela dobře i editor vi popř. vim, scriptovací jazyk perl, příkaz tr a další. Věršina těchto nástrojů je přítomna v každé Unixové distribuci, tedy i v distribucích Linuxových.

Asi nejlepší způsob mimo aplikaci příkazu tr je tento pomocí řádkového editoru sed:

kde ^M lze na prikazove radce bashe a v editoru vi zapsat jako sekvenci Ctrl-V a Ctrl-M. V editoru Emacs se ^M docílí pomocí sekvence Ctrl-Q a Ctrl-M.

V prostředí editoru vi se ovšem musí za substituci přidat ‚g‘, aby se substituce provedla v celém souboru a nejen na prvním výskytu ^M, tedy:

(například, možností je v Unixu obvykle více). Ve vimu (rozšířená verze editoru vi, vi improved) lze využít volby fileformat, tedy:

Dalši alternativou je následujíci „nečistý“ způsob opět pomocí sedu:

Uvedený způsob je „nečistý“, neboť se spouští další program, což při zpracování rozsáhlého souboru může způsobit znatelné zpomalení.

Další možné zápisy využívají možnosti zapsat v sedu heximální nebo oktalový znak. Příklad by pak vypadal asi takto:

Existuje samosebou i možnost, že se rozhodneme inkriminovaný znak ^M vůbec nehledat a odmažeme jednoduše poslední znaky řádků v souboru:

a podobně.

Další elegantní methodou, která se mi velice zamlouvá je tato pomocí příkazu tr:

Perl je velice silný nástroj, ale je také poněkud pomalejší a na takovýto problém řekněme snad až příliž mohutný. Ale přesto nevidím důvod, proč bychom jej nemohli v případě potřeby použít:

A samosebou, že kromě všech uvedených příkladů možného řešení se naskýtá ještě možnost použít utilitku s názvem dos2unix, která však nemusí být přítomna v každé implementaci Unixového OS.

Co se převodu plaintextových souborů z Unixu do DOSu týče, řekněme, že to nechám na každém z Vás. Doufám, že po výčtu všech method budete již sto vymyslet řešení sami. Ale přeci jen přidám regulérní výraz, který je k tomu vhodný:

Zajímavou variantu řešení konverze z Unixového formátu do DOSového se nabízí v souvislosti s možnostmi programu awk:

Unix se vyznačuje tím, že obsahuje mnohé z myslitelných nástrojů pro řešení konkrétních problémů. To v zásadě znamená, že řešení se lze dobrat vždy, a zpravidla i vícero cestami.
GNU/Linux jako Unixový operační systém samozřejmě obsahuje mnohem více, nástrojů, způsobů a cest, než jsme si zde stačili vyjmenovat a je na každém člověku, jakou methodu si pro sebe vybere jako nejlepší. Cílem tohoto textu nebylo ukázat všechny možnosti, což by ani při obrovské variabilitě nebylo možné, ale spíše poukázat na mnohost způsobů řešení problémů.

Obvykle píši v editoru Vim v konzoli, takže na skutečnost, že mi nad velkými písmeny a některými dalšími jako například „ď“, „ť“ a „ň“ a podobně nelze v prostředí XFree86 psát háček upozornila až moje slečna, která s oblibou používá na psaní svých textů českou lokalizaci kancelářského balíku Open Office.

Nejprve jsem nechápal, proč mi „klávesnice“ odmítá psát ty zatrolené háčky nad písmenky a hledal jsem tedy nejprve chybu v nastavení vlastních XFree86, které pro klávesnici vypadá u mne asi takto:

Takže stiskem obou kláves SHIFT přepínám mezi českým QWERTY rozložením kláves a rozložením anglickým. Laborováním s hodnotami proměnných v konfiguračním souboru /etc/X11/XF86Config ale nevedlo k žádnému výsledku.

Jak se brzy ukázalo, tudy cesta k řešení problému také opravdu nevedla. Řešení totiž spočívalo v naprosto jednoduchém nastavení LOCALES, konkrétně jednoho jediného „locale“, totiž LC_CTYPE na hodnotu pro českou lokalizaci. Celý problém má tedy velice snadné řešení. Stačí spustit X-ka následujícím způsobem.

A vše běží jak má. Ostatní LOCALES není nutné zdá se vůbec nastavovat, takže kdo je nechce mít nastavené, tak nemusí, což je přesně můj případ.

Obecně nejsem nadšeným příznivcem Midnight Commanderu, neboť se domnívám, že příkazová řádka je prostě nepřekonatelná. Přesto se mi kdysi stalo, že jsem nějaký čas Midnight Commander aktivně používal. Bohužel se mi také přihodilo, že jsem si nevšiml, že mám MC spuštěn jako superuživatel a smazal si několik důležitých věcí, neboť jsem se "uklepl" při označování pomocí klávesy Insert a bezmyšlenkovitě dal vše označené smazat. Aby se mi to nemohlo podruhé stát, vytvořil jsem si pro roota poněkud jiné barevné nastavení, které vám zde předkládám, a ze kterého je zcela jasné, kterak se barvy v MC nastavují.

V /root jsem si vytvořil soubor .mccolors, jehož obsah následuje (je nutno, aby text zůstal v jediném dlouhém řádku, tj. za dvojtečkama nesmí být mezera ani přechod na nový řádek, prostě to musí být tak jak je tomu zde):

Dále jen stačí nastavit v /root/.bashrc alias mc=’mc -C `cat /root/.mccolors`’ a je to! Alternativou může být i ruční editace /root/.mc/ini, kde se pouze přidá nová sekce [Colors] a pod ní se umístí inkriminovaný řádek s definicí barevného schématu. Jak to celé vypadá je zřejmé z následujícího screenshotu.

Také máte uživatele, kteří si stěžují, že se jim "defaultní" barvy "midnighta" jaksi nelíbí? Pro ty z Vás, kteří čelíte takovému problému anebo pro ty z Vás, kteří sice nemáte žádné uživatele, ale jste již starými dobrými barvami MC tak znaveni, že jste až líní vytvořit si vlastní schémata barev pro MC jsem vytvořil jedno odlehčené čili šedivé schéma barev a taktéž jedno schéma výstředně zelené, jejichž oba screenshoty vidíte dole, ač jestliže Váš internetový prohlížeč podporuje obrázky ve formátu PNG.

Nastavení těchto barevných schémat je stejné jako u shora popsaného "rootovsky" rudého schématu s tím rozdílem, že si jej uživatel uloží do svého domácího adresáře a ve svém $HOME/.bashrc vytvoří příslušný alias pro "mc".

Tak si to užijte, ale věřte, že stará dobrá "commandlajna" je z hlediska bezpečnosti před vlastní blbostí přeci jenom o něco lepší. A co se uživatelů týče? Zde platí, že je obvykle lepší, když jsou spokojení. Ovšem, to již nechávám jen a jenom na Vaší ctěné libovůli.

Program GKrellM jako takový je poměrně dost náročný na výpočetní výkon počítače. Proto je velice vhodné využít jeho schopnosti fungovat jako daemon, to jest jako program, který sice "není na první pohled vidět", ale kterého vidí klient a bere si od něj data, která potřebuje zobrazit, než abychom spouštěli na jednom serveru třeba padesát klientů.

Daemon pro klienta GKrellM se nazývá v GNU/Linuxu zcela typicky - gkrellmd. Nejprve se podíváme, kterak démona GKrellM nakonfigurovat, aby běžel jak má a dělal vše, co od něj očekáváme (jak uvidíte, já toho mnoho neočekávám, takže pokud toho budete chtít od gkrellmd více, přečtěte si prosím jeho manuálovou stránku).

V adresáři /root si vytvořte soubor .gkrellmd.conf (nebo v adresáři [/usr/local]/etc soubor gkrellmd.conf), jehož obsah může vypadat třeba nějak takto (vše si vysvětlíme dále).

Nyní si vše poněkud podrobněji rozebereme.

Položek, které lze nastavit je samosebou více. Asi nejzajímavější je možnost spustit daemona s plug-iny, které jsou volně ke stažení na stránkách projektu. Osobně si však myslím, že je lepší pluginy pod daemonem nespouštět a učinit tak až na straně klientů. Ale pro pořádek si ukážeme ještě dva řádky z [.]gkrellmd.conf, které by nám aktivovaly plug-iny amiconnected a gkrellweather.

Ještě je třeba podotknout, že samotné pluginy, aby je gkrellmd našel, musíme umístit buď do adresáře /root/.gkrellm2/plugins-gkrellmd nebo do /usr[/local]/lib/gkrellm2/plugins-gkrellmd.

Teď již nám zbývá daemona jen a pouze sputit. Napíšeme jako superuživatel příkaz gkrellmd a vše by mělo běžet jak má.

Klient se spouští velice jednoduše. Jako uživatel napíšeme na příkazovou řádku gkrellm -s adresa_serveru -f a mělo by nám naskočit okno s GKrellMem. Poté si nastavíme téma, popř. zapneme pluginy, které chceme používat nad rámec normálních implementovaných funkcí GKrellM a nakonfigurujeme je.

Máme-li vše nastaveno jak chceme, uvažujme možnost spustit si klienta bez možnosti dalších úprav nastavení. To se dělá pomocí parametru -nc ("no config", neboli "nekonfigurovatelný"). Parametr -f tentokrát již nepoužijeme, neboť sloužil k vytvoření unikátních nastavení GKrellMu pro daného hosta, ze kterého jsme se připojili k našemu běžícímu serveru gkrellmd.

Jsme-li s výsledkem spokojeni, zavedeme si ve svém $HOME/.bashrc takovýto alias na spouštění klienta.

Nyní již můžeme našeho klienta pohodlně spouštět z terminálu, ve kterém běží BASH.

GKrellM je báječná aplikace, která by rozhodně neměla chybět v žádné distribuci GNU/Linuxu. Pravděpodobně také nechybí. Přes námitku o vysoké "žravosti" procesorového čase se její provozování jistě vyplatí. Kdo by nechtěl mít stále na očích, co se děje "v" jeho serveru? Přeji si, aby i Vám tento skvělý kus svobodného software přinášel tolik užitku jako mě.

Vytvořil jsem jednoduše vypadající téma na aplikaci GKrellM, kteréžto vidíte na screenshotu dole. Mám v X-kách obvykle nastavenu pracovní plochu bez jakýchkoli zbytečných grafických "opičáren" - to jest má pracovní plocha je černá a téma, které vidíte se k ní dle mého názoru docela dobře hodí. GKrellM mám obvykle umístěn vlevo dole, což je způsobeno buď tím, že jsem levák, anebo třeba i tím, že používám Window Maker, kde není (chvála bohu) žádná lišta.

Aby to celé (po nainstalování tématu, které je ke ztažení dole) vypadalo přesně tak, jak vidíte na screenshotu, budete ještě potřebovat nastavit vhodná písma, tak jak to vidíte na následujícím screenshotu.

Asi bych měl závěrem podotknout, že jako základ pro toto téma jsem použil téma, které se jmenuje "CoplandOS", jenž je volně ke stažení na stránkách projektu GKrellM. Mnou "derivované" téma, které shora vidíte si můžete volně stáhnout zde. Když budete k tématu mít nějaké námitky anebo přání (rozšíření na další plug-iny apod.), budu rád, když mi napíšete.

Defaultní prompt v Bourne Again Shellu (zkráceně BASH) se mi moc nelíbil, a tak jsem si ho poněkud "poohnul" k obrazu, který mi již vyhovuje lépe.

Při tvobě následujícího promptu jsem měl na mysli dvě věci: 1) Chtěl jsem, aby mě prompt upozornil, že pracuji s právy superuživatele a 2) jsem také chtěl, aby mi poněkud napověděl něco zajímavého o aktuálním adresáři, ve kterém se v shellu nalézám a o procesech. Jak to celé nakonec dopadlo ukazují oba screenshoty, které dále vidíte.

K celé věci je potřeba, abyste měli v systému nainstalovány následující programy: find, wc, tr, echo, pwd, ps, jobs date a řádkový editor sed. Tyto programy jsou ale běžně k nalezení snad ve všech distribucích GNU/Linuxu, takže byste v tomto směru neměli narazit na žádné potíže. Zároveň nedoporučuji takovýto prompt nastavovat na pomalejších strojích. Tam je lépe se spokojit s normálním promptem, popř. upravit pouze vzhled (barvy) a rozlišení uživatele a superuživatele.

První řádek promptu obsahuje jméno aktuálního adresáře a pak v závorce počet souborů, počet adresářů a počet linků. Na druhém řádku naleznete aktuální čas, jméno uživatele a v závorce je kolik procesů vám běží, kolik jich je pozastaveno a poslední exitcode. Na třetím řadku je pouze dvojtečka, která uvozuje samotný příkazový řádek.

Jak je vidět na druhém "rootovském" screenshotu, těžko byste teď stiskli enter, pokud se jedná o stroj, za který máte osobní zodpovědnost, jelikož vykřičníky Vás jistě upozorní, že by to asi nebyl tak docela dobrý nápad.

Především je třeba, aby šlo používat ANSI sekvence kvůli barvičkám. To ale obvykle není problém a vše jede jak má. Celé to funguje tak, že v podstatě nastavíme pouze proměnnou PS1 BASHe tak, jak chceme. Lze použít zmiňované ANSI sekvence, specielní sekvence (například sekvence "\n" pro přechod na nový řádek nebo "\h" pro vypsání hostname a podobně) a samosebou jakýkoliv text. Právě toho využívám k tomu, abych do promptu dostal ony údaje o počtu souborů, adresářů a linků v aktuálním adresáři. Lze přidat naprosto cokoliv, například pro superuživatele by nebylo na škodu si vypsat i počet zalogovaných uživatelů. Uživatel si zase může nastavit, aby viděl počet e-mailů ve své schránce a podobně. Fantazii se zde meze nekladou.

Co se samotného "rozchození" týče, do /etc/bash_prompt nebo do souboru .bash_prompt ve Vašem $HOME (domácím adresáři) umístěte soubor s funkcí PROMT_COMMAND, který je volně ke stažení zde. Do souboru /etc/bashrc nebo $HOME/bashrc pak následující sekvenci příkazů, která zajistí, že se nám nový vysněný prompt nastavý.

Jak jednoduché, že? Rád bych ještě závěrem upozornil, že používat změněnou funkci PROMPT_COMMAND například na logonání příkazů není principielně dobrý nápad, protože ji lze kdykoli za chodu BASHe změnit.

Představme si, že máme síť s několika X.org nebo XFree86 terminály ("thin" klienty), a že jsme se rozhodli jako okenní manažer použít projekt WindowMaker. Je mnoho důvodů, proč bychom si vybrali nejspíše WindowMaker. Jedním z nich může být i to, že má skvěle propracován systém uživatelských menu.

Dále si představme, že každý z našich terminálů v síti má jiný hardware. Jeden terminál má grafickou kartu s podporou grafické akcelerace a jiný třeba ne. Některé terminály stojí na chodbě u výtahu a slouží veřejnosti a jiné jsou v kancelářích, kde slouží třeba úředníkům. My ale máme náš milý WindowMaker nainstalovaný na serveru, ke kterému jsou terminály připojeny a zobrazuje se tedy vzdáleně pro každý terminál. Chceme teď řešit, co který uživatel uvidí v menu WindowMakeru.

Jak vzápětí uvidíme, WindowMaker nám umožní užívatelská menu nakonfigurovat podle potřeby pro každou pracovní stanici v síti velice snadno. Bude na to stačit pouhý script v BASHi a několik malých úprav v dalších souborech.

Ke generování menu potřebujeme pouze shell, v mém případě jsem zvolil Bourne Again Shell (neboli BASH) a ještě příkaz echo, který je na 99.999% v každé z dostupných distribucí GNU/Linuxu přítomen. Samotná struktura menu, které budeme generovat ze spustitelného skriptu, je následující (tučně jsou vyznačena klíčová slova).

Abych lépe osvětlil, co znamená co, uvedu ještě maličký příklad. Chceme například, aby menu obsahovalo podmenu "Launch", které bude obsahovat položky "World Wide Web" (spustí příkaz mozilla) a "Electronical Mail" (spustí sylpheed). Musíme tedy vygenerovat strukturu podmenu, která bude vypadat následujícím způsobem.

BASHový script, který vygeneruje takovou strukturu podmenu napíšeme za pár vteřin a bude nejspíše vypadat nějak tak, jak vidíte hned dole. Pozor na ty "zpropadené" vnořené uvozovky…

Pro ilustraci si výsledek svého dosavadního snažení můžete prohlédnout na následujícím screenshotu submenu, které jsme shora uvedeným scriptem vygenerovali. Jak WindowMaker přesvědčíme, aby výstup z onoho scriptu použil pro generování takovéhoto podmenu si povíme až na konci tohoto článku. Script lze také stáhnout zde.

Zde je již třeba troška přemýšlení, ale ne zase moc. Existuje například množství uživatelských účtů. Také možná existuje uživatel "public", pod kterým jsou spuštěna "X-ka" na chodbě u výtahu. Pak víme, že například pracovní stanice "ps0001" má grafickou kartu dost zastaralou a vůbec je to asi moc staré "železo" a tak na ní nebudeme spouštět náročné grafické aplikace. Oproti tomu náš vlastní (administrátorský, s označením třeba "ps0028") terminál je velice výkonný, a proto proč toho nevyužít, že? Na chodbách pak postávají dva veřejné terminály, na nichž rozhodně nebude potřeba používat GL aplikace ("ps9001" a "ps9002").

Zdá se, že nám tedy vznikají jakési dvě skupiny pracovních stanic podle toho, zda je žádoucí či vůbec možné na nich spouštět náročné grafické aplikace. Pracovně si ty dvě skupiny pro náš příklad pojmenujeme třeba "public" a "gl" či "nogl". Komplexní řešení zde nebudu příliž rozebírat, pouze nadhodím, jak bychom mohli při tvorbě "inteligentnějšího" scriptu, který rozhodne, co kde má být zobrazeno v menu, postupovat.

Logika celého rozhodování má v tomto stále ještě jednoduchém příkladě pouze dva kroky, které jsou popsány zdola v bodě dva. Nejprve je však potřeba vytvořit seznamy, které budou mít patřičnou vypovídací hodnotu o stavu hardware v jednotlivých pracovních stanicích, což je obsahem následujícího bodu jedna.

1) Pro náš příklad mějme dva seznamy třeba v /etc/terminals/, které mají nastavena práva pouze pro čtení s názvy například public.list, gl.list (nebo nogl.list, to podle toho, kterých máme méně), ve kterých jsou za sebou mezerou oddělené názvy stanic. V /etc/terminals/public.list tedy bude vzhledem k našemu příkladu následující obsah.

2) Před případným echem, které vypíše na výstup položku pro spuštění oné náročné grafické aplikace musíme pouze zkontrolovat u jakého terminálu se pracuje. Toho docílíme například cyklem, který zkontroluje, zda proměnná $DISPLAY je shodná s některým řádkem z public.list nebo není. Pokud ne, zkontrolujeme zda není shodná s některým ze záznamů v našem gl.list (v něm logicky bude chybět ona nešťastná stanice "ps0001"). Pokud se prokáže shoda, vypíšeme položku pro problematické grafické aplikace do menu.

Celé to má ovšem ještě díru. Šikovnější uživatel brzy zjistí, že může ručně editovat soubor WMRootMenu, ve kterém se nachází definice menu taková (jak uvidíme ještě dále), aby se mu zobrazilo pouze námi chtěné menu. Proto v uživatelově $HOME/.xinitrc musíme zaměnit prosté spuštění WindowMakeru příkazen wmaker tak, aby si WindowMaker "natáhl" konfigurační soubory z adresáře, na který má pouze právo pro čtení, nikoliv zápis. Toho docílíme nastavením proměnné GNUSTEP_USER_ROOT před spuštěním WindowMakeru. Na konci $HOME/.xinitrc tedy budeme mít nyní následující řádek.

Přičemž inkriminovaný adresář má práva nastavena pouze pro čtení pro všechny uživatele. Soubor $HOME/.xinitrc je nejlépe udělat jako symlink na /etc/xinitrc, který má též nastaven práva pouze pro čtení.

Nyní si ještě musíme ukázat, jak generované menu WindowMakeru "vnutit". Dodílíme toho editací souboru $GNUSTEP_USER_ROOT/Defaults/WMRootMenu, který upravíme do následující podoby (ke stažení zde).

Tím dostaneme naše příkladové "triviální podmenu" do ukázkového "Main Menu", jehož screenshot Vám pro úplnost také předkládám.

Ještě mi dovolte poznamenat, že obdobným způsobem lze konstruovat i velice složité "hierarchie", kdy je mnoho různých úrovní oprávnění přístupu k programům. Například uživatel "kalousekj" je účetní, a proto by měl v menu jen to, co je potřebné k vedení firemního účetnictví. Naproti tomu sekretářka s uživatelským jménem "rihovak" by mohla spustit navíc program pro manipulování s elektronickou poštou. A my jako administrátoři toho všeho bysme mohli spustit uživatelské programy všechny.

Secure Shell nebo SSH je nástroj architektury daemon-klient, který umožňuje přístupovat bezpečně na vzdálené stroje. Jeho předchůdcem byl známý Telnet, který se již dnes používá pro vzdálený přístup pouze v rámci zabezpečených lokálních sítí. SSH de facto nahrazuje programy rlogin, rsh a rcp, u nichž spojení není zabezpečeno šifrováním a proto nejsou vhodné pro užívání ve "veřejném" prostoru sítě. Upřímně řečeno, nepoužíval bych je ani v rámci zabezpečených lokálních sítí, protože se vždy najde někdo i v prostoru například podnikové sítě, kdo by se vám rád podíval do vašeho uživatelského účtu.

K tomu, abychom se mohli vůbec na vzdálený stroj přihlásit, je potřeba, aby na něm bežel a poslouchal daemon (server). Ten se obvykle v systému nazývá sshd (Secure Shell Daemon) a bývá zvykem, ale ne pravidlem, že tento daemon poslouchá na vzdáleném stroji na portu 22. Klient se ve většine systému nazývá, zcela intuitivně, ssh (existují i klienti pro jiné operační systémy, např. pro M$ Windows se jmenuje "putty"). Budiž. Zkusíme se tedy přihlásit na stroj, na němž máme zřízený uživatelský účet s možností spustit alespoň nějaký shell (typicky BASH) a základní systémové programy.

Pokud se název uživatelského účtu shoduje s názvem uživatelského účtu, ze kterého se na vzdálený stroj připojujeme, lze si ušetřit trochu psaní a přihlásit se pouze následujícím způsobem.

Pokud vše proběhlo jak mělo a pokud jsme se tam předtím ještě nikdy nelogovali, vzdálený stroj nám s nejvyšší pravděpodobností ukazuje "otisk" (z angl. "fingerprint", tedy cosi jako otisk prstu známý z oblasti forenzní kriminalistiky) a ptá se nás, zda jej chceme akceptovat. Pokud otisk známe a vidíme, že předkládaný otisk souhlasí, není důvod jej neakceptovat. Pokud nesouhlasí, tak jej samosebou neakceptujeme, protože se stalo buď to, že nám někdo podvrhl spojení nebo jsme se nějakou "šťastnou náhodou" pokoušeli připojit na jiný vzdálený stroj než jsme byli chtěli a někdo tam má uživatelský účet stejného názvu jako my na tom správném stroji, na který jsme se původně chtěli přihlásit.

Při příštím pokusu o nalogování na vzdálený stroj se již s výzvou, abychom akceptovali fingeprint nesetkáme neboť jej lokální klient ssh již zná (akceptované fingerprinty si ukládá typicky do souboru $HOME/.ssh/known_hosts), ale s pouhou touto výzvou k zadání hesla.

Poté, co akceptujeme otisk se nás vzdálený stroj ještě zeptá na heslo k přístupu do uživatelského účtu.

To, co jsme nyní probrali je jeden ze dvou způsobů navázání spojení mezi lokálním a vzdáleným strojem pomocí SSH. Má to však své mouchy. Data sice jsou přenášena šifrovaně, takže by nám asi nemuselo vadit, že se při vytváření spojení "éteren" pohybují i naše uživatelská jména a hesla, ale přeci jenom, bezpečnosti není nikdy dost. Co když třeba někomu nad sklenicí lahodného moku vyžvaníme naše heslo? Co když bude naše heslo prolomeno nějakým jiným, tajuplným způsobem? Vivat paranoia! Povíme si tedy o druhém způsobu autorizace, který je založen na použití veřejneho klíče.

Pokud klíč ještě nemáme, tak si jej nyní vygenerujeme. Máme-li nainstalováno OpenSSH, máme též k dispozici utilitku s prozaickým názvem ssh-keygen. Nejprve si však povíme něco málo o šifrách, které se používají.

Protokol SSH existuje ve dvou verzích, SSH1 a SSH2. Protokoly se od sebe liší v zázadě jen typem použitého šifrování. Existují tři šifry používané SSH klienty i daemony, které vidíte v následující tabulce.

Obě šifry se vzájemně odlišují jen technologicky, tj. je v nich použit jiný matematický postup. Z hlediska přihlašování v nich prakticky není rozdíl. Je třeba podotknout, že šifrování RSA je starší než DSA, a proto bych se klonil spíše k používání protokolu SSH2, který využívá novější DSA šifrování. Klíče zašifrované pomocí RSA používám jen pokud vím, že se budu připojovat ke stroji, který podporuje pouze SSH1 protokol.

Nyní si prostudujme seznam příkazů, kterými si vygenerujeme klíč, popř. klíče (pod příkazem je vždy uvedeno, které soubory se nám vytvoří v našem $HOME/.ssh/ adresáři).

Vygenerovali jsme tedy klíč a v adresáři $HOME/.ssh/ nám přibyly příslušné soubory (ty bez koncové přípony .pub musíme pečlivě střežit). Ten, který má koncovou příponu .pub nás nyní velice zajímá. Jeho obsah totiž potřebujeme dostat do souboru $HOME/.ssh/authorized_keys na vzdáleném stroji, pričemž existují v zásadě dvě možnosti, jak toho docílit relativně bezpečně. Buď pomocí SSH spojení anebo přenosem na fyzickém médiu (to druhé je lepší, pokud máme ke vzdálenému stroji fyzický přístup).

Variantu první lze použít, pokud jsme si jisti, že jsme se zalogovali na správný stroj. Jelikož toto víme (oveřili jsme si přeci fingerprint!), z lokálního stroje provedeme například následující sérii příkazů (předpokládám SSH2 spojení a DSA šifrování, za znaky "#" uvádím komentáře, posloupnost příkazů je tak zbytečně složitá kvůli názornosti).

Utilitka scp slouží ke kopírování ze vzdáleného stroje na lokální anebo opačně (jejím protějškem pro operační systém M$ Windows může být například utilitka WinSCP).

Zbývá dovysvětlit, proč již není potřeba zadávat heslo při pokusu o zalogování na vzdálený stroj. Celá situaci nyní vypadá asi takto: K autorizaci se nyní používá náš veřejný klíč. Daemon na vzdáleném stroji zaznamená náš pokus o přihlášení a jelikož existuje soubor $HOME/.ssh/authorized_keys s náležitým klíčem, vytvoří pomocí tohoto veřejného klíče zašifrovaný proud dat, která odešle klientovi. Klient, který zná neveřejnou, tajnou, část klíče tento proud dat rozšifruje a pošle zpět vzdálenému daemonovi. Ten porovná tento rozšifrovaný proud dat s nezašifrovanými daty, která prve použil k vytvoření onoho šifrovaného proudu dat. Pokud dojde ke shodě a data jsou naprosto stejná, tak ví, že nás s čistým svědomím může vpustit dovnitř. A proto není není potřeba posílat do "éteru" jména ani hesla, a proto je tato metoda autorizace relativně bezpečnější než autorizace pomocí hesla.