Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
Evropská komise (EK) nařídila americké společnosti Meta, že musí znovu umožnit bezplatný přístup konkurenčním obecně zaměřeným asistentům umělé inteligence (AI) k WhatsAppu a tento přístup musí zachovat až do ukončení antimonopolního šetření. Opatření je dočasné a má zabránit vážnému a nevratnému poškození konkurence na rychle rostoucím trhu s obecnými AI asistenty. Meta uvedla, že se proti rozhodnutí odvolá.
Společnost Anthropic představila AI modely Claude Fable 5 a Claude Mythos 5. Claude Fable 5 je první model třídy Mythos určený pro běžné použití.
Byla vydána nová stabilní verze 3.24.0, tj. první z nové řady 3.24, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Přehled novinek v poznámkách k vydání.
Na čem pracují vývojáři v Rustu napsaného mikrokernelového unixového operačního systému Redox OS (Wikipedie)? Byl publikován přehled vývoje za květen. Vypíchnout lze nový scheduler EEVDF nebo port desktopového prostředí Xfce na Redox OS.
Upozornění pro uživatele Asahi Linuxu: Neaktualizujte macOS na verzi 27 Golden Gate! Apple změnil detekci spouštěcích oddílů. Po aktualizaci oddíl s Asahi Linuxem nevidí. Snad je to jenom chyba.
Na webu konference Den IPv6, která se konala 4. června v Národní technické knihovně v pražských Dejvicích, jsou nyní k dispozici všechny prezentace (v PDF) a jejich videozáznamy. Organizátory konference byly i letos sdružení CESNET, CZ.NIC a NIX.CZ.
Ďakujem za komentáre a podnety ku minulému článku. Týmto ho skúsim ešte trochu doplniť.
Príkaz
ssh -D 12345 PC2
otvorí šifrované spojenie z PC0:12345 na PC2 a sshd na PC2 bude plniť úlohu SOCKS proxy. Ľubovoľná aplikácia na PC0 (alebo v sieti PC0, ak je port 12345 otvorený do siete), ktorá dokáže používať SOCKS proxy, získa prístup ku prostriedkom, ako keby bežala priamo na PC2.
Díky @jiwopene za tip!
ProxyCommand /bin/ncat --proxy-type socks5 --proxy socks_server:socks_port PC2 ssh_port2
prípadne, ak socks_server sprístupňuje viaceré stroje/viaceré porty, dá sa napísať univerzálne
ProxyCommand /bin/ncat --proxy-type socks5 --proxy socks_server:socks_port %h %p
(viď. TOKENS v man ssh_config).
Netcat binárka sa môže v niektorých distribúciách volať aj /bin/nc, treba pozrieť svoj systém.
ssh umožňuje zdieľať jeden tunel nielen pre viacero použití v rámci jedného príkazu (ako napr. viacero -L), ale aj v čase, pre viacero klientov. Toto zdieľanie môže riadiť programátor v skripte, alebo môže byť nastavené ako automatické.
Príklad, ako zapnúť automatické zdieľanie spojení v ~/.ssh/config:
Host *
ControlMaster auto
ControlPath ~/.ssh/control_%r@%h_%p
ControlPersist 1m
Príkazy, ako napr.
#!/bin/bash
scp skript{1,2}.sh PC2:./
ssh PC2 ./skript1.sh
ssh PC2 ./skript2.sh
sa potom všetky udejú v rámci jedného ssh spojenia.
Poznámka: Zdieľanie spojenia nefunguje v rámci Cygwin-u a z nejakých dôvodov sa mne nedalo kombinovať s X11 forwardingom. Keďže s X11 forwardingom som robil len pokusy a reálne som ho nepotreboval, hlbšiu príčinu som nezisťoval.
Skript beží na PC5, je spúšťaný pravidelne cez crontab a udržiava "živý" reverzný tunel, ktorý vyúsťuje na PC1. Ku prihlasovaniu na PC1 sa používa ssh kľúč bez hesla. Verejnú časť kľúča je nutné nahrať nielen do /home/user1/.ssh/authorized_keys na PC1 ale aj do /home/user5/.ssh/authorized_keys na PC5, kvôli overovaniu funkčnosti tunela. Voľba StrictHostKeyChecking accept-new uľahčuje prvé spustenie. Voľby ServerAlive... boli pridané vďaka námetu od @Jenda, díky!
Skript funguje vďaka mechanizmu zdieľania spojenia, tentokrát nie v automatickom režime, ako v minulej kapitole, ale "manuálne" riadenému: -M štartuje nový master, -O posiela riadiace príkazy masteru cez socket -S.
Spustenie skriptu s parametrom stop ukončí tunel a súčasne pozastaví proces jeho obnovovania (netreba editovať crontab). Parameter start tunel zase obnoví, rovnako, ako reštart PC5 (pri reštarte sa obvykle zmaže /tmp/.)
Poznámka: Riešenie s reverzným tunelom nesie zo sebou istú nepríjemnosť v podobe otravných pokusov o neautorizované pripojenie. PC1 o výsledku pripojovania klienta nič nevie, iba posiela nejaké dáta do tunela, takže nemôže takéto pokusy blokovať. Z pohľadu PC5 prichádzajú všetky spojenia z localhost-u, takže vie, ktoré prípady by sa mali blokovať, ale nevidí adresu. Jednoduché riešenie formou povedzme fail2ban sa nedá nasadiť. Ak máte niekto nápad, ako sa neautorizovaných pokusov zbaviť, podeľte sa, prosím, v diskusii. Vysoké číslo portu (54321) dnes už nepomáha. Ja som skeptický.
#!/bin/bash
MyPort=54321
TheServer='PC1'
TheServerSshPort=22
TheServerLogin='user1'
LocalSshPort=22
ControlPath="$HOME/.ssh/server_tunnel_control"
BlockPath='/tmp/server_tunnel_block'
Identity="$HOME/tunel_test/id_rsa_port_forward"
# Kluc musi byt ako v $Identity, tak aj v ~/.ssh/authorized_keys a to kvoli kontrole funkcnosti spojenia (function is_tunnel_working)!
self="$(readlink -mn "$0")"
function start_connection()
{
ssh -M -S "$ControlPath" -fnN -g -2 -4 \
-o 'StrictHostKeyChecking accept-new' \
-o 'ControlPersist yes' \
-o 'ExitOnForwardFailure yes' -o 'ServerAliveInterval 30' -o 'ServerAliveCountMax 3' \
-R "*:$MyPort:localhost:$LocalSshPort" \
-i "$Identity" \
-p "$TheServerSshPort" "$TheServerLogin"@"$TheServer" \
&& rm -f "$BlockPath"
}
function control()
{
cmd=$1
ssh -S "$ControlPath" \
-O "$cmd" \
-i "$Identity" \
-p "$TheServerSshPort" "$TheServerLogin"@"$TheServer"
}
function stop_connection()
{
touch "$BlockPath"
control exit >/dev/null
}
function ping_server()
{
ping -c 2 "$TheServer" >/dev/null
}
function is_tunnel_working()
{
# Tunel sa povazuje za funkcny, ak cez neho skript vidi sam seba.
ssh -o 'StrictHostKeyChecking accept-new' \
-i "$Identity" -p "$MyPort" "$USER"@"$TheServer" \
/bin/ls "$(dirname "$self")" \
| grep -cxF "$(basename "$self")"
}
###============================================================================
case "$1" in
"start") ## iba pre pripad startu po zablokovani
start_connection
E=$?
logger --stderr -t "[THESERVER_SSH]" "Port forwarding start ($E)"
;;
"stop") ## zablokovanie forwardu, aby ho cron neobnovoval
stop_connection
E=$?
logger --stderr -t "[THESERVER_SSH]" "Port forwarding stop ($E)"
;;
"restart")
stop_connection && start_connection
E=$?
logger --stderr -t "[THESERVER_SSH]" "Port forwarding restart ($E)"
;;
*) ## default - ak nie je zablokovany, forward ma fungovat
[ -f $BlockPath ] && exit 0
if ! ping_server ; then
>&2 echo "Cannot ping $TheServer. Internet off?"
exit 1
fi
if [ ! -e "$ControlPath" ] ; then
"$self" start
exit $?
fi
T="$(mktemp)"
control check >"$T" 2>&1
E=$?
if [ "$E" -ne 0 ] ; then
logger --stderr -t "[THESERVER_SSH]" "($E) $(cat "$T")"
rm "$T"
if [ "$E" -ne 255 ] ; then
"$self" start
exit $?
fi
else
rm "$T"
fi
# funguje naozaj?
C="$(is_tunnel_working)"
if [ -z "$C" -o "$C" -eq 0 ] ; then
"$self" restart
E=$?
else
E=0
fi
;;
esac
exit $E
Tiskni
Sdílej:
ssh -N -D3081 user@machine -p 22Nebo aby byl proxy dostupny z jakehokoli PC v lokalni siti:
ssh -N -D192.168.1.100:3081 user@machine -p 22Pro pouziti proxy treba k webovemu prohlizeci Chromium:
chromium --incognito --proxy-server="socks5://192.168.1.100:3081"