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.

Ú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.

Pokud správce hesel nepoužíváte, zvažte jeho použití. Obecně jde o to, že si zapamatujete jedno (ale silné!) heslo a toto heslo zašifruje ostatní hesla.

Proto lze všechna hesla generovat tak, aby byla dostatečně dlouhá a jedinečná pro každou službu.

K dispozici je spousta správců, jednoduchý je pass, který umí používat na pozadí Git a má k dispozici spoustu klientů s grafickým rozhraním, včetně těch pro Android a iOS.

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í).

Soukromý klíč je jako heslo – nesmí uniknout. Obvykle jde o soubor a ten je tedy potřeba chránit. Typickou volbou pro přenosná zařízení je mít šifrovaný pevný disk.

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

Vyberte všechna pravdivá tvrzení. You need to have enabled JavaScript for the quiz to work.

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 VAS_GITLAB_LOGIN@linux.ms.mff.cuni.cz

Pokud byl váš účet GitLab vytvořen ručně, je pravděpodobné, že heslo ze SISu nebude na tomto počítači fungovat.

Prosím, kontaktujte nás prostřednictvím tohoto odkazu (název issue neměňte, text issue pište klidně česky a my vám účet vytvoříme ručně.

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.

Obvykle není heslo viditelné, tj. vůbec nic se nezobrazuje (ani hvězdičky). To je v pořádku: napište svoje heslo a potvrďte Enterem.

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.

Upozorňujeme, že tento stroj je společný pro všechny studenty tohoto kurzu. Používejte jej k řešení klasifikovaných úloh nebo k experimentování s příkazy, které si ukážeme na cvičení. Po zbytek kurzu jej budete používat k řešení několika úloh, proto jej prosím udržujte v rozumném stavu.

Nepoužívejte jej k výpočetně náročným úlohám nebo jiným úlohám, které nesouvisejí s tímto kurzem.

Rovněž přísně zakazujeme jeho používání pro jakýkoli druh vzdáleného vývoje pomocí nástrojů, jako je Visual Studio, IntelliJ IDEA nebo podobné IDE. Tyto nástroje instalují na vzdálený počítač obrovské bloky kódu/dat, a protože jen zřídka odstraňují staré verze, velmi rychle si pro sebe zabírají veškeré volné místo.

Pokud se setkáme s jakoukoli formou zneužití, příslušný účet zablokujeme.

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?Answer.

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

Osobní tip: na osobním počítači používejte barevný prompt bez uživatele/stroje, ale na všech vzdálených počítačích ponechte nebarevnou verzi s \u@\h, abyste měli krátký prompt na svém počítači, ale práce na vzdáleném počítači byla vizuálně odlišena.

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ý).

Generování klíčů probíhá vždy na místním stroji, tj. na tom, ze kterého se budete někam připojovat.

Můžeme chtít vygenerovat i pár klíčů na vzdáleném stroji (třeba na linux.ms.mff.cuni.cz). Ale tento pár se pak použije pro autentikaci k další službě, třeba ke GitLabu (tj. linux.ms.mff.cuni.cz bude lokálním strojem v komunikace).

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šší.

Pokud kopírování selže se záhadnou zprávou warning: here-document at line 251 delimited by end-of-file (wanted EOF), zkuste nejprve aktualizovat klienta SSH.

Pokud použijete obraz od nás, mělo by fungovat jednoduché sudo dnf upgrade openssh-clients.

Pouze pomocí klíčů

Všimněte si, že některé služby skutečně vyžadují ověřování pomocí páru klíčů namísto hesla, protože je to považováno za bezpečnější.

Výhodou je, že náhodní útočníci mohou vaše heslo hádat, a přesto nikdy nezískají přístup k vašemu počítači.

Automatické vyloučení klientů

Server SSH je také obvykle nakonfigurován tak, aby zakázal každého klienta, který se několikrát za sebou neúspěšně pokusí přihlásit. Náš server je také tak nastaven.

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
    • u-pl23.ms.mff.cuni.cz

SSH: zopakujte si své znalosti

Vyberte všechna pravdivá tvrzení. You need to have enabled JavaScript for the quiz to work.

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).

Sticky a jiné bity

Když spustíte následující příkaz, uvidíte trochu jiný výstup, než byste nejspíš očekávali.

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*

Můžete si všimnout, že /tmpt na místě executable bitu a passwd tam má s.

Jde o speciální varianty executable bitu. Bit t u adresáře znamená, že uživatel může odstranit jen své vlastní soubory. Důvod je jednoduchý – neměli byste mít možnost odstraňovat cizí soubory uvnitř /tmp. S použitím jen základních oprávnění by toto nebylo možné.

Bit s (set-uid) je trochu trikovější. Ten specifikuje, že bez ohledu na to, kdo spustil shell, passwd se vždy spustí pod uživatelem vlastnícím tento soubor (což je zde root).

Přestože to může vypadat neužitečně, jde o jednoduchý způsob, jak umožnit spouštění některých programů s vyššími oprávněními. passwd je typický příklad. Tento příkaz umožňuje uživateli změnit jeho heslo. To je ale uložené v souboru, který není přístupný ani ke čtení nikomu kromě roota (z očividných důvodů). Přiřazení bitu s ke spustitelnému souboru znamená, že proces poběží pod rootem a bude tak moci upravovat databázi s uživateli (tedy /etc/passwd a /etc/shadow, který obsahuje vlastní hesla).

Vzhledem k tomu, že změnu oprávnění může provést pouze vlastník souboru, není zde nebezpečí, že by podlý uživatel přidal bit s k jiným spustitelným souborů.

Jsou zde ještě drobné odlišnosti vztahující se k Unixovým oprávněním a jejich nastavování, viz chmod(1) pro podrobnosti.

Nád rámcem tradičních Unixových oprávnění: POSIX ACL

Model oprávnění popsaný výše je vzácným příkladem konceptu pocházejícího z Unixu, který je považovaný za málo flexibilní pro dnešní použití. Přesto je také považován za typický příklad jednoduchého ale dobře použitelného bezpečnostního modelu.

Mnoho programů tento model okopírovalo a můžeme si jej tak všímat i na jiných místech. Jde tak určitě o něco, co je dobré si zapamatovat a pochopit.

Malá flexibilita systému spočívá v tom, že povolení přístupu k souboru konkrétní skupině lidí vyžaduje vytvoření speciální skupiny pro tyto uživatele. Skupiny jsou přitom definovány v /etc/group, jehož změna ale vyžaduje administrátorská práva.

S rostoucím počtem uživatelů nám také může exponenciálně růst potřebný počet skupin. Na druhou stranu pro většinu situací stačí základní Unixová oprávnění.

Abychom se vypořádali s tímto problémem, Linux poskytuje také tzv. POSIX access control lists, díky čemuž lze přiřadit libovolný seznam uživatelů k libovolnému souboru pro specifikování jejich oprávnění.

getfacl a setfacl jsou nástroje pro řízení těchto práv, ale protože jsou prakticky potřeba jen zřídka, ponecháme jejich znalost na úrovni čtení příslušných manuálových stránek a acl(5).

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?Answer.

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

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

Za předpokladu následujícího výstupu ls -l (script.sh je skutečně skript shellu) a za předpokladu, že uživatel bob je ve skupině wonderland, zatímco uživatel lewis nikoli.

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

Vyberte všechna pravdivá tvrzení.

You need to have enabled JavaScript for the quiz to work.

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č? Hint.Answer.

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/2023/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? Answer.

Mimochodem, co se stane, když se pokusíte spustit následující příkaz?

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ší.

Git na jiných platformách také nabízí generování klíče SSH, ale často je klíč použitelný pouze pro jednu aplikaci (různé aplikace mají nekompatibilní formáty klíčů), zatímco v Linuxu je jeden klíč obecně použitelný pro Git, jiné počítače a další služby.

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.

Výpis procesů není nijak chráněn před ostatními uživateli. Každý uživatel na daném počítači může vidět, co ostatní uživatelé spouštějí (včetně argumentů příkazového řádku).

Mějte tedy na paměti, že hesla se nemají nikdy předávat jako argumenty příkazového řádku a vždy je předávejte prostřednictvím souborů (s příslušnými právy) nebo interaktivně na stdin.

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 naučili? Answer.

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ů

Vyberte všechna pravdivá tvrzení. You need to have enabled JavaScript for the quiz to work.

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.

Použití tmux pro lepší práci se SSH

tmux je terminálový multiplexer. To znamená, že uvnitř jednoho terminálu vám otevře několik paralelně běžících terminálů. Umožňuje také poslat relaci na pozadí, takže tam zůstane, i když se odhlásíte nebo je vzdálené připojení přerušeno (to je užitečné pro spouštění dlouhých skriptů). Jinými slovy, tmux vám dává k dispozici záložky (tzv. okna) uvnitř vaší existující relace, které lze minimalizovat/ikonifikovat (pokud si vypůjčením termínů z GUI můžeme vysvětlit užitečnost lépe).

Nejjednodušší způsob, jak spustit relaci tmux, je jednoduše:

tmux

Případně můžeme relaci zahájit s nějakým smysluplným názvem:

tmux new -s <session_name>

Seznam všech spuštěných relací získáme pomocí:

tmux ls

Chcete-li se připojit k probíhající relaci, spusťte:

tmux attach -t <session_name>

A nakonec, abychom ukončili relaci, použijeme:

tmux kill-session -t <session_name>

V relaci můžeme vytvořit více oken, rozdělit obrazovku a mnoho dalšího. Abychom mohli vyvolat příkaz tmux, musíme nejprve zadat tzv. prefix tmuxu. Výchozí klávesou je <Ctrl>-b.

Pro odpojení od relace můžeme jednoduše stisknout (nezapomeňte napsat prefix!):

d odpojení od relace

Práce s okny:

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

Někdy je užitečné rozdělit obrazovku na několik terminálů. Tato rozdělení se nazývají panely.

Operace s panely (rozdělením):

% 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

Další funkcí je možnost přepínat psaní na všech panelech současně. Provádění stejné operace vícekrát se může zdát málo užitečné, ale můžete například předem otevřít několik různých ssh připojení a pak všechny tyto počítače interaktivně ovládat současně.

Chcete-li ji přepnout, zadejte prefix a pak napište :set synchronize-panes. Pokud to chcete vyzkoušet v Rotundě, nespouštějte výpočetně náročné úlohy…

Jak je u linuxových nástrojů obvyklé, můžete jeho chování široce modifikovat pomocí rc nastavení. Chcete-li se například pohybovat mezi panely pomocí klávesových zkratek vim, upravte soubor .tmux.conf tak, aby obsahoval následující položky

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"

Osobní tip № 0: tmux je vynikajícím nástrojem pro spolupráci, protože se k jedné relaci může připojit více uživatelů.

Osobní tip № 1: při přednášce se můžete připojit k relaci tmux ze dvou terminálů. Později první z nich strčíte do projektoru, zatímco druhý máte na obrazovce notebooku. Tím odpadá nutnost zrcadlení obrazovky. Spolu s pdfpc a dlaždicovým správcem oken získáme skutečný “švýcarský nůž” pro prezentace.

Je toho mnohem víc, co bychom mohli říct. Další podrobnosti naleznete v tomto tmuxovém taháku nebo v dokumentaci.

Konfigurace SSH

Klient SSH se konfiguruje pomocí souboru ~/.ssh/config. Přehled syntaxe tohoto souboru je v man 5 ssh_config.

Soubor je rozdělen na sekce. Každá sekce se týká jednoho nebo více vzdálených hostitelů. Záhlaví sekce je ve formátu Host vzor, kde vzor může používat zástupné znaky (wildcards).

Syntaxe je většinou samovysvětlující, proto uvedeme pouze příklad.

Host *
    IdentityFile ~/.ssh/id_ed25519

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

Host mff1
    Hostname u-pl6.ms.mff.cuni.cz
    User YOUR_SIS_LOGIN

Host mff2
    Hostname u-pl17.ms.mff.cuni.cz
    User YOUR_SIS_LOGIN

S tímto ~/.ssh/config můžeme napsat ssh intro a ssh spustí spojení odpovídající následujícímu

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

Doporučujeme v konfiguraci používat různé názvy hostitelů u-pl*, aby se zátěž rozložila mezi více počítačů. Upozorňujeme, že stroje Rotunda mohou být zatíženy nerovnoměrně, proto je dobré si jich několik založit a přihlásit se jinam, pokud je první z nich příliš pomalý.

Úlohy před cvičením (deadline: začátek vašeho cvičení, týden 13. března - 17. března)

Následující úlohy musí být vyřešeny a odevzdány před příchodem na vaše cvičení. Pokud máte cvičení ve středu v 10.40, soubory musí být nahrány do vašeho projektu (repozitáře) na GitLabu nejpozději ve středu v 10.39.

Pro virtuální cvičení je deadline úterý 9:00 (každý týden, vždy ráno, bez ohledu na možné státní svátky apod.).

Všechny úlohy (pokud není explicitně uvedeno jinak) musí být odevzdány přes váš repozitář na úkoly. Pro většinu úloh existují automatické testy, které vám mohou pomoci zkontrolovat úplnost vašeho řešení (zde je popsáno jak číst jejich výsledky).

05/rights.md (30 bodů, skupina admin)

Zkopírujte následující text do souboru 05/rights.md ve svém repozitáři a odpovězte na otázky (jako obvykle zachovejte značky pro odpovědi).

K dispozici je více možností, odpovědi oddělujte mezerami nebo čárkami, např. **[A1]** 1,2 **[/A1]**.

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]**

Vzdálený soubor ~/LAB05 (30 bodů, skupina net)

Vytvořte běžný soubor LAB05 ve svém domovském adresáři na linux.ms.mff.cuni.cz. Jako jeho jediný obsah použijte své UKČO (číslo ze svého ISICu).

Nevytvářejte tento soubor v GitLabu, budeme jej ověřovat jen na linux.ms.mff.cuni.cz.

Přítomnost tohoto souboru je poloautomaticky kontrolována pomocí GitLabové pipeline. Mezi nahráním souboru a potvrzením testy na GitLabu je však určité zpoždění.

05/key.pub (40 bodů, skupina net)

Uložte svůj veřejný klíč do tohoto souboru.

Neztraťte přístup k jeho soukromé části – budete ji potřebovat pro některé pozdější úlohy.

Úlohy po cvičení (deadline: 2. dubna)

Očekáváme, že následující úlohy vyřešíte po cvičení, tj. poté, co budete mít zpětnou vazbu k vašim řešením úloh před cvičením.

Všechny úlohy (pokud není explicitně uvedeno jinak) musí být odevzdány přes váš repozitář na úkoly. Pro většinu úloh existují automatické testy, které vám mohou pomoci zkontrolovat úplnost vašeho řešení (zde je popsáno jak číst jejich výsledky).

Git přes SSH (80 bodů, skupina net)

Pro tento úkol se ujistěte, že soubor 05/key.pub v projektu obsahuje váš aktuální veřejný klíč.

Pak naklonujte následující repozitář (jako obvykle, LOGIN je váš GitLabí login malými písmeny) a zkopírujte výstup z uname -a (z vašeho počítače) do souboru nazvaného uname.txt v tomto repozitáři a odešlete jej zpět.

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

Po naklonování bude repozitář prázdný. To je v pořádku. Prostě jen vytvořte soubor uname.txt a commitněte ho (a pushněte ho na server).

Klíče aktualizujeme každý den; chyby, prosím, hlašte pouze pokud není repozitář dostupný po více jak 24 hodinách po změně ve vašem 05/key.pub souboru.

Tato úloha není kontrolována na GitLabu.

Nahrání našeho klíče (20 bodů, skupina net)

Přidejte následující veřejný klíč mezi autorizované klíče u svého účtu na linux.ms.mff.cuni.cz. Splnění úlohy ověříme tak, že se připojíme přes SSH na linux.ms.mff.cuni.cz pod vaším uživatelským jménem a s tímto klíčem.

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

Nevytvářejte tento soubor v GitLabu, budeme jej ověřovat jen na linux.ms.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 zobrazít 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

  • 2023-03-13: Přidáno URL pro úlohu po cvičení.

  • 2023-03-14: Upřesněno, kde jsou klíče vytvářeny.

  • 2023-03-27: Upřesněno použítí příkazu chmod.