Portál AbcLinuxu, 30. dubna 2025 21:21
host pc120 hostname xxx.xxx.xxx.xxx user "moje jmeno" ForwardX11 yes host pc121 ... atddalším krokem bylo vytvoření souboru, který by mi zprostředkoval různé varianty ssh služeb :
#! /bin/bash
programname=`basename $0`
mntdir="/home/moje_jmeno/mnt/provo"
if [ -n "$1" ]; then
provo="$1"
else
echo "Použití : $0 cisloprovozovny"
exit 1
fi
testdir() {
prov=$1
if [ -d "$mntdir/$prov" ]; then
echo " Adresář pro připojení provozovny $prov již existuje"
if mount | grep "$mntdir/$prov"; then
echo "Adresář je již používán"
return 1
else.
return 0
fi
else.
echo "Vytvářím adresář ..."
mkdir -p "$mntdir/$prov"
echo "Úspěšnost : $? "
fi
}
provoname="pc$provo"
case $programname in.
sshx2)
echo "připojuji se na displej 2 provozovny $provo"
vncviewer -bgr233 -encodings zlib -compresslevel 4 -via $provoname localhost:2
;;
......
sshx1)
echo "připojuji se na displej 1 provozovny $provo"
vncviewer -bgr233 -encodings zlib -compresslevel 4 -via $provoname localhost:1
;;
.......
sshx0)
echo "připojuji se na displej 0 provozovny $provo"
vncviewer -bgr233 -encodings zlib -compresslevel 4 -via $provoname localhost:0
;;
......
sshf)
echo "Připojuji filesystém provozovny $provo "
testdir $provo && sshfs moje_jmeno@$provoname:/ $mntdir/$provo/
;;
sshuf)
echo "Odpojuji filesystém provozovny $provo "
mount | grep $mntdir/$provo && fusermount -u $mntdir/$provo.
;;..
*)
echo "neznámý příkaz $programname"
;;
esac
Tento soubor dostal jméno sshx0 a "bratříčky" - odkazy se jmény sshx1, sshx2, sshf, sshuf.
Jak se to chová, je myslím zřejmé z výpisu, žádná kouzla. S řešením toho připojení na x-ka mé nakopli právě tady..
Dále se vyskytl zajímavý problém - zjistit existenci / neexistenci určitého souboru na vzdáleném systému. Do adresáře jsem se jako obyčejný uživatel nedostal, čili přes sudo ..
na to jsem si vytvořil skript, který jsem volal s číslem provozovny jako parametr (taky docela fuška zprovoznit) :
#! /bin/bash # v tom "./ansi" je příkaz cecho, který umí obarvovat text-jen taková frajeřinka :) if [ -f ./ansi ]; then . ./ansi fi if [ -z "$1" ]; then cecho "nebyla zadaná provozovna !!!" "red" exit 1 fi provo="$1" shost="pc$1" echo -n "Test pripojení k $1 ...." # test připojení serr=$((( ssh "$shost" echo "Přípojen !!") 1>/dev/null) 2>&1) if [ "$?" -lt 1 ] ; then cecho " OK " "green" echo "Přebírám administrátorké oprávnění .." echo rotovoheslo | ssh $shost sudo -S -v >> /dev/null. else cecho "BAD " red echo $serr exit 1 fi $spf="/nejaky_soubor" if [ `ssh "$shost" sudo test -f $spf && echo 1 ` ]; then cecho "soubor nalezen " red else. cecho "soubor nenalezen" green fi # tohle jsem ořezal, příkazy cecho jistě nahradíte (pokud snad návodu zde uvedeného využijete ) svými příkazyNo, závěrem doufám, že méně než 90% zdejších návštěvníků nemávne nad zápiskem rukou "pche, to jsme brali v první třídě ZDŠ.." ale že alespoň někomu přinese úžitek Pokud se někomu bude chtít v tom patlat, a najde nějaký způsob vylepšení, rád se přiučím..
Tiskni
Sdílej:
11.1.2011 15:07
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Pak je ještě možnost omezit ssh na spojení přes VPN.To bych se bál, že umře VPN a co pak s tím. SSH démon se mi zdá přecijen robustnější než SSH + VPN.
SSH přes OpenVPN má smysl jen tehdy, když je onen stroj, ke kterému se přistupuje, za NATem, nad kterým není kontrola (tj. není možné přesměrovaty port) a/nebo onen stroj dostává adresu dynamicky přes DHCP.To už radši SSH tunel nebo Teredo tunel, v případě měnící se adresy pak skript v cronu, který bude po každé změně adresu někam práskat (buď někam na HTTP nebo nejlépe dyndns).
Kromě robotů to většinou znamená i konečnou pro scriptkiddies
Sice mi není moc jasné, jaký je podle vás rozdíl mezi "roboty" a "script kiddies" (podle mne je robot ten skript a kiddie ten, kdo ho spustil, takže ve výsledku prašť jak uhoď), ale spíš by mne zajímalo, o jakou "konečnou" se podle vás jedná. To, aby se vám nedostali na počítač - a to je IMHO to podstatné - pomocí obskurního portu nezajistíte a naopak, použijete-li správné prostředky, abyste to zajistil, mají "konečnou" i na defaultním portu.
Vzpomínám si, jak mi takhle během pár dní narostl log na 3GB
Máte-li problém se zbytečnými zápisy do logu, pak řešte ten problém, tj. zbytečné zápisy do logu.
11.1.2011 12:12
11.1.2011 15:11
11.1.2011 16:07
sshd na obskurní port).
Ono se těch hlášek nezbavíš, protože jsou stejné jako ty od skutečných útoků.Bavíme se o hlášce oznamující odmítnutí přihlášení kvůli špatnému heslu?
12.1.2011 21:31
PermitRootLogin WithoutPassword (ano, ten název je děsivý :))
a-zA-Z0-9, nebo ještě lépe zakázání přihlašování heslem a používání 4Kib RSA klíčů.
eliminuješ tím přihlášení na jediný 100% jistý účet na tom daném stroji.Není to z hlediska bezpečnosti ekvivalentní připlácnutí mého běžného loginu do rootovského hesla a ponechání možnosti přihlásit roota zvenčí? Zákaz přihlášení heslem mi přijde daleko užitečnější.
11.1.2011 15:50
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
11.1.2011 17:19
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Kdyz uz, tak pristup pres sudo s vlastnim heslem. A pristup pres klic bych klidne dovolil - oba dva pristupy pak lze jednoduse spravovat pro ruzne uzivatele.
A root heslo nedavat nikomu uz jenom z toho duvodu, ze nekdo pak napise takovou prasarnu jako 
16.1.2011 23:06
12.1.2011 19:00
echo rotovoheslo | ssh $shost sudo -S -v. Vlastni heslo nepisu NIKAM, Windows heslo mam v /etc/auth/domain.ad pro autofs na windows shares a je jenom pro cteni rootovi. SSH klic a GPG klic mam s heslem na disku.
No jinak OK, akorat casem se to treba naucis zpameti a pak uz tohle potrebovat nebudes:)
sshx0 154nebo ne ? Nebo si mountnout vzdálený filesystém
sshf 154A samozřejmě - při použití ssh-agenta.
, ktere budou fungovat jen "u vas" nebo radeji memorovat oblibene kombinace std. prikazu, ktere pak muzete v klidu pouzivat vsude.
ssh root@server 'command'je lepší udělat
ssh vyhrazeny_uzivatel@server 'sudo command'a nastavit sudo tak, aby se neptalo na heslo a povolilo jen ten jeden konkretni command. Pak ani zveřejnění toho scriptu i s klíčem neznamená předání roota (ale záleží na tom, co ten command dělá). Jako další vylepšení by mohlo být nastavení toho celého command i se sudem jako login shell, aby ten vyhrazeny_uzivatel nemohl spustit nic jiného (ono vůbec je vlastní script místo loginshellu supr věc).
… je lepší udělatssh vyhrazeny_uzivatel@server 'sudo command'a nastavit sudo tak, aby se neptalo na heslo a povolilo jen ten jeden konkretni command.
V čem je to lepší než když rovnou pro ten klíč povolím jen příslušný příkaz? Mně to připadá jen komplikovanější.
Spíš než ssh root@server 'command' je lepší udělat ssh vyhrazeny_uzivatel@server 'sudo command'Nebo využít prostředky SSH a udělat to samé bez sudo.
Pěkné. Jen bych se opravdu vyhnul tomu psaní root hesla do nějakého souboru.Doporučuju klíč :).
Podle všech bezpečnostních pouček to vede k tomu, že účet daného uživatele je pak ekvivaletní s rootem.Což nemusí být za všech okolností špatně.
Pak je možnost udělat místo sudo něco jako ssh root@127.0.0.1 'command '.Nenapadá mě nic, v čem by to mělo být lepší než sudo.
Jediná věc, co tomu bránila k dosažení dokonalosti (alespoň tak cca rok zpátky, co jsem to zjišťoval) byla, že OpenSSH neumělo omezit nějaký rootovský klíč na použití z localhostu.Zajímavé, já to zjišťoval myslím v podobné době a OpenSSH to umělo. Podle nějakého namátkou vybraného howto to umělo nejspíš už v roce 2006 nebo dříve.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.