Šifrované spojení - ssh

Instalace programů

Umístění ssh autorizace a klíčů

Zakázání oprávnění přístupu čtení a zápisu všem, kromě uživatele vlastníka a to na celý adresář ~/.ssh .

💻 mkdir ~/.ssh

💻 chmod -R u+w,go-rwx ~/.ssh

Strana klient

Zde se jedná především o soubory klíče privátního (bez koncovky .pub) a přidruženého veřejného (s koncovkou .pub).

~/.ssh/uzivatel@hostname_key
~/.ssh/uzivatel@hostname_key.pub

Lze na klient uživateli přednastavit, který klíč se má požívat, pokud není v ssh příkazu uveden za parametrem -i ... a to v souboru

💻 vi ~/.ssh/config

Vloži:

Host *
    IdentityFile ~/.ssh/uzivatel@hostname_key

Strana server

Zde na cílové straně je především soubor autorizace authorized_keys, obsahující obsahy veřejných klíčů od klientů s možností dalších restrikcí, kterým je tímto umožněno navázání spojení.

Vygenerování ssh klíče

Omezení přístupu na sshd server pouze na autentikaci klíče

Strana server

Sshd server umožňuje ověření uživatele heslem jako má login v Linuxu (uživatel root toto povolené standardně nemá). Šifrování zůstává, výhodou snad je jen, že pro přihlášení odpadá nutnost mít pořešené na klientu a serveru klíče. Ovšem použitím klíčů je adresnější kontrola přístupů a oprávnění, což více posiluje zabezpečení. V principu vypnout přihlášení přes login heslo a ponechat autentikaci na heslo klíče. Jedná se o změnu v konfiguračním souboru:

💻 sudo vi /etc/ssh/sshd_config

Vložit:

PasswordAuthentication no
StrictModes no
ChallengeResponseAuthentication no
UsePAM no
PrintMotd no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server

⚠️ Pozor u server instalace na cloud-init

Parametr PasswordAuthentication no je přebíjen stejným povolujícím parametrem v cloud-ini a tím stále umožňuje přihlášení přes klasický login.
Odinstalovat.

💻 sudo apt remove --purge cloud-init

💻 sudo rm -rf /etc/cloud /var/lib/cloud /etc/ssh/sshd_config.d/50-cloud-init.conf

Zavedení změn

💻 sudo systemctl reload sshd.service

u server instalace

💻 sudo systemctl reload ssh

Autorizace a restrikce přístupu klienta na sshd server

Akcetpovatelný klient má na cílovém sshd serveru u uživatele, na který se přihlašuje v autorizačním souboru ~/.ssh/authorized_keys připsán obsah souboru klientova veřejného klíče (soubor s koncovkou .pub). V autorizačním souboru co klient, to řádek a přidaná omezení pro daného klienta se vkládají do stejného řádku kde má veřejný klíč. Omezení jsou obzvlášť nutná pro nezaheslované klíče (případ bezobslužného navázání spojení).

Příklad plných omezení, kdy klientem vložený příkaz cíl ignoruje a odpoví jen echem (pro ignoraci bez odezvy lze: command="/bin/true"):

command="/bin/echo ECHO: $SSH_ORIGINAL_COMMAND",no-X11-forwarding,no-agent-forwarding,no-user-rc,no-pty

Uživatel pro navazování tunnel spojení

Pro možnost přístupu například admina s pevnou, veřejnou IP na klienta, který nemá pevnou, veřejnou IP, je za NATetm lze přes šifrovaný ssh tunnel navazovaný klientem. Navázání ssh tunnel spojení je pouze poskytnutí portu, přes který se dá zpět na klienta přihlásil už zaheslovaným ssh loginem.

Z důvodu bezpečnosti je nejvhodnější navazovat tunnel spojení pouze pod uživatelem s k tomu omezenými právy.

Na klientu: Vytvoření uživatele „tunnel“ pouze k navazování tunnel spojení

Zvolené ID 1999 pro uživatele tunnel musí být na klientu unikátní (pokud již existuje, zvolit jiný).
Klientem poskytnutý ssh cílový port 55520 musí být na adminu unikátní, jinak pro něj zvolit jiný.
Pro přehlednost jsem zde zvolil pojmenování ssh klíče složeného z uživatele tunnel, hostname klienta a poskytovaného portu (sestaveného do proměnné NAME). Vytvoří se nezaheslovaný ssh klíč, dva soubory, kdy jeho veřejná část (soubor s koncovkou .pub) se předá adminovi, ktery je u sebe vloží autorizačního souboru a tím povolí klientu možnost navázat ssh tunnel spojení.
Nakonec omezení přístupvých práv do skrytého adresáře /home/.tunnel .

💻 sudo useradd -u 1999 -g 65534 -c "Pro tunelovani portu" -Md /home/.tunnel -s /bin/false -o tunnel

💻 sudo mkdir -p /home/.tunnel/.ssh

💻 NAME="tunnel@`hostname -s`"

💻 sudo ssh-keygen -t ed25519 -N "" -C "${NAME}_key" -f /home/.tunnel/.ssh/${NAME}_key

💻 sudo chown -R tunnel:nogroup /home/.tunnel

💻 sudo chmod -R u-w,go-rwx /home/.tunnel

Na adminu: Vytvoření uživatele pouze pro navazování tunnel spojení

Princip stejný jako na klientu s rozdílem, kdy místo generování klíče se vytvoří autorizační soubor authorized_keys obsahující veřejnou část ssh klíče klienta (obsah souboru s .pub koncovkou) a omezení práv jen pro tunnel spojení a jen určitý port 55520. Zde je v příkladu obecně hostname ve jméně souboru tunnel@hostname_key.pub a jeho obsah přidán do authorized_keys souboru echo příkazem.
Nakonec omezení přístupových práv celému adresáři /home/.tunnel .

💻 sudo useradd -u 1999 -g 65534 -c "Pro tunelovani portu" -Md /home/.tunnel -s /bin/false -o tunnel sudo mkdir -p /home/.tunnel/.ssh

💻 sudo echo 'permitopen="localhost:55520",command="/bin/true",no-X11-forwarding,no-agent-forwarding,no-user-rc,no-pty' `cat /home/.tunnel/.ssh/'tunnel@hostname_key.pub'` |sudo tee -a /home/.tunnel/.ssh/authorized_keys

💻 sudo chown -R tunnel:nogroup /home/.tunnel

💻 sudo chmod -R u-w,go-rwx /home/.tunnel

Na klientu: Navázání tunnel spojení s adminem

Příklad sdílení SAMBA soborového systému přes tunnel

Jde o šifrované tunelování, serverem poskytnutí SAMBA portu klientu s autentikací nezaheslovaného ssh klíče jen pro bezobslužnému navázání spojení a zároveň omezení klienta pouze pro účel tunelování (převzetí) SAMBA portu.

Z cílového serveru si klient tunelem nasdílí samba port 445 k sobě jako lokální např. 55445. Po aktivaci tohoto port tunelu bude možné sdílení souborové odkazem lokálně na port 55445 (localhost).

Na klientu: Vygenerování bezheslového klíče pro navázání tunnel spojení

S parametrem -N "" se vygeneruje klíč rovnou nezaheslovaný. Vzniknou soubory: ~/.ssh/samba@hostname_NOPWD_key a ~/.ssh/samba@hostname_NOPWD_key.pub

💻 ssh-keygen -t ed25519 -N "" -C "samba@hostname_NOPWD_key" -f ~/.ssh/samba@hostname_NOPWD_key

Na serveru: Nastavení omezení pro bezheslové navázání pouhého tunnel spojení

Do souboru ~/.ssh/authorized_keys se přidá řádek obsahující pravidla omezující spojení a obsah souboru veřejného klíče klienta. Nepopisuji jak překopírovat předem tento veřejný klíč z klienta na server.

💻 echo 'permitopen="localhost:445",command="/bin/true",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-user-rc,no-pty' `cat ~/.ssh/samba@hostname_NOPWD_key.pub` >> ~/.ssh/authorized_keys cat ~/.ssh/authorized_keys

Na klientu: Tunnel spojením převzetí ze serveru port 445 a jeho lokální poskytnutí jako 55445

Pro otestování je přidán parametr -v (debug mód) a nepoužít -q ,aby nebyl potlačen výpis. Při úspěchu lze potlačit výpisy odebráním -v a přidáním -q .

💻 ssh -v -CXNn -F /dev/null -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o ConnectTimeout=7 -o ConnectionAttempts=1 -o ServerAliveCountMax=2 -o ServerAliveInterval=120 -L 55445:localhost:445 -i ~/.ssh/samba@hostname_NOPWD_key uzivatel@cilovy.server.com

Jelikož navázané ssh tunnel spojení nevrátí promtp (lze ukončit [Ctrl]), tak z jiného terminálu klienta otestovat průchodnost tunelu

💻 nc -vzw 1 localhost 55445 && echo OK || echo FAILED

Vrátí-li nc příkaz „OK“ a zároveň ssh tunel spojení nevypíše chybu „channel 1: open failed: administratively prohibited: open failed„, je možno zkusi připojit souborové sdílení.

Dál je to dosti individuální dle konfigurace na straně samba serveru, tak jen ilustračně příklad připojení sdílení s názvem „ShareDir“ na adresář „/mnt“ .

💻 sudo mount.cifs -o username=uzivatel,port=55445 //localhost/ShareDir /mnt

Vygenerování ssh klíče pro sftp spojení z mobilu

Akceptace pouze souboru klíče v ssh parametru „-i“ 🆘

Zakázání zadávání ssh hesla přes dialogového okno 🆘