Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
ssh prihlasovacie_meno@server
ponúka ssh množstvo ďalších užitočných vlastností. Tento článok chce ukázať niektoré z nich.
Pre účely nižšie uvádzaných príkladov použijeme model siete podľa nasledujúceho obrázku:
Legenda:
PC0 je klient, počítač za ktorým používateľ fyzicky sedí; všetky príkazy v príkladoch sú zadávané na stroji PC0, pokiaľ nie je uvedené inak
PC1..PC5 sú počítače, ktorých služby chce používateľ využiť, služby dostupné cez sieť (otvorené sieťové porty) sú vymenované za označením PC
šípky predstavujú priamu sieťovú viditeľnosť (z PC0 je priamo dostupné ssh na PC2, ale PC0 nevidí ani PC3, ani PC4)
userN a pod. sú prihlasovacie mená (účty), adresy atď vzťahujúce sa na príslušné PC
PC0 môže byť domáce PC, PC1 nejaký vhodný (má pevnú verejnú IP adresu) stroj na internete, PC2..PC5 môže byť firemná sieť za firewallom/NAT, z ktorej je na pevnej verejnej IP adrese viditeľný iba ssh port PC2.
Ssh umožňuje preukázať totožnosť prihlasujúceho sa používateľa rôznymi spôsobmi, typicky sú to heslo a privátny kľúč. Prihlasovanie heslom má jedinú výhodu v tom, že je jednoduché. K nevýhodám patrí prinajmenšom riziko slabých hesiel a tým možnosť útoku na server a komplikácia pri skriptovaní*. Správca servera by mal prihlasovanie heslom zakázať ako jednu z prvých vecí pri konfigurovaní nového servera.
*) dá sa obísť cez sshpass
Kľúč si musí nechať vygenerovať každý používateľ sám za seba. Príkaz je
ssh-keygen -t rsa -C "<Meno> rsa-sha2-512 <dátum generovania>" ssh-keygen -t ed25519 -C "<Meno> ed25519 <dátum generovania>"
RSA kľúč má lepšiu kompatibilitu smerom ku starším systémom, ale kombinácia so SHA-1 (čiže ssh-keygen -t ssh-rsa
) sa už dnes nepovažuje za bezpečnú. Kľúč na báze eliptickej krivky 25519 je dnes asi najbezpečnejšia voľba (ale napr. starý CentOS 6 ju nepozná). Vygenerovaný kľúč je rozumné chrániť heslom, ssh-keygen
vyzve na jeho zadanie.
Je vhodné zadávať pri generovaní kľúča komentár, z ktorého bude jasné, koho alebo čoho sa kľúč týka, aký je to kľúč a aký je starý.
V adresári ~/.ssh/
vznikne vždy dvojica súborov, pokiaľ si používateľ nezvolí vlastné meno súboru, sú to
id_rsa id_rsa.pubresp.
id_ed25519 id_ed25519.pub
Súbory bez koncovky .pub
obsahujú kompletný kľúč, vrátane privátnej časti, ktorá je potrebná pri autentifikácií a preto ich treba chrániť. Ak sa útočník dostane ku privátnemu kľúču a prekoná prípadné heslo, môže v plnom rozsahu používať identitu obete na všetkých strojoch, kde je kľúč použitý. Ak používateľ stratí súbor s privátnym kľúčom alebo zabudne heslo, stratí možnosť prihlasovať sa tým kľúčom.
Obsah súboru .pub
(verejnú zložku kľúča) je potrebné dostať na server ako nový riadok do súboru authorized_keys
(/home/userN/.ssh/authorized_keys
). Ak ešte nie je zakázané prihlasovanie iným spôsobom, napr. heslom, môže to spraviť používateľ sám, ručne textovým editorom, alebo utilitou ssh-copy-id
. V opačnom prípade musí riadok pridať správca servera.
Aby nebolo nutné zadávať heslo ku ssh kľúču (resp. ku všetkým ssh kľúčom ~/.ssh/id_*
) pri každom otváraní ssh spojenia, je rozumné spustiť program ssh-agent
. Do vhodného skriptu, spúšťaného po prihlásení, napr. ~/.profile
treba pridať riadky
eval `ssh-agent` ssh-add
PAGEANT.EXE
. Aby identické kľúče, aké spravuje pageant
, boli dostupné aj pre programy z prostredia Cygwin, treba použiť (napr. v .bash_profile
) utilitu ssh-pageant
if [ -z "$SSH_AUTH_SOCK" -a -x /usr/bin/ssh-pageant ]; then eval $(/usr/bin/ssh-pageant -q) fiUtilitu
ssh-pageant
je vhodné ukončiť, keď už nie je potrebná, aby nezostávali v systéme bežať zbytočné procesy (riadky do .bash_logout
):
if [ -x /usr/bin/ssh-pageant -a ! -z "$SSH_PAGEANT_PID" ]; then eval $(/usr/bin/ssh-pageant -qk 2>/dev/null) fi
ssh -p port2 user2@PC2
ssh -L lokálna_adresa:lokálny_port_služby:PC3:port_služby user2@PC2Voľba -L sa može v príkaze opakovať a môže sprístupňovať služby/porty z rôznych počítačov. Kombinácia
lokálna_adresa:lokálny_port
musí byť unikátna a musí sa jednať o neobsadený port.
ssh -L 127.2.0.1:5900:PC2:5900 -L 127.3.0.1:5900:PC3:5900 -L 127.3.0.1:4080:PC3:80 user2@PC2sprístupní službu VNC z PC2 na adrese 127.2.0.1:5900, službu VNC z PC3 na adrese 127.3.0.1:5900 a službu HTTP z PC3 na adrese 127.3.0.1:4080.
Situácia: Vo firemnej LAN je zapnutý Windows počítač (PC3, PC4). Pracovník má doma svoj Windows počítač (PC0), z ktorého by mohol pracovať. LAN samozrejme nie je priamo prístupná z internetu a firemný správca nemôže natoľko dôverovať domácemu počítaču, aby ho pripojil do LAN cez VPN. Je však k dispozícii server (PC2), ktorý má ssh viditeľné z internetu a súčasne server vidí do LAN.
Príprava: Na PC3 a PC4 povoliť RDP a povoliť používateľovi prihlasovanie cez RDP.
Na PC2 vytvoriť účet pre použivateľa (user2) ako portforward-only, zapísať jeho kľúč do authorized_keys
.
Na PC0 nainštalovať PuTTY, pripraviť skripty, vytvoriť rdp súbory.
Pripoj_LAN.cmd
. Jedno ssh spojenie dokáže obslúžiť viaceré porty. PuTTY sa predpokladá v C:\bin\putty\
.
@echo off TITLE %0 %1 %2 @set srv=PC2 set LOGIN=user2 if not %1_ == _ set LOGIN=%~1 set LPORT=22 if not %2_ == _ set LPORT=%~2 copy /b c:\bin\putty\plink.exe "%TEMP%\Plink_for_LAN.exe" tasklist /FI "IMAGENAME eq PAGEANT.EXE" 2>nul: | find "PAGEANT.EXE" 2>nul: >nul: if not errorlevel 1 goto :PAGEANT_DONE if not exist C:\bin\putty\Pageant-start.cmd goto :PAGEANT_DONE call C:\bin\putty\Pageant-start.cmd :PAGEANT_DONE @echo. @echo on "%TEMP%\Plink_for_LAN.exe" -batch ^ -L 127.3.0.1:53389:PC3:3389 ^ -L 127.4.0.1:53389:PC4:3389 ^ -P %LPORT% -N -2 -v %LOGIN%@%srv%
Súbory RDP_PC3.RDP
a RDP_PC4.RDP
: ako adresu, na ktorú sa má pripojiť Remote Desktop protokolom je potrebné uviesť 127.3.0.1:53389 a 127.4.0.1:53389.
Hlavný skript, Spusti_PC3_Remote_Desktop.cmd
, ktorým bude používateľ spojenie štartovať (skript Spusti_PC4_Remote_Desktop.cmd
sa bude líšiť len vo výpisoch a vo volaní iného RDP; v prípade zbierky skritpov, kde dochádza ku pripájaniu sa do rôznych lokalít (rôznych LAN), bude zmena ešte v manažmente procesu Plink_for_XY a vo volaní iného skriptu Pripoj_XY.cmd).
@echo off @echo Start PC3 Remote Desktop set RP=%~dp0 set RP=%RP:~0,-1% set PLINK_IMG=Plink_for_LAN.exe tasklist /FI "IMAGENAME eq %PLINK_IMG%" 2>nul: | find "%PLINK_IMG%" 2>nul: >nul: if not errorlevel 1 goto :CONNECTED start "Connect to LAN" "%RP%\Pripoj_LAN.cmd" @echo Waiting for connection to LAN :WAIT_CONNECT tasklist /FI "IMAGENAME eq %PLINK_IMG%" 2>nul: | find "%PLINK_IMG%" 2>nul: >nul: if errorlevel 1 goto :WAIT_CONNECT :CONNECTED @echo Starting ping 127.0.0.1 >nul: start "PC3 RDP" mstsc.exe "%RP%\RDP_PC3.RDP"
Použivateľ pokliká na Spusti_PC3_Remote_Desktop.cmd
, zadá heslo ku svojmu SSH kľúču (iba prvý krát), po chvíľke sa mu objaví prihlasovací dialóg do RDC, po prihlásení normálne pracuje na svojom počítači v práci len pri tom používa domácu klávesnicu, myš a obrazovku.
ssh -L 127.3.0.1:53022:PC3:22 PC2
otvoriť tunel a potom v inom terminálovom okne robiť ssh -p 53022 127.3.0.1
. Elegantnejšie riešenie je použiť sshd na PC2 ako proxy
ssh -o 'ProxyCommand /usr/bin/ssh -W PC3:22 user2@PC2' user3@PC3Ak sa jedná o PC "hlbšie" v sieti, napr. PC5, tak je šikovnejšie
ssh -J user2@PC2,user3@PC3 user5@PC5
Stačí, ak ten stroj vidí server a je na ňom ssh. (Príklad: PC5 je domáci serverík niekde za skriňou, domáca sieť nemá verejnú adresu, ale je k dispozícii server (PC1), ktorý verejnú adresu má. Obrázok si predstavíme bez PC2.) Riešením môže byť reverzný ssh tunel, ktorý bude iniciovať PC5.
Príprava: Na PC1 je potrebné zabezpečiť nejaký voľný port, viditeľný z internetu. Na obrázku je to port 54321.
Na PC5 je potrebné zabezpečiť spustenie*
ssh -R '*:54321:localhost:22' user1@PC1a používateľ zo svojho počítača zadá
ssh -p 54321 user5@PC1a je pripojený na ssh na stroji PC5. Hoci spojenie sprostredkúva PC1, použivateľ sa prihlasuje ku účtu na PC5, preto user5!
*) Holé ssh -R samozrejme v praxi stačiť nebude: treba pravidelne spúšťaný skript (crontab), ktorý bude kontrolovať, či je reverzný tunel funkčný a v prípade potreby ho obnoví. SSH kľúč, uložený na PC5, ktorým sa bude skript prihlasovať na PC1 pri vytváraní tunela, musí byť pochopiteľne bez hesla.
Voľby na príkazovom riadku pre pripájanie sa ku niektorým PC môžu zadávanie príkazu slušne skomplikovať. Navyše ich zadávanie sa opakuje. Jednu z ciest, ako si spríjemniť život, ponúka konfiguračný súbor ~/.ssh/config
(/home/user0/.ssh/config
). Kľúčové slovo Host uvádza nastavenia pre konkrétny server (alebo skupinu serverov, ak sa použijú divoké znaky *,?).
Host PC1 Hostname pc1server.example.com Port 22 User user1 Host PC2 Hostname firewall.example.com User user2 Host PC3 Hostname pc3.lan ProxyJump user2@firewall.example.com User user3 Host PC5cezLAN Hostname pc5.lan ProxyJump user2@firewall.example.com,user3@pc3.lan User user5 Host PC5cezPC1 Hostname pc1server.example.com Port 54321 User user5a príkazový riadok potom bude iba
ssh PC3
Súbor ~/.ssh/config
využije nielen samotný ssh klient, ale aj ďalšie programy: scp, rsync a pod. Takže
rsync -az --delete PC3:projekt1/ ~/mirror_projekt1/prenesie stav z /home/user3/projekt1/ na PC3 do /home/user0/mirror_projekt1/
ssh PC5cezPC1 ls -l | grep -E ^- | wc -lspočíta súbory (okrem skrytých) v /home/user5/ na PC5
Tento text pokrýva iba zlomok možností ssh. Viac informácií: man ssh
a man ssh_config
.
Tiskni Sdílej:
…je rozumné spustiť programssh-agent
. Do vhodného skriptu, spúšťaného po prihlásení, napr.~/.profile
treba pridať riadky…
To ale jen pokud nepoužíváte desktopové prostředí, které vám ssh-agent
spustí rovnou a příslušné proměnné zdědí všechno, co spustíte v rámci toho prostředí. Pokud ano, pak bych spíš doporučil podívat se na pam_ssh
pro další zjednodušení.
Mimochodem, ne všude se také dá spolehnout na to, že emulátory terminálu v grafickém desktopu budou spouštět shell jako login shell, aby se načetl ~/.profile
pam_ssh
som zatiaľ nepoužil.
Jediný stroj, kde momentálne používam linuxový desktop, je KUbuntu a ak mi pamäť dobre slúži, aj tam som pridával ssh-agent
do ~/.profile
.
ssh -R
s posloucháním jinde než na localhostu většinou bývá defaultně zakázané, je potřeba nastavit GatewayPorts clientspecified
v konfiguraci SSH serveru.
treba pravidelne spúšťaný skript (crontab), ktorý bude kontrolovať, či je reverzný tunel funkčný a v prípade potreby ho obnovíTohle mi fungovalo tak strašně blbě (například se stane, že jedna strana zůstane viset, to blokuje port na serveru, a nový forward tiše selže; trochu pomůže
ssh -o "ExitOnForwardFailure yes" -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3"
), že všude kde to není úplně adhoc spojení dávám OpenVPN.
GatewayPorts yes
, takže toto som nepotreboval riešiť.
Skript na obsluhu reverzného tunela možno pridám dodatočne, musím ho trochu zovšeobecniť.
-J
jsem nevěděl.
V souvislosti s port forwarding je ještě dobré zmínit -N
(nepouští žádný příkaz, jenom forwarduje porty) a -f
(pustí se na pozadí).
Ještě doplnění ohledně kopírování (pokud nebude v pokračování) - docela osvědčená (oproti rsync) kombinace je:
ssh já@remote 'cd /whatever && tar fcv - --exclude whatever .' | ( cd localdir && tar fxv - )
-C
tar
záleží od okolností. Ak je dát veľa, a potrebujem preniesť iba zmeny, ktorých je zopár, je rsync
neprekonateľný!
Inak pri skriptovaní zložitejších vecí pozor na to, že na strane sshd sa string parsuje ešte raz! Takže
whatever1='projekt1_$platby' ssh já@remote "cd $whatever1 ..."dostane sshd ako
cd projekt1_$platby ...a keďže premenná $platby je (takmer určite) nedefinovaná, výsledkom bude
cd projekt1_ ...Samozrejme konkrétny prípad sa dá konkrétne riešiť, ale ak programátor nemá kontrolu nad tým, aké dáta dostáva na vstupe (ja som sa stretol so súbormi, kde sa v mene bežne objavovali $, ', "), tak je to oriešok. Túto vlastnosť má nielen
ssh
, ale aj scp
a rsync
.
set -u
moc nepomôže, aj keby som ho vedel nejako injektovať do scp alebo do rsync volania.
Scenár: Používatelia nahrávajú súbory do primárneho úložiska. O platných súboroch sa vedie evidencia v SQL databáze. Potrebujem raz za čas balancovať obsadenosť úložísk, tj. preniesť súbory z primárneho na niektoré zo sekundárnych úložísk. U súborov, ktoré sa podarí úspešne skopírovať, musím poznačiť zmenu uloženia do SQL databázy a následne môžem ten súbor z primárneho úložiska zmazať.
Súbory si používatelia nazývajú (takmer) ľubovoľne, v mene jedného súboru môže byť kombinácia znakov $, ', ".
Toto celé sa deje na manažovanom webhostingu, kde si nemôžem nič inštalovať a musím použiť to, čo hosting ponúka.
set -u moc nepomôže, aj keby som ho vedel nejako injektovať do scp alebo do rsync volania.Máš pravdu, přehlédl jsem kde používáš ' a kde " a myslel jsem, že expanze je už na lokálním počítači.
-D
, která nastaví SOCKS proxy.
Kľúč na báze eliptickej krivky 25519 je dnes asi najbezpečnejšia voľba (ale napr. starý CentOS 6 ju nepozná).S tou nejbezpečnější volbou opatrně. Klíč Ed25519* je ekvivalentní 128b symetrické šifry. Jeho hlavní výhoda spočívá v tom, že je malý a že pro generování není potřeba hledat prvočísla (jako u RSA), ale jen náhodná čísla (s tím, že tomu nemá vadit ani cinklý generátor). Takže výhody jsou malé klíče, rychlé generování i použití klíče (tj přihlašování, podepisování). Nevýhodou je pevně daná velikost. Já osobně pro "velké servery" stále jedu RSA-4096. Na druhou stranu pro slabé krabičky je ed25519 výhodný a přihlášení je rychlejší. *) Navíc já osobně mám proti eliptickým křivkám filozofickou výhradu spočívající v tom, že zatímco u RSA je jasně daný algoritmus a všechny parametry si lze vygenerovat u sebe (tj. je nikdo nemůže podstrčit) tak u eliptických křivek (kterých je nekonečně mnoho) je ze samé podstaty nutné vybrat jednu konkrétní a na té potom počítat. A je tady neodstranitelná pochybnost o původu té konkrétní navržené křivky a je úplně jedno, jestli pochází od NSA, NIST nebo Bernsteina.
... najbezpečnejšia voľba ...Ok, mohol som zvoliť vhodnejšiu formuláciu. To, že niekto rozhodol, že práve krivka 25519 je "tá správna", mne osobne problém nerobí - celý svet okolo nás je taký zložitý, že bez dôvery by sme nemohli fungovať. RSA je určite skvelé v tom, ako dlho problém faktorizácie odoláva úsiliu o matematické riešenie. Zatiaľ sa zdá, že vydrží až do času, kedy mu zlomí väz kvantové počítanie. Výpočty na eliptických krivkách, problém diskrétneho logaritmu, vnímam ja (nie-matematik) ako "modernejšiu" matematiku, možno aj preto ten príklon ku ed25519. Kvantové počítanie (taktiež Shorov algoritmus ako pri faktorizácii) údajne rozbije aj túto skupinu šifier, takže z tohto pohľadu ed25519 výhoda nie je.