Dotaz: SSH + denyhosts co děláte více ? Jestli vůbec ...

[alanos]

Z výpisu z /var/log/auth.log se dovídám tak o cca 2 až 4 pokusech z různých IP adres /většina z východní asie/ přihlášení přes SSH ./etc/hosts.deny je přes 500 zablokovaných IP adres ... Tak si pokládám otázku jestli mám dělat ještě nějaké další kroky k ochraně serveru. Děkuji za případné reakce.

---

---

Odpovědi

[Filip Jirsák]

Pokud můžete, nastavte přihlašování klíčem a zakažte přihlašování heslem. Pak můžete seznam blokovaných adres klidně vyprázdnit.

[chutracek]

Mam ssh hozeny na nestandardni port, coz vyfiltruje drtivou vetsinu pokusu o prihlasovani. Podle dulezitosti stroje pak pouzivam knockd. A jak zminoval kolega, zakazat prihlasovani heslem a pouzivat pouze klice.

[jirkamailto]

Ja pouzivam fail2ban, ktery po nekolika (definujes si) neuspesnych prihlasenich zablokuje IP adresu proti pristupu k SSH na cas (ktery si definujes). Po tento cas se zkratka nemuze dany stroj na Tvuj server pristupovat. Da se take nastavit, ze po kazdem zablokovani Ti prijde mail, ve kterem se objevi vypis. Treba si muzes nastavit, aby Ti to poslalo vypis ze whoisu dane IP adresy. Je to pekna vec, pouzivam uz dlouho a nemuzu si stezovat. Srkipt prida pravidlo do IPTABLES, takze pozor, kdyz manualne refreshnes IPTABLES tabulku, tak je nutne zrestartovat i skript, aby znovu pravidlo do tabulky zapsal. Skript by mel nbyt jako balik soucasti vetsiny distribuci. pro debian staci dat apt-get install fail2ban

[Filip Jirsák]

Nechápu, k čemu je takový skript dobrý. Před ničím vás neochrání, akorát hrozí, že zablokuje vás.

[SPM]

Ušetří pár MB místa v logách a kus systémové zátěže - když se ssh nemusí obtěžovat odpovídat na celý slovník...

[Filip Jirsák]

Pokud bych chtěl šetřit místo v logách, šetřil bych místo v logách a ne zakazoval komunikaci na firewallu. Otázka je, zda zátěž generovaná tou spoustou pravidel v iptables pak není větší, než jednoduché uzavření spojení.

[SPM]

Konkrétně u SSH bych řekl, že bude daleko méně nákladné se u paketu podívat na IP hlavičku a paket rovnou zahodit, než otevřít spojení, vygenerovat klíče, vyměnit klíče, poslat ho někam a zavřít (pokud to jsou 4 spojení, tak je to celkem směšné, ale když jsem nechal server poslouchat na výchozím portu, tak tam každých pár minut nějaký chytrolín sypal celej slovník jmen...)

[VM]

Fail2ban je šikovná věcička - po několika neúspěšných pokusech (defaultně tuším 3-5) zabanuje na hodinu danou IP adresu. Roboty co dělají slovníkové útoky to odradí, šetří místo v logu a snižuje šanci, že uhodnou heslo. Legitimní uživatelé většinou používají SSH klíče, do 3-5ti pokusů si na heslo vzpomenou, a i když ne, tak v nejhorším mohou pokračovat o hodinu později (lze nastavit i kratší dobu).

[Filip Jirsák]

To bude důvod, proč ho nepoužívám – šetřit místo v logu konfigurací firewallu mi připadá jako hloupý žert, a šance, že někdo uhodne heslo, je nulová, takže snižovat ji nejde.

[SPM]

Ta šance nikdy nulová neni, leda by se tim heslem nešlo přihlásit :)

[Filip Jirsák]

No vždyť ano.

[SPM]

Naproti tomu si stačí klíč vygenerovat na nějakém kvalitním distru typu debian a už bych se o to pouštění do světa taky bál :))

[Filip Jirsák]

Hlavně aby někoho nenapadlo, že si pro jistotu klíč vygeneruje na více různých distribucích, a pak je porovná, jestli jsou stejné

[Bilbo]

Na tohle používám denyhosts, akorát ten limit jsem zvednul (5 pokusů je ještě ok, ale 1000 už je moc) Denyhosts nemodifikuje pravidla v iptables, ale /etc/hosts.deny což má ale za následek to samé - dotyčný se k dalšímu zkoušení SSH nedostane.

Jinak až na pár vyjímek pro pár uživatelů mám taky přihlašování jen pomocí klíče, což šance robotů dostat se dovnitř dosti snižuje.

[NN]

Pouzivat VPN.

NN

[alanos]

Tak jsem nastavil přihlašování jen klíčem ssh , VPN tam mám taky vše jede , jen jsem občas někdy prostě potřeboval připojit se z kompu kde jsem neměl klíče ... tak jsem tam měl přihlášení i přes heslo .. zatím to budu sledovat co se děje .. uvidíme :o)

[GGG]

Já v tom případě používám OTP. Kalkulačku spustím na každém mobilu ( třeba jotp ).

[pht]

IMO schemata typu auto blokování jsou zcestná. Doporučené kroky obvykle jsou

1) Používat systém veřejných klíčů místo hesel

2) Mít sshd na jiném portu než 22

3) Omezit firewallem IP adresy klientů pro sshd

4) Používat IDS/nezávislý monitoring pro kontrolu zdraví serveru

... podle potřeby kombinovat.

[x00]

Imho tvoje obscurity je zcestne. 1) kokovina 2) kokovina^2 3) firewallom lol 4) urcite nainstaluj si dalsiu kokovinu ktora je programatorovym MyFirstProjektInC++

Security - custom kernel custom kernel hardening hardening restriksny restriksny a hlavne vyhadzat z kernelu vsetky nepotrebne sracky ako LSM,rozne emulacne vrstvy ako ia32 a podobne

[methuz]

No, z fleku bych Vas doporucil na misto v nasem Security teamu, kolego.

[pht]

Asi tak, nebo o tom může vést přednášky místo nás...

[Filip Jirsák]

Záleží ovšem na tom, kdo to doporučuje. Já bych třeba bod 1 zařadil mezi doporučené, body 2 a 3 mezi dost nedoporučené a krok 4 jako zbytečný (resp. za nesmírně náročný pokud by měl k něčemu být).

[Šangala]

Jak píšete, já bych zas bod 2 vyřadil a bod 3 nedoporučil.
Protože nikdy nevím odkud se budu hlásit, a znám místa kde je povolen ven je 21,22,80,443.
A s bodem jedna je to taky někdy na štíru, pokud se hlásím nejen odkudkoliv a ale i čímkoliv a nemusím mít certikát u sebe (takže potřebuji aspoň jeden speciální účet, který má povoleno i přihlášení přes heslo).
A pak už zbude blokování IP adres na firewall-u (používám svůj script), jen je potřeba aby byly k dispozici různé servery na veřejných IP, které se nemohou vzájemně blokovat. Pak i když Vás (naprosto a jen pouze teoreticky) někdo zablokuje, bo s Vámi sdílí IP, tak se dočasně odblokujete.
Dělám to na několika veřejných IP a vetšinou se tam blokuje tak do 10 adres současně - max 30 (automaty to celkem brzo pochopí), což server nijak nezatíží (neblokuji jen 22 ale i například 443 a 21).

[pht]

Ten firewall není myšlen tak, že se sám otvírá a zavírá, ale že tam je nastavena pevná sada adres odkud je povoleno se přihlásit. Samozřejmě omezení přístupu má za následek to, že omezuje přístup Když se chcete kdykoliv jakkoliv a odkudkoliv přihlásit, tak si to tak nastavit můžete, ale pak se může kdykoliv jakkoliv a odkudkoliv přihlásit také někdo jiný.

[Filip Jirsák]

Pokud se hodlám přihlašovat z jakéhokoli zařízení, které někde potkám, nemusím bezpečnost řešit skoro vůbec a můžu přístupové údaje rovnou veřejně vyhlásit. Dávám přednost přihlašování z několika málo zařízení, která mám pod kontrolou – a není problém si vybrat taková, kde je možné klíč použít. Stačí mít to na svém počítači, notebooku a mobilu, a ostatní počítače v síti nakonfigurované tak, aby se tam dal použít klíč uložený na nějakém tokenu nebo flash disku. Přihlašovat se z nějaké internetové kavárny opravdu nepovažuju za dobrý nápad – to použiju radši notebook a wifi nebo přinejhorším mobil.

[Šangala]

To nemusí být zařízení, které někde potkám, ale je to limitováno tím, kde třeba zrovna jsem a nemám dovoleno se přihlásit ze svým NTB do sítě, a nebo jsem někde ve známém prostředí bez ntb, nebo třeba u kamaráda a nenosím certifikát jako součást klíčků od domu.
Internetová kavárna není dobrý nápad, ale je spousta míst kde to je dobrý nápad.

[Filip Jirsák]

To pak záleží na tom, kdo je na co zvyklý. Já mám třeba u sebe certifikát skoro pořád, takže kombinace důvěryhodného prostředí s přístupem na internet a nepřítomnost certifikátu u mne nastává možná pár hodin v roce. A v takovém případě u sebe nejspíš nebudu mít ani správce hesel, 20znaková hesla k různým rootovským účtům si opravdu nepamatuju.

[Šangala]

No to jde , obvykle to řeším z ntb, kde vlastně ani neřeším kde jsem co dělám - stačí 3 hesla (k disku, k přihlášení a k certifikátu) a dostanu se všude. Ale někdy jsem rád, že mám aspoň platební kartu .
A zapamatovat si několik hesel nemám problém (pamatuji si jich mnohem víc, než potřebuji a mám i trochu delší než uvádíte), ale v zásadě mi stačí 2 abych se probil ke klíčence, případně 3 pokud bych měl přímou cestu zablokovanou.
A prostě už se mi to několikrát osvědčilo mít přístup „jen“ heslem.
Stejně tak se mi osvědčilo blokování IP:PORT na krátkou a postupně se zvyšující dobu. Je pravdou, že se SSH/Aplikace přes HTTPS/FTP nepoužívají nijak masivně (na mnou spravovaných serverech), ale zatím nevím o jediném případu, kdy by to někoho odřízlo, bo je na stejné IP se zlým počítačem.

[pht]

Klíče nejsou samospásné, a 2 & 3 jsou (zbytečně) předmětem vášnivých debat. Ale zajímalo by mě proč je monitorování zbytečné? Když nemáte oči tak nic nevidíte.

[Filip Jirsák]

Monitorování by nebylo zbytečné, kdyby skutečně dokázalo průniky spolehlivě detekovat.Monitorovat systém zevnitř jeho samého má jen omezené možnosti použití, a monitorovat ho z venku není nic snadného.

Něco jiného je monitorování dostupnosti poskytovaných služeb (třeba web serveru) z úplně jiné lokality – ale to nepovažuju primárně za bezpečnostní opatření.

[pht]

No zrovna u toho ssh to není tak těžké, můžete si nechat třeba pro začátek nechat posílat audit.log ohledně úspěšných spojení a jednou denně ho číst. Což tak nějak je používaná praktika.

A ohledně monitorování zvenčí, IDS softwarů je docela dost a myslím si že pokud mám nějakou síť opravdu zabezpečit, tak je lepší investovat trochu vůle a času do ochočení nějakého, byť blbého, IDS, než pozorovat ... co? LEDku harddisku jestli nesvítí moc často?

[Filip Jirsák]

No zrovna u toho ssh to není tak těžké, můžete si nechat třeba pro začátek nechat posílat audit.log ohledně úspěšných spojení a jednou denně ho číst. Což tak nějak je používaná praktika.

Myslíte, že když se někdo na server dostane, bude čekat, až se mi pošle neupravený log spojení? A že „ruční“ pročítání takového logu bude spolehlivé?

A ohledně monitorování zvenčí, IDS softwarů je docela dost a myslím si že pokud mám nějakou síť opravdu zabezpečit, tak je lepší investovat trochu vůle a času do ochočení nějakého, byť blbého, IDS, než pozorovat ... co?

A co budu pozorovat s tím IDS? Že se ten napadený počítač chová z venku pořád stejně?

Obě zmíněná opatření by asi odhalila nějaké script-kiddies, ale proti těm je dostatečnou ochranou aktualizovaný software a používání bezpečných způsobů přihlášení (nejlépe klíče, nebo alespoň silná hesla).

[pht]

Myslíte, že když se někdo na server dostane, bude čekat, až se mi pošle neupravený log spojení? A že „ruční“ pročítání takového logu bude spolehlivé?

Já jsem kdysi míval normální syslog forwarding a to celkem spolehlivé bylo. Ta hláška se odešle souběžně, ne-li dřív, než se přihlásí, a když si to necháte jednou denně vyjet a přečtete si to, tak máte aspoň omezenou dobu, do kdy na to přijdete. Pravděpodobně na to lze nasadit nějaký automatický analyzátor, ale to mi na první iteraci přijde zbytečně složité.

A co budu pozorovat s tím IDS? Že se ten napadený počítač chová z venku pořád stejně?

Spoustu věcí. Že se na počítač spojuje kdosi odkudsi jinud než normálně, že se počítač začne chovat jinak - např. napadat ostatní počítače.

Samozřejmě se lze před tím skrýt, ale je to další úsilí, které musí útočník vyvinout, když nemáte IDS, tak nebude muset vyvinout nic.

[Jiří Lisický]

Já na jednom serveru používám modul iptables, který se jmenuje recent. Oproti scriptům jako je fail2ban se mi na něm líbí, že neprohledává logy což je nákladné (a navíc se to děje až zpětně) a že není třeba nic přiinstalovávat, jen napsat pravidla do firewallu.

Funguje to tak, že si počítá počet připojení za jednotku času a pokud je ten počet překročen zdrojovou adresu zablokuje.

Je to standardní modul do iptables, takže si pravidla můžete napsat jak potřebujete. Včetně toho, že zdrojové IP ze kterých obvykle přistupujete nemusíte počítat vůbec.

[Filip Jirsák]

Funguje to tak, že si počítá počet připojení za jednotku času a pokud je ten počet překročen zdrojovou adresu zablokuje.

To pak musí být zábava, když na nějakém počítači, který není na whitelistu, pustíte třeba tohle:

for f in * do
 scp $f user@remote:/nejaka/cesta
done

Zrovna v tomhle případě to jde udělat lépe, ale někdy něco takového může být nejjednodušší řešení.

[R]

Tiez mam na jednom mieste riesenie s recent a nikdy som s tym problem nemal. Lebo viem, ze nebudem pouzivat take blbosti, ako x-krat scp za sebou. fail2ban som hned zavrhol - prehladavanie logov a este aj v pythone, vsak to je z principu totalny nezmysel...

[alkoholik]

Takhle kopiruje jenom idiot.
Mezery v nazvech souboru jsou pro bash for specialitka. Nehlede na naprosto zbytecne pousteni mnoha ssh.

[Filip Jirsák]

Jak tedy okopírujete soubory, jejichž seznam máte v souboru, nebo které potřebujete vyhledat pomocí find (nestačí na to hězdičková expanze scp), a je jich tolik, že se nevejdou všechny jako parametry příkazové řádky?

[alkoholik]

Jezis to jsou zase bludy. Jaka hvezdickova expanze scp?
"Expanzi" dela bash a jestli je seznam dlouhy, tak scp * rozhodne fungovat nebude. Presne tenhle problem se resi pres xargs.
Kdyz potrebuje neco jineho nez *, tak samozrejme find .. -exec vcetne spravnych uvozovek.
Seznam ze souboru musite cist pres while read LINE; do scp "$LINE" host:/dir/ ; done < file_list

[Filip Jirsák]

Jaka hvezdickova expanze scp?

Normální hvězdičková expanze scp. Když dáte cestu s hvězdičkou do uvozovek, shell neprovede expanzi a předá hvězdičku scp. Hvězdičku pak expanduje až scp. Díky tomu můžete hvězdičku použít i ve vzdálené cestě (shell by vám ji expandoval podle místních souborů nebo vůbec – podle toho, jak by si poradil s tou divnou cestou). Nebo-li

scp -r user@remote:/home/user/* ./

vám nejspíš neprojde a shell vám vynadá, že nezná cestu user@remote:/home/user/ a nemůže expandovat hvězdičku. Nebo to pochopí jako lokální cestu /home/user a ze vzdáleného serveru tak okopírujete soubory a adresáře s takovými jmény, jaké máte v lokálním adresáři /home/user. Což jste asi nechtěl.

scp -r "user@remote:/home/user/*" ./

udělá to, co očekáváte, totiž okopíruje všechny viditelné soubory a adresáře ze vzdáleného adresáře /home/user.

jestli je seznam dlouhy, tak scp * rozhodne fungovat nebude

To jsem psal.

Presne tenhle problem se resi pres xargs.

Který se interně chová tak, že seznam argumentů rozdělí na několik kratších a zavolá příkaz (tady scp) opakovaně – čímž se aktivuje zmíněná ochrana a daná IP adresa se zablokuje.

Kdyz potrebuje neco jineho nez *, tak samozrejme find .. -exec vcetne spravnych uvozovek.

Tím se scp spustí pro každý soubor zvlášť, tedy opakovaně, a opět zafunguje zmíněná ochrana a blokace.

Seznam ze souboru musite cist pres while read LINE; do scp "$LINE" host:/dir/ ; done < file_list

A do třetice opakované spuštění scp následované aktivací ochrany a blokací IP adresy.

[alkoholik]

Ja kritizoval tu vasi silenou konstrukci for f in *.

[Filip Jirsák]

Podstatné ovšem bylo, že může být dobrý důvod scp pouštět opakovaně. Způsobů provedení si můžete vymyslet milion – já jsem zvolil schválně takový, ze kterého bude na první pohled vidět, o co jde.

[alkoholik]

A k vasi hvezdicce: scp ji vazne nikdy neexpanduje. Jenom ji preda bashi na druhe strane.
Navic jste ji v prikladu mel u zdroje.
Jinak ja scp pouzivam na jeden dva soubory. Jak podotknul kolega, uz vymysleli tar.

[Filip Jirsák]

A k vasi hvezdicce: scp ji vazne nikdy neexpanduje. Jenom ji preda bashi na druhe strane.

Když se chcete nimrat v nepodstatných detailech (podstatné je, že hvězdičku nezpracuje shell, ale že ji dostane program na příkazovém řádku), dělejte to důsledně. SFTP bude zcela jistě fungovat i bez bashe na serveru.

Navic jste ji v prikladu mel u zdroje.

Já jsem v příkladu hvězdičku v příkazu scp vůbec nepoužil. Navíc u scp může být hvězdička vždy jen u zdroje, protože cíl je jen jeden argument. Podstatné je ale to, zda je to lokální cesta (které rozumí i shell), nebo vzdálená cesta (které ne každý shell rozumí).

Jak podotknul kolega, uz vymysleli tar.

Jenže scp umí kopírovat jen soubory, takže bych ty zdrojové soubory musel spojit do jednoho souboru, k čemuž nemusí být místo ani příležitost (třeba read-only médium). Samozřejmě existuje spousta různých způsobů, jak soubory okopírovat úplně jinak – ale proč, když existuje jednoduché a snadno použitelné scp?

[alkoholik]

Expanzi hvezdicky vzdy provadi bash. At uz lokalni nebo vzdaleny. Scp samo o sobe nic takoveho neumi.
Neplette dohromady SCP a SFTP. To je jina vesnice.
Co ma spolecneho read-only medium a tar? Nikdy jste nevidel konstrukci tar -cf - soubor1 soubor2 .. souborN | ssh user@remote tar -xf - -C /remote/dir?

[Filip Jirsák]

Expanzi hvezdicky vzdy provadi bash.

Asi mám kouzelný počítač. bash nemám, a expanze hvězdičky funguje.

Neplette dohromady SCP a SFTP. To je jina vesnice.

Ano. scp je (v této debatě) program z balíku OpenSSH, který implementuje SFTP klienta.

Co ma spolecneho read-only medium a tar? Nikdy jste nevidel konstrukci tar -cf - soubor1 soubor2 .. souborN | ssh user@remote tar -xf - -C /remote/dir?

A opačně, když chci přenést soubory ze vzdáleného počítače na lokální? Taky to napíšete z hlavy? Mimochodem, kde v tom vašem zápise vidíte použití příkazu scp?

[Ash]

Psát z hlavy - to jste předpokládám nemyslel ten příkaz (který umí každý, je to klasika) ale myslel jména těch souborů na vzdáleném stroji?

Pak by stálo za to vypíchnout další věc, kterou jste tedy asi naznačil, a sice že ten modul může omezit bash-completion při doplňování jmen na vzdáleném stroji při použití scp, která je prováděna přes ssh.

V souvislosti s tím bych ten limit nastavil nějak rozumně (vyšší), ale zcela bych ho neodsuzoval. Když uživatel dlouho nemůže přijít na to, kde vlastně je ten soubor, který chce kopírovat, tak ať si trochu odpočine, provětrá mozek, a pokračuje po vypršení limitu :)

[Filip Jirsák]

Psát z hlavy - to jste předpokládám nemyslel ten příkaz (který umí každý, je to klasika) ale myslel jména těch souborů na vzdáleném stroji?

Příkaz, který v rámci jedno ssh spojení na vzdáleném počítači zabalí soubory, pošle je na lokální počítač a tady je rozbalí? To z hlavy rozhodně nenapíšu (což samozřejmě není měřítko).

V souvislosti s tím bych ten limit nastavil nějak rozumně (vyšší)

Abych pravdu řekl, nevím, jak zsh-completion (v mém případě) pracuje se spojeními při doplňování ze vzdáleného serveru (tedy jak moc si drží jednou otevřená spojení, a jak moc spoléhá na přístup „nevadí, klidně si připojím za chvilku znova“). Takže nevím, zda nastavení rozumného limitu pro práci by neznamenalo úplnou bezzubost takového opatření.

[Ash]

Ale jo, je to skoro stejné jako z lokálu na vzdálený stroj, považuji to za takovou klasiku, užije se to i v jiných případech (posíláte data procesu na vzdáleném stroji, třeba rrddump | ssh a@b "rrdrestore"), ale je fakt, že mne to zaujalo v době, kdy jsem nevěděl, že existuje nějaké scp, tak možná proto :) Je to jen otázka kam dát to "scp".

tar -cf - file1 file2 | tar -xf - -C dir

tar -cf - file1 file2 | ssh user@hostname "tar -xf - -C dir"

ssh user@hostname "tar -cf - file1 file2" | tar -xf - -C dir

S tou bezzubostí máte pravdu, je to asi "buď recent, nebo bash-completion". Mnohem vhodnější bude modul na složitější hesla, jak jste navrhoval, a být připraven na zával žádostí o obnovu hesla :D

[Filip Jirsák]

Než bych si ověřil, že se mi do výstupu nepřidá uvítací hláška vzdáleného systému nebo výzva pro zadání hesla, udělal bych to dávno jinak. Samozřejmě pokud nad tím někdo nemusí přemýšlet a ví rovnou, že uvítací hlášku přece vypisuje login nebo shell, který se v tomto případě vynechá, a že výzvu pro zadání hesla neposílá ssh na standardní výstup (to už fakt hádám), je to pro něj běžné použití.

[Ash]

Chápu, já bych zase musel trošku přemýšlet nad syntaxí scp, které nepoužívám. Na uvítací hlášku jsem jednou narazil (u špatně nakonfigurovaného systému, byl potřeba update:). Jinak problémy nebývají, je to rutina.

[Filip Jirsák]

Expanzi hvezdicky vzdy provadi bash. At uz lokalni nebo vzdaleny.

Jenom aby to někoho nemátlo, pokud se sem dostane: Expanzi na vzdáleném serveru samozřejmě neprovádí bash ani jiný shell. Ono by asi bylo dost složité nebo spíš nemožné obecně z libovolného shellu v neinteraktivním režimu vymámit expanzi cesty s žolíky. Ve skutečnosti to, alespoň v implementaci SFTP serveru v OpenSSH, dělá funkce glob (3).

[Ash]

>>Jak podotknul kolega, uz vymysleli tar.

>Jenže scp umí kopírovat jen soubory, takže bych ty zdrojové soubory musel spojit do jednoho souboru, k čemuž nemusí být místo ani příležitost

Tar spojuje zdrojové soubory do jednoho souboru. Je to vlastně jediná věc, co dělá (a dělá ji dobře). Proto jsem mluvil o vhodnosti jeho použití. Místo stačí mít na cílovém počítači, tam předpokládám je. Příležitost je právě teď.

Jinak chápu že principem bylo ukázat, že omezení služby ssh (recent) může někoho omezit, přestože nechce na stroj útočit, ale "jen" ho chce zahltit ssh požadavky. Ano, je to tak. Je to omezení se všemi důsledky.

[Filip Jirsák]

Tar spojuje zdrojové soubory do jednoho souboru. Je to vlastně jediná věc, co dělá (a dělá ji dobře). Proto jsem mluvil o vhodnosti jeho použití. Místo stačí mít na cílovém počítači, tam předpokládám je. Příležitost je právě teď.

Je to trochu komplikovanější. tar umožňuje spojovat soubory a standardní vstup, a výsledek uložit do souboru nebo na standardní výstup. Jenže příkaz scp umí pracovat jen se soubory, tudíž jako zdroj ani jako cíl nemůžete použít standardní vstup nebo výstup. Takže buď byste musel tarem soubory spojit do souboru (který musíte mít kam uložit), nebo můžete použít pojmenovanou rouru (to mi připadá kvůli překopírování souborů po síti trochu komplikovaný postup), nebo vůbec nepoužívat scp a poslat výstup z taru anonymní rourou do ssh. Jinak tar je samozřejmě vhodný nástroj, když to budete chtít třeba opakovaně pouštět ve skriptu. Když si ale nejprve odladím find, aby mi našel pár desítek správných souborů, tak pak na závěr akorát přidám -exec scp, a nebudu řešit, že je to neefektivní. Vy to evidentně chápete, alkoholik asi ne

[Ash]

Dobrý nápad s tou rourou, jednodušší bude ale asi:

tar -cf - file1 file2 | scp /dev/fd/0 user@remote:/nejaka/cesta/soubor.tar

což je k mání někdy od roku jádra 2.4. Já bych ve všech zatím zmiňovaných případech použil to ssh :) ale pokud je někdo zvyklý na scp, jak říkám, ten limit chce mít rozumný, ne 3 pokusy a dost, ale třeba sto a chvíli pauza.

A kdyby bylo jen po mém, tak bych limit nedával žádný, cítil bych se tím jen omezen, nikoliv chráněn.

Na druhou stranu pokud bych věděl, že tam mám uživatele, kteří trvají na tom že musí mít hesla a ne klíče (protože třeba neví jak klíč uložit do mobilu), a věděl bych, jak asi jejich "hesla" budou vypadat, asi bych ten recent zvážil, s pocitem, že maj co si zaslouží :)

Zabezpečení je stejně jako cokoliv vždy otázka určitého kompromisu, nejzabezpečenější počítač je nedostupný a nejde použít apod...

[Filip Jirsák]

Ta varianta s /dev/fd/0 mne vůbec nenapadla. Ale je na tom dobře vidět, jak je v unixu spousta možností, jak udělat jednu a tu samou věc. Myslet na to, že jednu variantu nemůžu použít – rovněž bych si připadal omezen, ne chráněn.

Na druhou stranu pokud bych věděl, že tam mám uživatele, kteří trvají na tom že musí mít hesla a ne klíče (protože třeba neví jak klíč uložit do mobilu), a věděl bych, jak asi jejich "hesla" budou vypadat, asi bych ten recent zvážil, s pocitem, že maj co si zaslouží :)

V tom případě bych použil spíš PAM modul na vynucení kvality hesla. Aspoň by uživatelé rychle zjistili, jak ten klíč do mobilu uložit

[pht]

tar -cf - file1 file2 | scp /dev/fd/0 user@remote:/nejaka/cesta/soubor.tar

No a nebo prostě

... | ssh host 'cat >soubor.tar'

[Ash]

Ten váš příklad ale jaksi neilustruje použití /dev/fd/0 u nástroje, který umí pracovat jen se soubory, což bylo aktuální téma diskuze :)

Jste si jist, že všude, kde lze použít scp, lze automaticky použít i ssh?

[Ash]

Nemluvě o tom, že v případě ssh asi nepůjde bash-completion cesty na vzdáleném stroji (cat > /home/abdaluhguldiwarth/presto/ese/meo/precnik/savemethere), což bylo rovněž horké téma.

[Ash]

tar

Pokud na počet souborů nestačí délka příkazové řádky, bude jich asi hodně, takže není chytré je posílat po jednom přes scp. Naštěstí byl vynalezen tar.

[Jooky (inactive)]

Ja pouzivam recent/iptables (jedno spojenie za 30 sekund a len 2 moznosti na hesla) + multiplexovanie spojeni. Inak povedane, vzdy otvaram jedno ssh spojenie, pre lubovolny pocet terminalov a scp sessien. Tato kombinacia sa mne najviac osvecila. V linuxe sa to da nastavit uplne transparetne pre ssh/scp a gui nadstavby (priama podpora v ssh). Prvy raz prejde autentifikacia a potom dalsie "spojenia" idu v jednom kanali. Tak sa da kazde dalsie "okno" nepomerne rychlejsie otvorit a netreba riesit hesla + lamat fw cez koleno.

[dustin]

Již roky na serverech používáme denyhosts, firemní IP adresy jsou whitelistované, hosts.deny má 10 tis. řádků, root jen přes klíče a zatím s tím nikdy problém nebyl. Jen uvádím vlastní zkušenost.

[Piki]

1. prehodit SSH na jiny port

2. zakazat prihlaseni pod uzivatelem root

3. povolit prihlaseni pres ssh jen pod par uctama

[Filip Jirsák]

4. Dohledat si v dlouhosáhlých diskusích na AbcLinuxu, proč je to spíš ku škodě věci.

[jirkamailto]

Prehozeni na jiny port je sice hezke, ale pokdu se prihlasuje vice uzivatelu navic kazdy uzivatel z ruzneho pocitace, bude je to jiste obtezovat. Zakazat prihlaseni roota primo je urcite vhodne. Povolit prihlaseni urcitych uzivatelu neni vhodne, protoze pri pridani noveho uzivatele muzes zapomenout pridat do konfigurace ssh toho uzivatele. Je lepsi zakazat direct prihlaseni vybranych uzivatelu u kterych vis ze se nikdy nebudou potrebovat prihlasit pres ssh.

[Filip Jirsák]

Zakazat prihlaseni roota primo je urcite vhodne.

Zejména jako startovací bod pro diskuse o tom, proč je to k ničemu. Ale jak je vidět, kouzlo pořád funguje.

[Ed]

> Prehozeni na jiny port je sice hezke, ale pokdu se prihlasuje vice uzivatelu navic kazdy uzivatel z ruzneho pocitace, bude je to jiste obtezovat.

Zabezpeceni je obvykle kompromis mezi bezpecnosti a pouzitelnosti.

Ten port si staci dat do .ssh/config.

Klice jsou obecne lepsi nez hesla, ale pokud kopirujete neco ze vzdaleneho serveru na kterem se nejdriv musite prihlasit na roota, na jiny server, je to opruz. Jasne, jde to, ale je to opruz.

denyhosts/recent/fail2ban/sshguard ma tu vyhodu, ze pokud je adresa blokovana, tak chrani i pred chybami v ssh.

Povolit firewallem spojeni jen z nekterych adres je taky dobra soucast reseni. Pokud to zrovna vam nevyhovuje, ok, ale v kombinaci s VPN nebo pristupovym serverem se to pouziva bezne a ku prospechu veci, rekl bych.

[asdfasd]

Odinstaluj SSH demona, potom tieto problemy mat nebudes.

[alanos]

Tak to sleduji týden, po té co jsem zakázal přihlašování přes hesla tak je tak 1 pokus za den /někdy ale vůbec nic/.