Cvičení #5 (18. března - 22. března)

Cvičení: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14.

Cílem tohoto cvičení je začít používat Linux v síťovém prostředí a naučit se základní koncepty potřebné pro práci na počítači sdíleném více uživateli. Po absolvování cvičení se budete moci přihlásit ke vzdálenému počítači se systémem Linux, používat Git přes SSH a také se podívat, jaké programy jsou aktuálně spuštěny.

Uvádíme stručný přehled několika pojmů, o kterých se domníváme, že byste je již měli znát. Neváhejte tyto části přeskočit a zaměřte se pouze na nová témata.

Předstartovní kontrola

Úvod do síťování

Tento text předpokládá, že už máte základní znalosti o sítích. Termíny jako IP adresa, rozhraní nebo port by pro vás neměly být nové. Potřebujete-li si je oživit, připravili jsme krátkou stránku se stručným přehledem sítí.

O asymetrické kryptografii

Než se pustíme do podrobností o přístupu ke vzdáleným počítačům (přes SSH), musíme si krátce osvěžit některá témata související s kryptografií.

V tomto cvičení se budeme bavit hodně o asymetrické kryptografii. Obecně je to metoda šifrování/dešifrování, u níž potřebujeme jiný klíč pro dešifrování zprávy, než byl použit pro její zašifrování.

V tom je rozdíl oproti symetrickým šifrám. Např. známá Caesarova šifra má jen jeden klíč (posun v abecedě), který je použit pro šifrování i dešifrování.

Asymetrická kryptografie obvykle vytváří dvojici klíčů: veřejný klíč, který se obvykle používá k šifrování, a soukromý (privátní) klíč. Pokud například vytvoříte veřejný šifrovací klíč a soukromý dešifrovací klíč, může vám zprávu zašifrovat kdokoli, ale dešifrovat ji můžete pouze vy. To je bezpečné, pokud je nemožné (nebo dostatečně obtížné) odvodit soukromý klíč z veřejného (což je ten obvyklý případ).

Má to jednu jasnou výhodu: nepotřebujete vytvářet tajný symetrický klíč pro každou dvojici uživatelů, kteří spolu chtějí komunikovat. Místo toho každý rozdistribuuje svůj veřejný klíč a hlídá si jen jeden privátní. (Není to ale tak jednoduché, jak to vypadá: Když Alice chce poslat šifrovanou zprávu Bobovi, musí se ujistit, že daný veřejný klíč opravdu patří Bobovi. Jinak by mohla snadno vytvořit bezpečné spojení, ale k útočníkovi.)

Naneštěstí nemáme žádný dobrý příklad asymetrické šifry tak jednoduchý jako byla Caesarova. Jako trochu složitější ale stále srozumitelný příklad se můžete podívat na RSA.

Poznamenejme, že výběr dobré šifry je jen malý krok v bezpečné komunikaci. Chcete-li se dozvědět více, zkuste nějakou opravdovou učebnici kryptografie, nebo se přihlaste na některý z našich kryptografických předmětů.

Dvojí použití asymetrické kryptografie

Asymetrická kryptografie má dvě hlavní použití. První je jasné: známe-li veřejný klíč příjemce zprávy, můžeme jej použít pro její zašifrování a poslat ji nezabezpečeným kanálem (beze strachu, že by ji někdo jiný mohl přečíst).

Ale můžeme to použít také naopak k autentizaci vlastníka soukromého klíče. Předpokládejme zde, že umíme distribuovat veřejný klíč bezpečně.

Mini-protokol poté dokáže autentizovat (ověřit), že protistrana je tím, za koho se vydává, prokázáním vlastnictví soukromého klíče (předpokládáme tedy, že soukromé klíče nebyly ukradeny).

Metoda je velmi jednoduchá – odesílatel vygeneruje náhodný text a zašifruje jej veřejným klíčem příjemce (kterého chceme ověřit). Je-li příjemce skutečný vlastník, dokáže náhodný text dešifrovat a poslat zpět. Nemožnost text dešifrovat znamená, že příjemce není vlastníkem soukromého klíče.

Autentizace veřejným a soukromým klíčem

Obvykle se uživatelé autentizují ke službě pomocí přihlašovacího jména a hesla. Přestože je tento způsob přirozený a pro lidi obvyklý, má několik nevýhod.

Hlavním problémem je složitost hesla: lidé zřídkakdy mají silná hesla a jen málo lidí používá správce hesel. Používání stejných hesel na více místech zase dovoluje administrátorovi (nebo hackerovi) jedné ze služeb se za vás vydávat v těch ostatních.

Zpět k ověřování soukromým/veřejným klíčem. Některé služby umožňují uživatelům ověřit se pomocí svých veřejných klíče namísto uživatelského jména/hesla.

Uživatel nahraje na server svůj veřejný klíč (pro ověření této operace použije přihlašovací jméno a heslo), a když se chce přihlásit, server mu pošle výzvu – náhodný tajný řetězec zašifrovaný jeho veřejným klíčem. Uživatel jako jediný vlastník soukromého klíče (a tedy jediný, kdo je schopen dešifrovat) může tajný řetězec dešifrovat a potvrdit tím svou identitu. Operace pak pokračuje jako u jakéhokoliv jiného ověřeného uživatele.

Užitečná pravidla

Aby autentizace veřejným klíčem probíhala bezpečně, následující je velmi doporučené (většina těchto pravidel platí i pro jiné způsoby přihlašování).

Je také možné chránit heslem přímo klíč. Ani v případě uniklého souboru s privátním klíčem pak nehrozí okamžitě krádež identity. Poznamenejme, že jsou zde nástroje, jako například ssh-agent(1), které umí uložit heslo na krátkou dobu, takže jej nemusíte zadávat při každém použití klíče.

Máte-li více počítačů, je preferováno používat různé páry veřejného a soukromého klíče na každém z nich. Je-li jeden stroj kompromitován, stačí odebrat jeho veřejný klíč ze všech aplikací, zatímco stále můžete používat ostatní klíče.

Základy kryptografie: zkontrolujte si, zda této části rozumíte

Použití SSH

Dost bylo teorie: připojme se k nějakému vzdálenému počítači. Prozkoumejme SSH.

Co je SSH?

SSH – zkratka pro Secure Shell – je protokol pro připojení k jiným počítačům a používání shellu na nich.

Z uživatelské perspektivy poté, co se připojíte z Linuxového stroje na jiný Linuxový stroj, shell může vypadat stejně a některé příkazy se můžou chovat úplně stejně. Jen s tou výjimkou, že budou spuštěny na jiném počítači.

Jde o záměrné chování: vzdálený shell je přirozený způsob pro ovládání Linuxového stroje. Není potřeba jej odlišovat od ovládání pomocí místního shellu.

SSH prakticky

Použití SSH je velmi jednoduché (alespoň když si to nekomplikujeme). Pro připojení pomocí SSH ke vzdálenému počítači potřebujete znát své přihlašovací údaje (tj. přihlašovací jméno a heslo) a samozřejmě název vzdáleného počítače.

Pak spusťte následující:

ssh VAS_LOGIN@NAZEV_VZDALENEHO_STROJE

Všimněte si, že příkaz ssh se často nazývá klient SSH, protože se připojuje k serveru SSH (podobně jako curl nebo wget jsou weboví klienti připojující se k webovému serveru).

Nastavili jsme pro vás vzdálený počítač linux.ms.mff.cuni.cz. Budete používat své přihlašovací jméno do GitLabu (SIS/CAS) a také stejné heslo.

ssh your_gitlab_login@linux.ms.mff.cuni.cz

První přihlášení na vzdálený počítače je o něco složitější. Klient SSH po vás chce ověření, že vzdálenému serveru důvěřujete. Zobrazí vám takzvaný otisk serveru:

The authenticity of host 'linux.ms.mff.cuni.cz (195.113.20.170)' can't be established.
ECDSA key fingerprint is SHA256:ltoc1TjoYhCZk6b8qSTAL6wFsRv7blw6u3h6NqCcYvI.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Podle konfigurace n vašem počítači se místo toho může objevit klíč RSA nebo ED25519:

RSA: SHA256:Z11Qbd6nN6mVmCSY57Y6WmxIJzqEFHFm47ZGiH4QQ9Y
ED25519: SHA256:/CVwDW388z6Z5VlhLJT0JX+o1UzakyQ+S01+34BI0BA

Tento otisk serveru byste měli získat bezpečným způsobem před připojením k serveru (například vytištěný od zaměstnavatele apod.). V tomto případě doufáme, že případný útočník nebude schopen proniknout do tohoto webového serveru i do serveru SSH najednou. Proto používáme protokol HTTPS na webu jako bezpečný způsob ověření serveru SSH.

Program pak pokračuje žádostí o zadání hesla a také vás informuje, že otisk (fingerprint) serveru byl uložen.

Při následujících přihlášeních klient SSH kontroluje, zda se otisk nezměnil. Změněný otisk patřící stejnému počítači (tj. se stejným názvem DNS) by mohl znamenat tzv. man-in-the-middle útok. Nepřipojujte se, pokud se otisk změnil. Vždy kontaktujte správce (v tomto konkrétním případě např. učitele) a ověřte si u něj, co se děje.

Pokud se vám podařilo přihlásit, uvidíte (téměř) prázdný domovský adresář a jinak normální linuxový počítač, tentokrát bez nainstalovaných grafických aplikací.

Zkuste spustit lscpu abyste viděli, na jakém počítači jste přihlášeni.

Nastavení $PS1

Toho jsme se již trochu dotkli v předchozím cvičení, kde to bylo jako doplněk pro další čtení.

$PS1 určil, jak vypadá váš prompt. Od nynějška byste měli zajistit, aby $PS1 zobrazoval také název stroje, abyste vždy věděli, kde se nacházíte (tj. ke kterému stroji jste přihlášeni).

Podobně jako při nastavení EDITOR v souboru ~/.bashrc byste měli zajistit, abyste zadali alespoň následující údaje, pokud výchozí nastavení nezobrazuje název stroje.

PS1='\u@\h \w\$'

Tím zajistíte, že uvidíte své uživatelské jméno (\u), jméno hostitele (stroje) (\h) a také pracovní adresář (\w).

Který soubor ~/.bashrc musíte upravit?Odpověď.

Chcete-li zobrazit další možnosti, jak si prompt nastavit, vraťte se k předchozímu cvičení.

Použití SSH ke spuštění jednoho příkazu

Příkaz ssh je ve skutečnosti poměrně výkonný a konfigurovatelný. Jednou z důležitých vlastností je, že můžete zadat příkaz za jménem stroje a přímo jej spustit. V tomto případě SSH nikdy nespustí interaktivní shell na vzdáleném počítači, ale provede pouze zadaný příkaz a skončí.

Následující příkazy vypíší uname -r na vzdáleném počítači.

ssh user@hostname uname -r

Zjistěte, jak (a proč) se následující příkaz chová jinak.

Rozdíl je vidět pouze pokud se SSHčkujete na jiný stroj, tj. pokud spouštíte ssh na vašem místním stroji.

ssh user@hostname uname -r >local_file.txt
ssh user@hostname "uname -r >remote_file.txt"

Chcete-li ověřit, že jste na jiném počítači, spusťte uname -a a hostname -f (poskytuje úplný DNS název aktuálního počítače).

Vidíte rozdíly?

Můžete také vyzkoušet free -h nebo uptime.

SSH a ověřování bez hesla

Pro povolení ověřování pomocí veřejného klíče přes SSH je třeba provést dva kroky. Vygenerovat pár veřejného a soukromého klíče a zkopírovat veřejný klíč na vzdálený počítač.

Pro vygenerování veřejného klíče je třeba spustit následující příkaz (-C je vlastně komentář, obvykle se zadává e-mail nebo přihlašovací jméno, ale je možné ho nechat i prázdný).

ssh-keygen -t ed25519 -C "your_email@example.com"

Program se nás zeptá, kam má uložit vygenerovaný soukromý a veřejný klíč. Ponechte výchozí hodnoty. Zvolte, zda chcete mít přístupovou frázi (vlastně heslo, passphrase), nebo ne (je bezpečnější ji mít, ale používání je trochu těžkopádnější). Po skončení ssh-keygen zkontrolujte, zda adresář ~/.ssh obsahuje id_ed25519 (soukromý klíč) a id_ed25519.pub (veřejný klíč).

Jejich obsah si můžete prohlédnout např. pomocí cat. Překvapuje vás, že se jedná o textové soubory?

Jakmile máme veřejný klíč připravený, musíme jej nahrát na vzdálený počítač. Pokud máte více párů klíčů, přečtěte si o přepínači -i.

ssh-copy-id LOGIN@REMOTE_MACHINE

Pokud se znovu přihlásíte ke vzdálenému počítači, klient SSH by měl použít dvojici klíčů a přihlásit vás bez žádosti o heslo. Pokud se tak nestane, spusťte SSH s -vvv, což vám pomůže problém odladit.

Všimněte si, že veřejný klíč byl uložen do souboru ~/.ssh/authorized_keys na vzdáleném počítači. Můžete ho tam zkopírovat i ručně, ale použití ssh-copy-id je jednodušší.

Kopírování souborů

Pokud jste rozluštili, co následující příkaz dělá, měli byste už mít představu, jak kopírovat soubory na vzdálený počítač a ze vzdáleného počítače (ale neříkáme, že je to ten nejefektivnější způsob):

ssh user@hostname "uname -r >remote_file.txt"

Zajímá vás, jak vám to pomůže při kopírování souborů? Než budete číst dál, trochu se nad tím zamyslete, a zvažte, jak se používají roury atd.

Vážně jste o tom přemýšleli? :-)

Pro kopírování souborů můžeme použít příkaz cat, který jednoduše vypíše soubor tak, jak je, na stdout. Jeho výstup pošleme rourou do SSH a na druhém počítači spustíme druhý cat, který soubor uloží.

cat README.md | ssh user@hostname "cat >remote-readme.md"

Nyní se, prosím, ujistěte, že dokážete vysvětlit, co se děje. SSH umí číst stdin (konec konců jsme naše příkazy psali lokálně a objevily se ve vzdáleném shellu na naší lokální obrazovce), a proto přes něj můžeme protáhnout (tunnel) data.

Existují také příkazy scp a rsync, které lze použít pro snadné kopírování více souborů přes SSH, ale o nich budeme hovořit na pozdějších cvičeních.

Správci souborů

Mnoho správců souborů umožňuje transparentně používat SSH a kopírovat soubory mezi počítači stejně snadno jako při práci s místními soubory.

Například v okně mc vyberte v levém nebo pravém panelu položku Shell connection a zadejte připojení SSH. Jeden z panelů zobrazí soubory na vzdáleném počítači. Zkuste použít F5 pro interaktivní kopírování souborů.

Používání strojů v Rotundě

Kromě stroje linux.ms.mff.cuni.cz je k dispozici také plná laboratoř strojů v počítačové učebně Rotunda na Malostranském náměstí.

Všechny počítače se systémem Linux v laboratoři jsou rovněž přístupné přes SSH. K přihlášení opět použijte své přihlašovací údaje do SIS. Všimněte si, že všechny stroje v Rotundě (ale ne linux.ms.mff.cuni.cz!) sdílejí stejný domovský adresář, tj. je jedno, ke kterému se fyzicky připojíte. Vaše soubory budou dostupné na všech strojích.

Použitý souborový systém v Rotundě a mechanismus ověřování bohužel neumožňuje použít ověřování pomocí veřejného klíče. Vždy je nutné zadat heslo. (linux.ms.mff.cuni.cz toto omezení nemá a předpokládáme, že zde budete používat ověřování pomocí veřejného klíče.)

K dispozici jsou následující stroje.

• Laboratoř SU1
  • u1-1.ms.mff.cuni.cz
  • u1-2.ms.mff.cuni.cz
  • …
  • u1-14.ms.mff.cuni.cz
• Laboratoř SU2
  • u2-1.ms.mff.cuni.cz
  • u2-2.ms.mff.cuni.cz
  • …
  • u2-25.ms.mff.cuni.cz
• Rotunda
  • u-pl1.ms.mff.cuni.cz
  • u-pl2.ms.mff.cuni.cz

K počítačům v laboratořích SU1 a SU2 se nedá pomocí SSH přistupovat během dne (resp. během rozvržené výuky). To má zabránit vzdáleným uživatelům znepříjemňovat práci studentům, kteří se v laboratoři učí. Počítače v Rotundě jsou k dispozici 24/7.

SSH: zopakujte si své znalosti

Unixová přístupová práva

Zatím jsme jen tiše ignorovali fakt, že je na každém Linuxovém systému více uživatelských účtů. A také to, že uživatelé nemůžou přistupovat ke všem souborům. V této části vysvětlíme základy Unixových přístupových práv, a jak je interpretovat.

Nyní se můžete přihlásit ke sdílenému počítači a měli byste být schopni pochopit, k čemu máte přístup a k čemu ne.

Vzpomeňme si, co jsme říkali o /etc/passwd – obsahuje seznam uživatelských účtů na tom konkrétním stroji (technicky to není jediný možný zdroj uživatelských záznamů, ale prozatím je to dobrá aproximace).

Každá běžící aplikace, tedy process, je vlastněná jedním z uživatelů z /etc/passwd (opět to tu trochu zjednodušujeme). Také říkáme, že tento proces běží pod konkrétním uživatelem.

A každý soubor v souborovém systému (včetně jak reálných souborů jako ~/.bashrc, tak virtuálních jako /dev/sda nebo /proc/uptime) má svého vlastníka.

Když se proces pokouší číst nebo upravovat soubor, operační systém rozhodne, jestli je tato operace oprávněná. Toto rozhodnutí je založené na vlastníkovi souboru, vlastníkovi procesu a právech definovaných pro daný soubor. Je-li operace zakázána, vstupní/výstupní funkce ve vašem programu vyvolá výjimku (např. v Pythonu) nebo vrátí chybový kód (v C).

Protože model založený pouze na vlastnících by nebyl dostatečně flexibilní, máme také skupiny uživatelů (definované v /etc/group). Každý uživatel je členem jedné nebo více skupin, z nichž jedné se říká primární skupina. Tyto skupiny jsou asociované s každým procesem daného uživatele. Soubory pak mají jak vlastnícího uživatele, tak vlastnící skupinu.

Soubory mají přiřazené tři množiny oprávnění: jednu pro vlastníka souboru, druhou pro uživatele ve vlastnící skupině a třetí pro všechny ostatní uživatele. Přesný algoritmus pro určení, která množina bude použita, vypadá takto:

1. Je-li uživatel, který proces spustil, stejný jako vlastník souboru, jsou použita přístupová práva vlastníka (někdy také označované jako uživatelská přístupová práva).
2. Je-li uživatel běžícího procesu ve skupině, která byla nastavena u souboru, jsou použita skupinová (group) přístupová práva.
3. Jinak systém použije ostatní přístupová práva.

Každá množina oprávnění obsahuje tři práva: čtení (r), zápis (w), spouštění (execute, x):

• Operace čtení a zápisu souboru se chovají očekávatelně.

• Právo na spouštění se ověřuje v případě, kdy se uživatel snaží spustit soubor jako program (připomeňme, že bez chmod +x, se v takovém případě objevovala chyba Permission denied: zde je její důvod).

  • Poznamenejme, že skript, který lze číst, ale není spustitelný, můžeme stále spustit zavoláním příslušného interpretru manuálně.
  • Po spuštění programu nový proces zdědí vlastníka a skupiny svého rodiče (např. shellu, který jej spustil). Vlastnictví samotného spustitelného souboru není směrodatné po jeho spuštění. Například /usr/bin/mc vlastní uživatel root, ale přesto může být spuštěn libovolným uživatelem a běžící proces je poté vlastněný tím, kdo jej spustil.

Stejná oprávnění se vztahují také na adresáře, ale jejich význam je trochu odlišný:

• Právo na čtení umožňuje uživateli číst seznam souborů uvnitř (běžných, symlinků, podadresářů, atd.).
• Právo na zápis uživateli umožňuje vytvářet, odstraňovat a přejmenovávat soubory uvnitř. Všimněte si, že odstranění práva na zápis k souboru uvnitř zapisovatelného adresáře, je bezvýznamné, protože to uživateli nezabrání v tom, aby soubor nahradil úplně novým.
• Spustitelné (executable) právo na adresáři umožňuje uživateli otevírat položky uvnitř. (Má-li adresář x, ale ne r, můžeme používat soubory uvnitř, pokud známe jejich názvy, nemůžeme ale vypsat jejich seznam. Na druhou stranu, má-li adresář r, ale ne x, můžeme vypsat seznam souborů, ale nemůžeme je použít.)

Oprávnění souboru nebo adresáře může měnit pouze jejich vlastník a to bez ohledu na aktuální oprávnění. To znamená, že vlastník může sám sobě odepřít přístup odstraněním všech přístupových práv, ale stejně jej poté může později obnovit.

Uživatelský účet root

Vedle účtů pro normální uživatele je zde vždy i účet pro takzvaného superuživatele – obvykle nazývaného jen root – ten má administrátorská práva a je tedy oprávněn dělat cokoliv s libovolným souborem v systému. Ověřování oprávnění popsané výše jednoduše vůbec neplatí pro procesy vlastněné rootem.

Na rozdíl od jiných systémů, Linux je navržený tak, aby uživatelské programy byly vždy spouštěny pod normálními uživateli a nikdy nevyžadovaly práva roota. Ve skutečnosti se některé programy i odmítnou spustit pod uživatelem root (historicky jde o velmi časté chování IRC chatovacích programů).

Zobrazování a změna oprávnění

Podíváme-li se na zkratky rwx pro jednotlivá oprávnění, možná vám budou povědomá:

drwxr-xr-x 1 intro intro 48 Feb 23 16:00 02/
drwxr-xr-x 1 intro intro 60 Feb 23 16:00 03/
-rw-r--r-- 1 intro intro 51 Feb 23 16:00 README.md

První sloupec obsahuje typ položky (d pro adresář, - pro obyčejný soubor, atd.) a tři trojice oprávnění. První trojice se vztahuje k vlastníkovi souboru, prostřední ke skupině a poslední ke zbytku světa (k ostatním). Třetí a čtvrtý sloupec obsahují vlastníka a skupinu souboru.

Vaše osobní soubory v domovském adresáři budou typicky mít za vlastníka vás spolu se skupinou stejného jména. Jde o výchozí konfiguraci, která brání ostatním uživatelům, aby viděli vaše soubory.

Zkontrolujte, zda toto platí pro všechny adresáře pod /home na sdíleném počítači.

Poznamenejme, že většina souborů je ve skutečnosti přístupná ke čtení všem.

To je v pořádku, protože když se podíváte na oprávnění pro svůj ~, uvidíte, že je to typicky drwx------. Jen vlastník jej může upravovat a provést cd dovnitř. Vzhledem k tomu, že nikdo nemůže změnit svůj pracovní adresář na vaši domovskou složku, nikdo nemůže ani číst vaše soubory (technicky, čtení souboru znamená projít celou adresářovou strukturu a ověřit přístupová práva na celé této cestě).

Na změnu oprávnění můžete použít program chmod. Ten má obecně formát

chmod WHO[+=-]PERMISSION file1 file2 ...

WHO může být prázdné (pro všechny – uživatele, skupinu a ostatní) nebo určení u, g nebo o. A PERMISSION může být r, w nebo x.

Je možné je kombinovat, takže např. g-r,u=rw odstraní právo na čtení souboru pro skupinu a nastaví oprávnění čtení i zápisu pro vlastníka (čili soubor nebude spustitelný bez ohledu na předchozí stav executable bitu).

ls -ld /usr/bin/passwd /tmp

drwxrwxrwt 23 root root   640 Mar  3 08:15 /tmp/
-rwsr-xr-x  1 root root 51464 Jan 27 14:47 /usr/bin/passwd*

Kontrola přístupových práv

Vraťme se ještě na chvíli k přístupovým právům.

Změňte oprávnění některých skriptů na --x. Zkuste je spustit. Co se stane?Odpověď.

Odstraňte zapisovatelný bit pro soubor a zapište do něj pomocí přesměrování standardního výstup. Co se stane?

Kvíz o přístupových právech

-rwxr-xr-- 1 alice wonderland 1234 Feb 20 11:11 script.sh

Git přes SSH

Dosud jsme používali Git před HTTPS. Git ale můžeme používat také přes SSH. Komunikace je pak jednoduše tunelovaná skrz SSH spojení, na kterém Git závisí jak kvůli bezpečnosti tak (částečně) kvůli autentizaci.

V podstatě všechny Gitové servery (GitLab, GitHub, Bitbucket, …) po vás budou chtít nahrát váš veřejný klíč, abyste mohli používat Git přes SSH.

Abychom mohli Git přes SSH skutečně používat, musíme nejprve systému GitLab sdělit naše SSH klíče (připomeňte si protokol, který se používá k ověření uživatele).

GitLab a SSH klíče

Zkopírujte svůj veřejný klíč do aplikace GitLab. Přejděte do pravého horního menu se svým avatarem, vyberte Preferences a poté SSH keys nebo navštivte tento odkaz.

Zkopírujte tam svůj veřejný klíč a pojmenujte ho. V názvu by obvykle mělo být uvedeno vaše uživatelské jméno a váš počítač. Všimněte si, že vám GitLab zašle e-mail s informací o novém klíči. Proč? Nápověda.Odpověď.

Přejděte na svůj projekt a znovu jej naklonujte. Tentokrát použijte adresu URL Clone with SSH.

git clone git@gitlab.mff.cuni.cz:teaching/nswi177/2024/student-LOGIN.git

Všimli jste si, že to vypadá jako adresa SSH? Ve skutečnosti je to přesně tak. První část identifikuje stroj a uživatele (git) a za dvojtečkou je místní cesta.

Tímto způsobem můžete klonovat adresář Git z libovolného serveru SSH zadáním jeho vzdálené cesty (zde GitLab provádí určité úpravy, ale princip stále platí).

Všimněte si, že uživatel, se kterým klonujeme, je git – ne vy. Tímto způsobem potřebuje GitLab pouze jeden fyzický uživatelský účet pro zpracování požadavků Gitu a rozlišuje uživatele pomocí jejich veřejných klíčů. Jak? Odpověď.

ssh git@gitlab.mff.cuni.cz

Všimněte si, že pro práci se systémem Git byste měli preferovat protokol SSH, protože je mnohem pohodlnější.

Zbytek práce se systémem Git zůstává stejný. git add, git commit, git push atd. budou fungovat stejně, pouze komunikace s GitLabem bude probíhat přes tunel SSH. Všimněte si, že při provádění git push nemusíte znovu zadávat své přihlašovací údaje. Je to proto, že si git pamatuje, jak jste git cloneovali úložiště, a použije stejnou adresu URL (buď HTTPS, nebo SSH) i pro git push (pokud to nenastavíte jinak). A protože jste použili SSH pro stahování, použije SSH i pro odesílání, které používá již jednou nastavené ověřování pomocí veřejného/soukromého klíče.

Procesy

Soubory v systému jsou jeho pasivními prvky. Aktivními částmi jsou spuštěné programy, které data skutečně mění. Podívejme se, co vlastně běží na našem počítači.

Když spustíte program (tj. spustitelný soubor), stane se procesem. Spustitelný soubor a běžící proces sdílí kód – ten je stejný v obou. Ale proces také obsahuje zásobník (stack) (např. pro lokální proměnné), haldu (heap), seznam otevřených souborů apod. – tomu všemu se obvykle říká kontext procesu. Obvykle jsou slovní spojení běžící program a proces zaměňována.

Pro zobrazení seznamu běžících procesů na našem počítači můžeme použít htop, který zobrazí informace o procesech. Podobně jako v MidnightCommanderu provádějí nejdůležitější akce funkční klávesy a nápověda je viditelná v dolní liště. Můžete také nakonfigurovat htop tak, aby zobrazoval informace o systému, jako je množství volné paměti nebo využití procesoru.

Pro neinteraktivní použití můžeme spustit ps -e (nebo ps -axufw pro podrobnější seznam).

Pro ilustraci uvádíme příklad výstupu ps (s volbou --forest pro zobrazení vztahu rodič/dítě).

Chcete-li však zobrazit i běžící procesy svých kolegů, spusťte na sdíleném počítači příkaz ps -ef --forest.

UID          PID    PPID  C STIME TTY          TIME CMD
root           2       0  0 Feb22 ?        00:00:00 [kthreadd]
root           3       2  0 Feb22 ?        00:00:00  \_ [rcu_gp]
root           4       2  0 Feb22 ?        00:00:00  \_ [rcu_par_gp]
root           6       2  0 Feb22 ?        00:00:00  \_ [kworker/0:0H-events_highpri]
root           8       2  0 Feb22 ?        00:00:00  \_ [mm_percpu_wq]
root          10       2  0 Feb22 ?        00:00:00  \_ [rcu_tasks_kthre]
root          11       2  0 Feb22 ?        00:00:00  \_ [rcu_tasks_rude_]
root           1       0  0 Feb22 ?        00:00:09 /sbin/init
root         275       1  0 Feb22 ?        00:00:16 /usr/lib/systemd/systemd-journald
root         289       1  0 Feb22 ?        00:00:02 /usr/lib/systemd/systemd-udevd
root         558       1  0 Feb22 ?        00:00:00 /usr/bin/xdm -nodaemon -config /etc/X11/...
root         561     558 10 Feb22 tty2     22:42:35  \_ /usr/lib/Xorg :0 -nolisten tcp -auth /var/lib/xdm/...
root         597     558  0 Feb22 ?        00:00:00  \_ -:0
intro        621     597  0 Feb22 ?        00:00:40      \_ xfce4-session
intro        830     621  0 Feb22 ?        00:05:54          \_ xfce4-panel --display :0.0 --sm-client-id ...
intro       1870     830  4 Feb22 ?        09:32:37              \_ /usr/lib/firefox/firefox
intro       1966    1870  0 Feb22 ?        00:00:01              |   \_ /usr/lib/firefox/firefox -contentproc ...
intro       4432     830  0 Feb22 ?        01:14:50              \_ xfce4-terminal
intro       4458    4432  0 Feb22 pts/0    00:00:11                  \_ bash
intro     648552    4458  0 09:54 pts/0    00:00:00                  |   \_ ps -ef --forest
intro      15655    4432  0 Feb22 pts/4    00:00:00                  \_ bash
intro     639421  549293  0 Mar02 pts/8    00:02:00                      \_ man ps
...

Především má každý proces svoje ID, často označované jen PID (neplést s tímto). PID je číslo přiřazené jádrem operačního systému a je používáno nástroji pro správu procesů. PID 1 je určeno pro první proces spuštěný v systému (0 je vyhrazená pro speciální účely – mrkněte na fork(2) pokud vás zajímají detaily). Když tento proces skončí, systém se vypne. Ostatní procesy dostávají (v jednoduchosti) postupně se zvyšující PIDy, časem jsou PIDy recyklovány.

Vzpomeňte si, že tyto informace jsou obsažené též v adresáři /proc/PID a odtamtud je také ps čte.

Pro zobrazení všech procesů v počítači znovu spusťte ps -ef --forest. Vzhledem ke grafickému rozhraní bude seznam pravděpodobně poměrně dlouhý.

Prakticky může mít malý server nabízející webové stránky, kalendář a přístup přes SSH asi 80 procesů, u desktopu s prohlížečem běžícím v Xfce a několika dalšími aplikacemi se počet zvýší na téměř 300 (tohle opravdu hodně závisí na konfiguraci, ale je to rozumný přibližný odhad). Asi 50-60 z nich jsou ve skutečnosti vnitřní vlákna jádra. Jinými slovy, webový/kalendářový server potřebuje asi 20 “skutečných” procesů, desktop jich potřebuje asi 200 :-).

Vynucené ukončování procesů

V tuto chvíli si ukážeme asi to nejdůležitější, co můžete s procesy dělat. A to je jejich vynucené ukončení.

Časem se seznámíme s pojmem signálu, v tuto chvíli se omezíme na dva základní příkazy.

Příkaz `pgrep lze použít k vyhledání procesů odpovídajících zadanému názvu.

Otevřete dva další terminály a v jednom spusťte sleep 600 a ve druhém sleep 800. Program sleep jednoduše počká daný počet sekund, než se ukončí.

Ve třetím terminálu spusťte následující příkazy, abyste pochopili, jak probíhá vyhledávání procesů.

pgrep sleep
pgrep 600
pgrep -f 600

Co jste se dozvěděli? Odpověď.

Když známe PID, můžeme použít nástroj kill a program skutečně ukončit. Zkuste spustit kill PID s PID jednoho ze sleepů a podívejte se, co se stalo v terminálu, kde sleep běžel.

Měli byste vidět něco takového:

Terminated (SIGTERM).

Tato zpráva nás informuje, že příkaz byl násilně ukončen.

Některé programy příkaz kill ignorují a neukončí se. Proč je to možné, si vysvětlíme v některém z příštích cvičení, ale zatím chceme zmínit, že k příkazu kill je možné přidat -9, což operačnímu systému nařídí, aby byl trochu důraznější a program ukončil, aniž by mu dal možnost nesouhlasit ;-).

Své vlastní procesy můžete ukončovat (zabíjet) vždy, ale ukončování cizích procesů není možné.

Rychlá kontrola znalostí procesů

Něco navíc

Několik drobností navíc, které výrazně zlepší vaši uživatelskou interakci s SSH, ale ke kterým se můžete kdykoli později vrátit.

tmux

tmux new -s <session_name>

tmux ls

tmux attach -t <session_name>

tmux kill-session -t <session_name>

d odpojení od relace

c vytvořit okno
w seznam oken
n další okno
p předchozí okno
f najít okno
, název okna
& zabít okno

% vertikální rozdělení
" horizontální rozdělení

o prohození panelů
q zobrazit čísla panelů
x zabít panel
← přepnutí na levý panel
→ přepnutí na pravý panel
↑ přepnutí na horní panel
↓ přepnutí na dolní panel

bind-key C-h run "tmux select-pane -L"
bind-key C-j run "tmux select-pane -D"
bind-key C-k run "tmux select-pane -U"
bind-key C-l run "tmux select-pane -R"

Host *
    IdentityFile ~/.ssh/id_ed25519

Host intro
    Hostname linux.ms.mff.cuni.cz
    User YOUR_SIS_LOGIN

Host mff0
    Hostname u-pl0.ms.mff.cuni.cz
    User YOUR_SIS_LOGIN

Host mff21n
    Hostname u-pl1.ms.mff.cuni.cz
    User YOUR_SIS_LOGIN

ssh YOUR_SIS-LOGIN@linux.ms.mff.cuni.cz

Úlohy k ověření vašich znalostí

Očekáváme, že následující úlohy vyřešíte ještě před příchodem na cvičení, takže se budeme moci o vašich řešeních na cvičení pobavit.

Předpokládejme, že máme soubor `test.txt`, pro který `ls -l` vypíše následující:

    -rw-r----- 1 bjorn ursidae 13 Mar 21 14:54 test.txt

Který z následujících uživatelů bude moci číst obsah souboru?

 1. `bjorn` ve skupině `ursidae`
 2. `bjorn` ve skupinách `carnivora` a `mammalia`
 3. `iorek` ve skupině `ursidae`
 4. `iorek` ve skupinách `carnivora` a `mammalia`
 5. `root` (superuživatel)
 6. všichni

**[A1]** ... **[/A1]**

Uvažujte, že soubor z předchozího příkladu je uložen v rámci
v adresáři `/data` s následujícími právy, jak je vypsal příkaz `ls -l`:


    drwxrwx-wx 3 bjorn ursidae 4096 21.3.14:53 data


Který z následujících uživatelů bude moci tento soubor smazat?

 1. `bjorn` ve skupině `ursidae`
 2. `bjorn` ve skupinách `carnivora` a `mammalia`
 3. `iorek` ve skupině `ursidae`
 4. `iorek` ve skupinách `carnivora` a `mammalia`
 5. `root` (superuživatel)
 6. všichni

Lze předpokládat, že kořenový adresář `/` je čitelný a spustitelný
pro každého.

**[A2]** ... **[/A2]**

V návaznosti na předchozí otázky uveďte, které příkazy lze použít k tomu, abyste
soubor `test.txt` učinili čitelným a zapisovatelný pouze pro vlastníka a nikoho jiného?

 1. `chmod u=rw test.txt`
 2. `chmod =rw test.txt`
 3. `chmod g= test.txt`
 4. `chmod o= test.txt`
 5. `chmod g=,o= test.txt`
 6. `chmod g-r test.txt`
 7. `chmod g-rwx test.txt`

**[A3]** ... **[/A3]**

gitolite3@linux.ms.mff.cuni.cz:lab05-LOGIN

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPuoJJldIS6zOxunFxIFGk6tQlw0qpYSOxHYs57117o/ teachers-nswi177@d3s.mff.cuni.cz

Učební výstupy

Učební výstupy podávají zhuštěný souhrn základních konceptů a dovedností, které byste měli umět vysvětlit a/nebo použít po každém cvičení. Také obsahují absolutní minimum, které je potřebné pro pochopení navazujících cvičení (a dalších předmětů).

Znalosti konceptů

Znalost konceptů znamená, že rozumíte významu a kontextu daného tématu a jste schopni témata zasadit do většího rámce. Takže, jste schopni …

• vysvětlit základní principy síťové komunikace (bez ohledu na OS/zařízení)

• vysvětlit základní principy asymetrické kryptografie

• do detailu vysvětlit, jak se dá použít asymetrická kryptografie (privátní a veřejný klíč) pro autentizaci uživatele

• vysvětlit, co je SSH a jaké funkce nabízí

• vysvětlit jaké druhy účtů existují na Linuxu a čím se liší (např. johndoe, root a nobody)

• vysvětlit, jak se liší spouštění programů lokálně a vzdáleně přes SSH

• vysvětlit rozdíl mezi používáním Gitu přes HTTPS a přes SSH

• vysvětlit, jaká jsou základní přístupová práva na unixových operačních systémech soubory a pro adresáře

• vysvětlit co znamenají jednotlivá oprávnění r, w a x pro běžné soubory a pro adresáře

• vysvětlit co je to set-uid bit

• vysvětlit, co je proces a jak se liší od spustitelného souboru

• vysvětlit rozdíl mezi vlastnictvím souboru a běžícího programu

• volitelné: vysvětlit, co je POSIX ACL, jen základní přehled

Praktické dovednosti

Praktické dovednosti se obvykle týkají použití daných programů pro vyřešení různých úloh. Takže, dokážete …

• nastavení proměnné PS1 pro rozlišení různých strojů

• použít příkazu ssh na přihlášení se ke vzdálenému stroji

• spouštět příkazy na vzdáleném stroji pomocí SSH

• používat příkaz hostname

• přenos souborů přes SSH pomocí cat

• nastavit přihlašování bez hesla na vzdáleném Linuxovém stroji pomocí páru privátního a veřejného klíče

• nastavit autentizaci veřejným klíčem na GitLabu

• použití git clone (a pull a push) přes SSH

• zobrazovat a měnit základní přístupová oprávnění souborů

• pomocí ps zobrazit seznam existujících procesů (včetně přepínačů -e, -f a --forest)

• použít htop k interaktivnímu sledování existujících procesů

• volitelné: nastavit zkratky pro SSH

• volitelné: používat základní funkce terminálového multiplexeru tmux

Seznam změn na této stránce

• 2024-03-11: Přidána poznámka o ssh -v.

• 2024-03-14: Poznámka, že loginy rozlišují velikosti písmen.

• 2024-03-18: Oprava seznamu strojů dostupných v Rotundě.

• 2024-04-08: Sdílený domovský adresář v IMPAKTu a v Rotundě.