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.

Tohle cvičení také obsahuje malý domácí úkol za dva body.

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

Předstartovní kontrola

  • Umíte spouštět základní Gitové operace skrz příkazovou řádku.
  • Znáte základní principy síťování jak jsou naznačeny v našem přehledu.

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íč (pro dešifrování). 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ý může jen rozdistribuovat 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. Vždy tady budeme předpokládat, ž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íčů 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.

Existují i další možnosti, jak autentizovat uživatele, třeba pomocí speciálních aplikací nebo hardwarových klíčů (passkeys). Ty jsou nad rámec tohoto předmětu, tady se zaměříme pouze na pár veřejný/soukromý klíč.

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

Váš login bude obvykle rozlišovat malá a velká písmena. Pro naše (a univerzitní) servery to znamená, že login musí být malými písmeny.

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

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

Kdykoliv řešíte potíže s SSH, spusťte SSH klienta (ssh(1)) s volbou -v, která zapne upovídané logování, následovanou původními argumenty. Vytiskne, které klíče byly zkoušeny, úplnou identifikaci vzdáleného stroje a další užitečné detaily.

Když budete vytvářet issue o nefunkčním SSH, prosím, vždy rovnou uveďte výstup z ssh -v .... Děkujeme!

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čilo, 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í.

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

Dokážete vysvětlit rozdíly? Nápověda. Odpověď.

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í klíčů 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ý).

Volba -t určuje typ klíče, který budeme vytvářet. Na většině aktuálních systémů bude výchozí stejně Ed25519, takže můžete typ úplně vypustit.

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 autentizaci k další službě, třeba ke GitLabu (tj. linux.ms.mff.cuni.cz bude lokálním strojem v komunikaci).

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

Nezadávejte jiné umístění pro klíče ani jiný název soubor. Jinak je SSH a další program nebudou umět najít (bez další konfigurace z vaší strany)!

Až je budete nahrávat do repozitáře student-LOGIN, zkopírujte je z .ssh a přejmenujte je pouze ve vašem repozitáři (vizte úlohy na konci cvičení).

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.

Ujistěte se, že dokážete vysvětlit, co se děje v tomto případě. Pochopení příkazů níže v podstatě garantuje, že chápete, jak SSH funguje a co kde běží (a kde budou které soubory vytvořeny).

cat /etc/os-release | ssh login@linux.ms.mff.cuni.cz "cat >client-os.txt"
ssh login@linux.ms.mff.cuni.cz cat /etc/os-release >server-os.txt

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ě a v dalších učebnách

Kromě stroje linux.ms.mff.cuni.cz jsou k dispozici také další stroje.

Všechny počítače se systémem Linux v učebnách (a v Rotundě na Malostranském náměstí) jsou rovněž přístupné přes SSH. K přihlášení opět použijte své přihlašovací údaje do SISu. 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.

Stejný domovský adresář je sdílený napříč všemi stroji na Malostranském náměstí a v IMPAKTU (takže pokud se SSHčknete na u-pl1.ms.mff.cuni.cz a vytvoříte tam soubor, tak je to totéž, jako když fyzicky dorazíte do učebny N8/N11 a vytvoříte soubor, když jste přihlášeni skrz GUI).

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 během výuky. Počítače v Rotundě jsou k dispozici 24/7.

Host keys

Níže je seznam našich serverů a jejich tzv. host keys (ty jsou zobrazeny při prvním připojení a SSH vás varuje, pokud se změní).

  • u-pl0.ms.mff.cuni.cz
    • 256 SHA256:a4cEChPmXAbaQiEb4QKmDvddk/pgXqusLRIQLsQTKFM u-pl0.ms.mff.cuni.cz (ED25519)
    • 256 SHA256:U6u6eLekctQDr9uy4CKZJeDFjcCWqCI/v9owL1NODcE u-pl0.ms.mff.cuni.cz (ECDSA)
    • 1024 SHA256:8NUbwUmLxG3NfKSLy0ORuOxjQBTSirnXo1p/WQ0Z6vw u-pl0.ms.mff.cuni.cz (RSA)
  • linux.ms.mff.cuni.cz
    • 256 SHA256:/CVwDW388z6Z5VlhLJT0JX+o1UzakyQ+S01+34BI0BA linux.ms.mff.cuni.cz (ED25519)
    • 256 SHA256:ltoc1TjoYhCZk6b8qSTAL6wFsRv7blw6u3h6NqCcYvI linux.ms.mff.cuni.cz (ECDSA)
    • 3072 SHA256:Z11Qbd6nN6mVmCSY57Y6WmxIJzqEFHFm47ZGiH4QQ9Y linux.ms.mff.cuni.cz (RSA)
  • gitlab.mff.cuni.cz
    • 256 SHA256:jRH0TCd3DTvckbie4NNSAqiUOs/H/J3X44zhLyG2x0E gitlab.mff.cuni.cz (ED25519)
    • 256 SHA256:feqdasElJ4gNZxPFoR6ynKl8ERDPSV/66jWQBUykzuk gitlab.mff.cuni.cz (ECDSA)
    • 2048 SHA256:Irez3gnPeMX5S8dniRsqTZU7hpuoqIXGsHI92IGte7o gitlab.mff.cuni.cz (RSA)

SSH: zopakujte si své znalosti

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

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

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

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 bude Git záviset 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/2025/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ěď.

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.

Základní síťové nástroje

Po většinu času bude síťování na vašem stroji prostě fungovat.

Ale pokud se vyskytnou problémy, je dobré vědět, které nástroje jsou k dispozici a jak provést základní diagnostiku.

Network Manager

Existuje několik způsobů, jak konfigurovat síť v Linuxu. Správci serverů často dávají přednost použití základního příkazu ip nebo nastavení síťování pomocí systemd-networkd; na stolních počítačích dnes většina distribucí používá NetworkManager, takže si jej ukážeme i zde. Všimněte si, že stránka ArchLinux Wiki o NetworkManageru obsahuje také mnoho informací.

Konfigurace sítě na serveru je součástí předmětu Administrace Linuxu.

NetworkManager má grafické rozhraní (pravděpodobně jste použili jeho applet, aniž byste o tom věděli), rozhraní TUI (které lze spustit pomocí nmtui) a nakonec rozhraní CLI.

Zde se (ze zřejmých důvodů) zaměříme na rozhraní příkazového řádku. Bez parametrů zobrazí nmcli informace o aktuálních spojeních:

wlp58s0: connected to TP-Link_1CE4
        "Intel 8265 / 8275"
        wifi (iwlwifi), 44:03:2C:7F:0F:76, hw, mtu 1500
        ip4 default
        inet4 192.168.0.105/24
        route4 0.0.0.0/0
        route4 192.168.0.0/24
        inet6 fe80::9ba5:fc4b:96e1:f281/64
        route6 fe80::/64
        route6 ff00::/8

p2p-dev-wlp58s0: disconnected
        "p2p-dev-wlp58s0"
        wifi-p2p, hw

enp0s31f6: unavailable
        "Intel Ethernet"
        ethernet (e1000e), 54:E1:AD:9F:DB:36, hw, mtu 1500

vboxnet0: unmanaged
        "vboxnet0"
        ethernet (vboxnet), 0A:00:27:00:00:00, hw, mtu 1500

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 192.168.0.1 8.8.8.8
        interface: wlp58s0

...

Porovnejte výše uvedené údaje s výstupem příkazu ip addr. Všimněte si, že NetworkManager explicitně uvádí výchozí trasy a také vás informuje, že některá rozhraní neovládá (zde lo nebo vboxnet0).

Změna IP konfigurace

Přestože většina sítí nabízí DHCP (alespoň ty, ke kterým se připojujete pomocí svého počítače), někdy je třeba nastavit IP adresy ručně.

Typickým příkladem je situace, kdy potřebujete dočasně propojit dva počítače, např. pro přenos velkého souboru přes kabelové připojení (v našem případě je to přes rozhraní enp0s31f6).

Nezapomeňte, že IP adresa je navázaná na rozhraní (interface, často jen if). Při konfigurace IP adres je tedy potřeba vědět jak síť (subnet) tak i rozhraní.

Jediné, o čem musíte rozhodnout, je, jakou síť vytvoříte. Nepoužívejte stejnou, jakou používá váš domácí router; naše oblíbená volba je 192.168.177.0/24.

Následující příkaz přidá na enp0s31f6 připojení s názvem wired-static-temp, přičemž vychází z výše uvedeného názvu:

sudo nmcli connection add \
    con-name wired-static-temp \
    ifname enp0s31f6 \
    type ethernet \
    ip4 192.168.177.201/24

Často je potřebné aktivovat spojení pomocí následujícího příkazu:

sudo nmcli connection up wired-static-temp

Stejný postup proveďte i na druhém hostiteli, ale použijte jinou adresu (např. .202). Nyní byste měli být schopni pingnout druhý počítač:

ping 192.168.177.201

Chcete-li demonstrovat, jak se ping chová při výpadku připojení, můžete zkusit odpojit kabel nebo provést totéž softwarově:

sudo nmcli connection down wired-static-temp

A až budete končit, můžete ji úplně odstranit pomocí nmcli connection delete.

Výše uvedený příkaz pro vytvoření připojení po Ethernetu může být upraven i pro WiFi sítě (ale tam je celkem velká šance, že už bude s DHCP: nakonec i NetworkManager dokáže takovou síť vytvořit, dokonce včetně sdílení připojení k Internetu).

nmcli connection add \
    con-name wifi-static-temp \
    ifname wlp58s0 \
    type wifi \
    ssid "SSID dané Wifi" \
    wifi-sec.key-mgmt "wpa-psk" \
    wifi-sec.psk "WiFi heslo" \
    ip4 192.168.177.203/24

Další síťové nástroje

Nebudeme zde suplovat kurzy síťování, ale zmíníme se o některých základních příkazech, které by vám mohly pomoci při ladění základních problémů souvisejících se sítí.

Již znáte ping: základní nástroj pro zjištění, zda je počítač s danou IP adresou spuštěn (a reaguje na síťový provoz).

ping je základní nástroj pro případ, že náhle ztratíte spojení s nějakým serverem. Pingněte cílový server a také nějaký jiný známý server. Pokud pakety procházejí, víte, že problém je někde jinde. Pokud projdou pouze pakety na dobře známý server, problém je pravděpodobně na daném serveru. Pokud selžou oba, síť pravděpodobně nefunguje.

K dispozici jsou však i pokročilejší nástroje.

traceroute (neboli cesta je cíl)

Někdy se může hodit znát přesnou cestu, kterou pakety procházejí. Pro tento druh úloh můžeme použít traceroute.

Podobně jako v případě ping musíme zadat pouze cíl.

traceroute 1.1.1.1

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  _gateway (10.16.2.1)  2.043 ms  1.975 ms  1.948 ms
 2  10.17.0.1 (10.17.0.1)  1.956 ms  1.971 ms  1.961 ms
 3  gw.sh.cvut.cz (147.32.30.1)  1.947 ms  1.973 ms  1.977 ms
 4  r1sh-sush.net.cvut.cz (147.32.252.238)  2.087 ms  2.262 ms  2.527 ms
 5  r1kn-konv.net.cvut.cz (147.32.252.65)  1.856 ms  1.849 ms  1.847 ms
 6  kn-de.net.cvut.cz (147.32.252.57)  1.840 ms  1.029 ms  0.983 ms
 7  195.113.144.172 (195.113.144.172)  1.894 ms  1.900 ms  1.885 ms
 8  195.113.235.99 (195.113.235.99)  4.793 ms  4.748 ms  4.723 ms
 9  nix4.cloudflare.com (91.210.16.171)  2.264 ms  2.807 ms  2.814 ms
10  one.one.one.one (1.1.1.1)  1.883 ms  1.800 ms  1.834 ms

První sloupec odpovídá počtu skoků. Druhý sloupec představuje adresu tohoto skoku a za ním jsou uvedeny tři časy oddělené mezerou v milisekundách. Příkaz traceroute odešle na cíl tři pakety a každý z časů označuje dobu, za kterou paket na cíl dorazí. Z výše uvedeného výstupu tedy vidíme, že balíčky na své cestě mezi místním počítačem a cílem provedly celkem 10 skoků.

Tento nástroj je užitečný zejména tehdy, když máte potíže se sítí a nejste si jisti, kde je problém.

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  10.21.20.2 (10.21.20.2)  0.798 ms  0.588 ms  0.699 ms
 2  10.21.5.1 (10.21.5.1)  0.593 ms  0.506 ms  0.611 ms
 3  192.168.88.1 (192.168.88.1)  0.742 ms  0.637 ms  0.534 ms
 4  10.180.2.113 (10.180.2.113)  1.696 ms  4.106 ms  1.483 ms
 5  46.29.224.17 (46.29.224.17)  14.343 ms  13.749 ms  13.806 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Z tohoto protokolu vidíme, že poslední navštívený skok byl 46.29.224.17, takže se můžeme zaměřit na tento síťový prvek.

nmap (aneb průzkum vaší sítě)

nmap je velmi mocný nástroj. Bohužel i nevinné – ale opakované – použití může být snadno chybně interpretováno jako škodlivé skenování zranitelností, které jsou náchylné k útoku. Používejte tento nástroj opatrně a experimentujte ve své domácí síti. Bezohledné skenování univerzitní sítě může ve skutečnosti vašemu počítači na nějakou dobu zakázat jakékoli připojení.

nmap je základní nástroj pro skenování sítě. Pokud chcete zjistit, které síťové služby jsou na počítači spuštěny, můžete se zkusit připojit ke všem jeho portům a zjistit, které jsou otevřené. Nmap to umí a ještě mnohem více.

Zkuste nejprve zkontrolovat zařízení zpětné smyčky (loopback), zda v počítači nejsou spuštěny interní služby:

nmap localhost

Výsledek by mohl vypadat takto (počítač má tiskový server a HTTP proxy server):

Starting Nmap 7.91 ( https://nmap.org ) at 2021-05-04 16:38 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00011s latency).
Other addresses for localhost (not scanned): ::1
rDNS record for 127.0.0.1: localhost.localdomain
Not shown: 998 closed ports
PORT     STATE SERVICE
631/tcp  open  ipp
3128/tcp open  squid-http

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds

Pokud chcete zobrazit více informací, můžete zkusit přidat parametr -A.

nmap -A localhost

A pokud jej spustíte pod rootem (tj. sudo nmap -A localhost), může se nmap pokusit detekovat i vzdálený operační systém.

Ve výchozím nastavení nmap skenuje pouze porty často používané síťovými službami. Pomocí volby -p můžete zadat jiný rozsah:

nmap -p1-65535 localhost

Tento příkaz dává nmap pokyn ke skenování všech portů TCP (-p1-65535) na localhost.

Opět: neskenujte všechny porty TCP na počítačích v univerzitní síti!

Cvičení: Který webový server se používá v našem GitLabu? A který je na našich univerzitních webových stránkách? Řešení.

nc (netcat)

Podívejme se, jak vytvořit síťové připojení ze shellu. To je nezbytné pro ladění síťových služeb, ale je to také užitečné pro použití sítě ve skriptech.

Švýcarský armádní nůž síťového skriptování se nazývá netcat nebo nc.

Bohužel existuje více implementací netcatu, které se liší možnostmi a schopnostmi. My si ukážeme ncat, který je ve Fedoře standardně nainstalován. Ve vašem systému může být nainstalována jiná varianta.

Nejprve triviální věci: chcete-li se připojit k danému portu TCP na vzdáleném počítači, můžete spustit příkaz nc machine port. Tím se naváže spojení a připojí se k němu stdin a stdout. Můžete tedy komunikovat se vzdáleným serverem.

Netcat se často připojuje k jiným příkazům pomocí rour. Napišme si základního HTTP klienta:

echo -en "GET / HTTP/1.1\r\nHost: www.kernel.org\r\n\r\n" | nc www.kernel.org 80

Používáme \r\n, protože protokol HTTP vyžaduje řádky ukončené CR+LF. Hlavička Host: je povinná, protože protokol HTTP podporuje více webových stránek běžících na stejné kombinaci IP adresy a portu.

Vidíme, že http://www.kernel.org/ nás přesměruje na https://www.kernel.org/, a tak to zkusíme znovu pomocí HTTPS. Naštěstí naše verze programu netcat umí pracovat s protokolem TLS (transport-layer security), který se používá k šifrování:

echo -en "GET / HTTP/1.1\r\nHost: www.kernel.org\r\n\r\n" | nc --ssl www.kernel.org 443

Nyní vytvoříme jednoduchý server. Bude naslouchat na portu TCP 8888, a když se k němu někdo připojí, server pošle na toto připojení obsah daného souboru:

nc --listen 8888 <path-to-file

Můžeme otevřít nový shell a zkusit soubor přijmout:

nc localhost 8888

Soubor obdržíme, ale netcat se neukončí – stále čeká na vstup ze stdin. Stisknutí klávesy Ctrl-D funguje, ale je jednodušší říct netcatu, aby pracoval pouze jedním směrem:

nc localhost 8888 --recv-only

OK, pro přenos jednoho souboru po síti to funguje. (Mějte však na paměti, že přenos není šifrovaný, takže není rozumné jej používat ve veřejné síti.)

Po přenosu souboru se server ukončí. Co když chceme spustit server, který zvládne více připojení? Zde přesměrování nestačí, protože potřebujeme soubor číst vícekrát. Místo toho můžeme požádat netcat, aby pro každé spojení spustil příkaz shellu a propojil spojení s jeho stdin a stdout:

nc --listen 8888 --keep-open --sh-exec 'cat path-to-file'

To lze samozřejmě využít k mnohem zajímavějším věcem, než je odesílání souboru. Můžete vzít libovolný program, který komunikuje přes stdin a stdout, a udělat z něj síťovou službu.

Další kroky: používání tmuxu pro ještě lepší práci s SSH

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

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 tmuxu, 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
& zavří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 zavří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 vimu, 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.

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

Uložte vaše veřejné klíče do keys/key.[0-9].pub na GitLabu (wildcard slouží k tomu, abyste mohli nahrát klíčů více, pokud používáte více strojů – pochopitelně se budou soubory jmenovat keys/key.0.pub nebo keys/key.1.pub).

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

Tento příklad vám může zkontrolovat GitLab skrz automatizované testy. Uložte vaše řešení jako keys/key.[0-9].pub a commitněte ho (pushněte) do GitLabu.

Hodnocený malý domácí úkol

Tohle začne fungovat až když nahrajete vaše klíče do keys/key.[0-9].pub.

Potom byste měli být schopní naklonovat tenhle repozitář (jako obvykle, LOGIN je GitLabový login malými písmeny) přes SSH.

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

Klíče aktualizujeme každý den; chyby, prosím, hlaste pouze pokud není repozitář dostupný po více jak 24 hodinách po změně ve vašich keys/key.[0-9].pub souborech.

Pokud po vás bude chtít příkaz git clone heslo, je pravděpodobně chyba ve vašem nastavení. Budete používat přihlašování pomocí klíčů, čili jediné heslo, které v této konfiguraci dává smysl je fráze (passphrase) k vašemu (privátnímu) klíči (pokud jste se rozhodli ji nastavit).

Rozhodně nepoužívejte vaše heslo ke GitLabu. Nebude to fungovat.

Typičtí podezřelí: zkontrolujte, že jste na stroji, z něhož jste klíč nahráli (zkontrolujte ~/.ssh), počkejte 24 hodin po nahrání klíčů, zkontrolujte, že pipeline keys je zelená.

Po naklonování bude repozitář prázdný (a Git vám to řekne). To je v pořádku. Cílem je ověřit, že zvládnete naklonovat další repozitář aniž byste měli k dispozici nějaké webové rozhraní.

Vytvořte soubor uptime.txt s výstupem příkazu uptime a soubor uname.txt obsahující výstup uname -a.

Tyto soubory budou v kořenovém adresáři repozitáře. Commitněte je a _push_něte změny zpátky na server.

Termín dokončení tohoto úkolu je 23. března.

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

Vytvoříme vám soubor FROM_TEACHERS jakmile náš klíč nastavíte (opět, dejte nám ale nějaký čas na spuštění našich skriptů).

Tohle je tu proto, abychom si ověřili, že umíte nastavit přístup pro někoho jiného, aniž by se něco rozbilo :-).

Učební výstupy a kontrola po cvičení

Tato část podává 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ů).

Kontrola po cvičení

Seznam níže shrnuje nejdůležitější činnosti (akce), které byste měli mít touto dobou provedené. Pokud tomu tak nebude, nebudete moci dokončit další cvičení nebo se tím jeho průchod výrazně zkomplikuje.

  • Mám nahraný veřejný klíč k mému GitLabovému projektu.

  • Mám hotový malý domácí úkol.

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 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, proč je použití nmap obvykle omezeno/zakázáno správci sítě

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 …

  • nastavit proměnnou PS1 pro rozlišení různých strojů

  • použít příkaz 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řenášet soubory 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žít git clone (a pull a push) přes SSH

  • volitelné: nastavit zkratky pro SSH

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

  • použít nc pro základní operace

  • použít nmap pro základní skenování sítě

  • použít ip k dotazování na stav aktuální síťové konfigurace

  • použít utility ping a traceroute jako základní nástroje pro ladění síťových problémů

  • volitelné: použít NetworkManager k nastavení statických IP adres

Seznam změn na této stránce

  • 2025-03-11: Další tipy k hodnocenému malému domácímu úkolu.

  • 2025-03-12: nmcli příklad pro Wifi.

  • 2025-03-14: Skripty pro kontrolu klíče teachers-nswi177@d3s.mff.cuni.cz(FROM_TEACHERS) jsou teď spouštěny dvakrát denně.

  • 2025-03-18: Explicitně zmíněno, že je potřeba vědět, ke kterému rozhraní je IP adresa navázána.

  • 2025-03-21: Přidány host keys MFF serverů.

  • 2025-04-09: Zvláštní výstraha k názvům souborů s klíči.