Názory k článku
Hostingové služby nerespektují bezpečnostní doporučení

Obavam se, ze autor ponekud prestrelil. Contactel neni z nejmensich ISP, ma webhosting, serverhosting i portal a MA nameservery na ruznych sitich, dokonce v ruznych lokalitach.
Vsechny domeny v Contactelu hostovane tedy jsou podobneho problemu usetreny.
Mimochodem, nemyslim, ze umisteni nameserveru na jednu sit je _bezpecnostni_ problem. Spis je to problem navrhu site. Ten muze byt byt spatny nebo dobry, ale jestli muze byt i bezpecny, pripadne nebezpecny, to si nejsem moc jist.
Nebezpecny muze byt samotny provoz, ale tezko umisteni.
Kazdopadne, straste lidi, piste pokud mozno poplasne ladene zpravy. Zvysuje to navstevnost ;)
Pro uplnost jsem se dival na nameservery nekterych ISP:
Contactel - ruzne site, ruzne lokality
GTS - ruzne site
IOL - stejne site
Eunet/KPNQuest - ruzne site
Nextra - stejne site
PVTNet - ruzne site
InWay - ruzne site
.... takze situace neni tak zla, jak vidno. Pokud si webhostingova sluzba chce delat DNS sama a udela si DNS nejlepe na dvou IP jednoho fyzickeho stroje, nemuze s tim ISP nic udelat. Krom toho, ze nabidne vlastni, lepe postavenou sluzbu.

trochu fer pristup by mozna neuskodil, u Contactelu uvadite ruzne lokality, u jinych nic. Bud zkuste zjistit udaje u vsech, nebo o nich nepiste, vyvolavate nespravne dojmy. Prinejmensim GTS ma nameservery rovnez umistenene v ruznych lokalitach

Jiste, pripoustim, ze situaci u jinych provideru neznam, proto jsem pouzil informaci, kterou si muzu zjistit (a overit). Puvodni clanek me ovsem ponekud nadzvedl (slusne receno) a utvrdil me v ponekud tendencnim zamereni Lupy. Proste jsem se nechal unest. Osobne predpokladam, ze vetsina provideru narodniho vyznamu ma nameservery nejen na ruznych sitich, ale i v jinych lokacich.
Soude podle vasi (opravnene) lehce rozhorcene reakce usuzuji, ze s puvodnim clankem take "lehce" nesouhlasite.

No Contactel ma asi ruzne lokality, ale urcite stejne site :-) Nebo si terminologicky nerozumime. Fakt je, ze stejnou chybu dela vetsina nasich ISP.

Ruzna sit je jiny ISP. Nechci se chlubit, ale zkus zkusit totez u domeny pinknet.cz :-)

co je to sit? Mam za sit povazovat subnet, nebo sit urcite tridy, nebo jednoho ISP? Asi o tom lze polemizovat. Na druhou stranu z ceho poznam, ze stroje s IP 192.168.0.5 a 192.168.0.35 jsou na stejnem subnetu? Teoreticky muzou lezet v ruznych mistech republiky, pokud ma provozovatel dostatecne sileny adresni plan a silne paterni routery.

Pravdou asi je, ze jeden zalozni DNS/MX server mimo prostor ISP se hodi, riziko je ale na podle mne unosnou miru snizeno pri pripojeni na ruzne upstream provideru z ruznych bodu vlastni site.

... coz predpoklada 100% funcknost vlastni IP site ... coz je mimochodem cira utopie ... Pomineme-li marketingove "benefity " :-)

s utopii souhlasim :-)). Ale kdyz zalozni sluzby umistim dostatecne blizko zaloznim linkam, pak vypadek hlavni casti site nema za nasledek nedostupnost zaloznich sluzeb z okolniho internetu.

Sveho casu jsem u nejmenovaneho ISP z telekomunikacniho ringu nezavazne poptaval cenu za umisteni serveru prave pro tyto ucely. Odpoved jsem nedostal. To je potom tezke.

"Ruzna sit je jiny ISP. Nechci se chlubit, ale zkus zkusit totez u domeny pinknet.cz :-)"

Okay, necht. V tom pripade temer zadny (=nevim o zadnem) cesky ISP tomuto predpokladu nevyhovuje. Je fajn, ze domena pinknet.cz je na tom lip (moje soukrome domeny taky). Nicmene velke organizace typy ISP to tak jednoduche nemaji. Treba ten.cz (jeden AS), ze ano :) Pravda, potize maji i ti mensi, treba pragonet (jeden segment) :)

No rekneme to tak, ze kdybych byl zodopovedny za provoz IP sluzeb u takoveho providera, rozhodne by tomu tak nebylo. Nastesti nejsem :-)

Slozitejsi pro velke organizace to rozhodne neni. Jde spise o lenost prislusnych lidi :-)

Pri tvych nepopiratelnych schopnostech by nemelo byt tezke to v ramci firmy vykomunikovat. Je podivne, ze se spokojis s nadhledem nad chybami/lenosti firem, s kterymi mas co do cineni, potazmo pro ne pracujes.
Nicmene pripadne dalsi kolo teto diskuse navhuji spis jen mezi sebou :-)))

No jsou veci, ktere ma cenu komunikovat a jsou veci, ktere cenu komunikovat nema - respektive jsou dulezitejsi veci na praci :-) Ale to urcite znas taky ...

Tedy promin, MK, ale "to communicate something" v anglictine neexistuje. Pak nevim, kde jsi vzal "komunikovat neco". To je k zbliti. Uz staci "zminit neco", "diskutovat neco" a podobne vyblitky.

Proboha a vsiml jste si uz, ze Nextra a PVTnet je uz jedna a tataz sit, jen ma do NIXu dva pristupy ? Takze kdyz PVTnet podle Vas ma nameservery na "ruznych" sitich, jakto ze Nextra nema ?

Asi je CTT fakt best ve vsem :o)

Nikdy jsem nerekl, ze CTT je best ve vsem. To, ze PVTNet a Nextra jsou po svatbe nijak neimplikuje stav zakaznickych sluzeb obou partneru provozovanych pred svatbou. Kdyz CTT koupil komercni Cesnet, byly (a stale jsou) nektere zakaznicke sluzby provozovany prakticky beze zmeny. Je mozne, ze v pripade PVT<>Nextra to je jinak, ale dost o tom pochybuji.
Takze, proboha si uvedomte, ze po zakoupeni casti konkurence _neni_ vasi hlavni cinnosti desinfikovat nakoupene zelezo a prenaset vse na vase puvodni stroje. Vasim prvoradym zajmem bude, aby pokud mozno nikdo ze zakazniku tuto zmenu nezaznamenal. Asi nebudete, alespon hned, pregistrovavat domeny z jedne entice vasich nameserveru na jinou emtici.

... az takovou vec pochopi i nejmenovany ISP, ktery koupil cizi sit (neni to NEXTRA), velmi se ulevi memu mobilnimu telefonu.

Nemuzes to tomu nejmenovanemu operatorovi nejak tlumocit ? :-)))

Neda mi to nereagovat - byl bych rad, kdyby si ten nejmenovany koupeny taky uvedomil, jaky mel v cele siti b....l. Ale opravdu dalsi diskusi spis osobne...

Myslite jako treba Zdenka ? :-)))

No, pokusim se to vyvesit ve vsech vytazich ;)

IMHO nestačí mít odděleně umístěné nameservery, ale taky více MX záznamů, a někde mít alespoň mail-relay, ne? Je sice hezké, že se dozvíte správnou adresu mail serveru, ale když je tento také nedostupný, tak to nepomůže.

Kdyz je znamy, ale nedostupny, tak mail zustane ve fronte na odesilacim mailserveru a muze byt dorucen pozdeji. Kdyz je ovsem neznamy, tak bude mail okamzite vracen odesilateli

To jsem nevěděl. Díky za informaci. Ale stejně bych to dal alespoň jako doporučení, protože v té frontě můžou maily třeba po dnu vypršet. No ale zase je fakt, že celodenní výpadek by i tak byl docela průser...

Pred deviti dny jsem zadal webhostingovou sluzbu pes.cz
o upgrade php z 4.0.2 na aktualni verzi a to z duvodu bezpecnosti:

http://www.securityfocus.com/bid/2205

Zde je odpoved a musim napsat, ze na serveru, kde mam domenu se zatim nic nezmenilo. Pritom upgrade na novou verzi je otazka maximalne nekolika desitek minut.

Dle meho nazoru zneprsitupneni serveru je otazka nekolika sekund.


ODPOVED Z pes.cz


Vazeny pane,
o upgradu samozrejme uvazujeme, ale je to docela problematicka zalezitost.
Prinese hodne problem vsem klientum a hlavne na nejakou dobu znepristupni
cely nas server.

Problematice zabezpeceni se veneujeme prubezne.

Dekujeme za informaci a preji hezky den
Josef Grill

Jojo, PES :o))) Az vam nekdo smaze veskera data a podobne (at uz je to hacker ci admin PES :o)), nebo az vam server nepojede cca deset dnu (dungeony.cz rulez :o)), tak udelate to co vetsina provozovatelu ambiciozne rostoucich serveru, ktere by mely spise fungovat nez nefungovat (napada me treba Seznamit.cz, ktery mel nejprve reklamy na Psa snad vsude na homepage, kam se clovek podival :o)) - sbalite si svych pet svestek, databazi a ja nevim ceho vseho jeste a pujdete co nejdrive jinam :o)))

BTW: a za tenhle prispevek budu sedet, nebot mi prave volal Grill, ze jde oznamit na policii trestny cin pomluvy z me strany :o))) Aspon vidite, co se u Psa dela cely den - ctou internetove diskuse :o)))

Cituji začátek skutkové podstaty trestného činu pomluvy podle § 206 odst. 1 tr. zákona : Kdo o jiném sdělí nepravdivý údaj, který je způsobilý značnou měrou ohrozit jeho vážnost... Nevím, jestli tady někdo sdělil nějaký nepravdivý údaj, ale dost jistě vím to, že kromě čtení intertnetových diskusí, se po zbytek dne, když zbude chvíle, u PSA píše denně několik trestních oznámení. Ale jsem klidný, zatím z důvodu psích trestních oznámení nikoho nezavřeli. Bylo by zajímavé založit Sdružení těch, na které PES podal trestní oznámení, myslím, že by nás nebylo málo :-))

No já myslím, že je už dávno veřejným tajemstvím, že PES se hodí možná tak k hostování osobních stránek :)

To by pak šlo sedět více lidí. Můj známý měl u Psa "lechtivý" server a cituji: "Po týdnu neustálých výpadků a dohadování s jejich techniky jsem se sbalil a utíkal jako zdravý před morem." Takže s tou kvalitou to nebude nic moc. Já osobně jsem u Globe a nestěžuju si (konec skryté reklamy ;-)).

he he ono o jejich profesionalite hovori uz jen ten fakt ze vsechny jejich servery na TELECOMU maji kvaltni pripojeni jednim spolecnym koaxem :-), myslim ze to je revolucni technicka novinka kterou nikdo jiny nepouziva :-))))

Dobry den ve spolek. Plne souhlasim s panem Polachem. PES jsou nejvetsi amateri, jaky kdy cesky webhosting videl. Nejenze ze neumi delat svoji praci, ale ani nezvlada zakladni pravidla slusneho chovani. Radsi se k tomu nebudu vice vyjadrovat, zabralo by to min. par kB, stejne planuji sepsat a nasledne zverejnit sve pameti a zkusenosti s touto znamou "firmou". Zdravim Vas, pane Grill - dlouho jsem o Vas neslysel :)))

Až je budete sepisovat, vzpomeňte si i na mě, stanu se signatářem :)

Musim konstatovat, ze autor predchoziho prispevku si predstavuje provedeni upgradu na serveru, kde bezi mozna stovky webu jako Hurvinek valku. Co, kdyz se stane to, ze po provedeni upgradu nepobezi desitky serveru, ktere vam za provoz plati nejake penize...

Jo jo, je to tak.
Kdyz si nekdo predstavuje neco, co nemusi byt jen otazkou par sekund. Pan Grill uvazuje dle meho nazoru rozumne.

Takze podle vas se upgrade neudela dokud bude ten server fyzicky existovat, ze. A to, ze hrozi prunik do systemu a kradez dat a zdrojaku, to vam asi nevadi, ze?

Nezaznamenal jsem za ten vice nez tyden od pes.cz zadnou snahu problem resit. Jako mozne reseni vidim napriklad oznameni: "dne x.x bude proveden upgrade php4.0.2 na bezpecnejsi php4.0.4pl1. Doporucujeme provozovatelum virtualnich serveru naslednou kontrolu funkcnosti jejich skriptu".

Ale to oni ne, jen ticho po pesine.

Poznamky v nekolika komentarich a me zkusenosti s "on-line" zprovoznenim serveru a database uvazuji o odchodu jinam.

Muze nekdo doporucit levny, ale dobry webhosting?

Mohu doporučit firmu OUTLINE, u níž hostuji. Zatím žádné problémy, vstřícný přístup, levné ceny. Jsou na stránkách www.outline.cz.

Abychom se drzeli tematu:

Non-authoritative answer:
outline.cz nameserver = ns1.outline.cz
outline.cz nameserver = ns2.outline.cz

Authoritative answers can be found from:
ns1.outline.cz internet address = 194.228.3.58
ns2.outline.cz internet address = 194.228.3.59

Ze by .58 a .59 nebyli na stejne siti (ci dokonce na stejnem stroji) - to podle mne neni ani mozne..

Jinak outline neznam, jejich kvalitu hostingu nemohu posoudit..

Na jedné síti jsou sice taky, ale ne na jednom stroji. To jen pro upřesnění.

No jo, ovsem pak se nesmi divit, az mu to pres nejaky znamy bug nekdo hackne...

Ja si nemyslim, ze by problem upgradu byl tak velky.
Budu-li uvazovat server apache, upgrade znamena bud prelozit znovu s novou verzi PHP, nebo, pokud pouzivam nemodifikovany balik z distribuce(coz asi ne), update baliku. Specielne u PHP se myslim nestane, ze by prechod na novejsi verzi( nemyslim z 3.x na 4.x) znamenal nejakou nekompatibilitu s verzi predchozi, zvlaste kdyz jde v podstate o bezpecnostni patch.
Samozrejme, ze stary apache hned nesmazu. Udelam si zalohu a pokud se nedejboze neco nepodari, snadno to z te zalohy obnovim. Co je na tom tak narocneho? Co na to Hurvinek?

Jeste k debate o nameserverech. Ja osobne si myslim, ze pokud mam nameservery na ruznych IP segmentech s ruznymi cestami ven, uplne to staci. U posty problem resi vice MX serveru, jak uz tu nekdo podotkl. Pokud 'chcipne' linka, ktera me spojuje s ostatnim svetem, bud existuje jina a pak je alespon cast site dosazitelna, nebo je jedno, kde je jaky server. Pak by asi bylo vhodne mit nameserver u jineho providera. To s sebou ale prinasi problem se spravou a neco to vetsinou stoji. Proste to nepovazuji za obecne platne pravidlo(jak jsem mel pocit z clanku). Ani zminovane RFC nikde nerika, ze je nutne mit zalozni servery v sitich cizich subjeku. Nebo se mylim? Clanek mi prijde dost populisticky. Vice objektivity a precteni trochy dokumentace by autorovi jiste nzaskodilo.

Jeste jeden dodatek. Nechapu, jak v kontextu clanku souvisi umisteni nameserveru v lokalite a sitich s bezpecnosti. Autor si zjevne plete hodinky a holinky.

No, to je asi jednoduche, ne? Pokud budete mit dva nameservery v jedne cimre, byt na uplne jinych dratech do jinych siti, pri pozaru vam shori oba dva... Bezpecnejsi je, mit kazdej fyzicky nekde jinde... Takze to souvisi s bezpecnosti (stabilitou i za zhorsenych podminek castecnych vypadku) provozu jako takoveho. Ja bych se pojmu bezpecnost provozu nebranil...

Mozna. Moje reakce pramenila z toho, ze z clanku jsem mel pocit, ze vubec nejde o zadnou bezpecnost. O bezpecnosti mluvi jen tucny titulek. Takze muzeme vymyslet, spekulovat, hadat se. Ja tez nemyslel fyzickou bezpecnost masiny. Kazdy pocitac vam prece muzou ukrast. :-))

Dobry den! Dovolim si nesouhlasit s vyse uvedenym:
> Proste to nepovazuji za obecne platne pravidlo(jak jsem
> mel pocit z clanku). Ani zminovane RFC nikde nerika, ze
> je nutne mit zalozni servery v sitich cizich subjeku.

Zde je citace z RFC:
"When selecting secondary servers, attention should be given to the various likely failure modes. Servers should be placed so that it is likely that at least one server will be available to all significant parts of the Internet, for any likely failure". Zde se rika, ze by servery mely byt umisteny tak, aby byly dostupne z vetsiny internetu i v pripade vypadku. "Consequently, placing all servers at the local site, while easy to arrange, and easy to manage, is not a good policy. Should a single link fail, or there be a site, or perhaps even building, or room, power failure, such a configuration can lead to all servers being disconnected from the Internet." Tady se rika, ze neni dobre umistit oba servery na jednom miste, ci serveru.. "Secondary servers must be placed at both topologically and geographically dispersed locations on the Internet, to minimise the likelihood of a single failure disabling all of them."

Zde se rika, ze servery MUSI (zminovane RFC nikde nerika, ze ;-) byt umisteny na ruznych mistech jak topologicky (ruzne site) tak i geograficky (jine misto).

"That is, secondary servers should be at geographically distant locations, so it is unlikely that events like power loss, etc, will disrupt all of them simultaneously. They should also be connected to the net via quite diverse paths. This means that the failure of any one link, or of routing within some segment of the network (such as a service provider) will not make all of the servers unreachable." Etc...

Opet se rika, ze vyse uvedene doporuceni zajisti, aby nameserver byl dostupny i v pripade vypadku konektivity.
-----
K tomu, ze:

> Clanek mi prijde dost populisticky. Vice objektivity a
> precteni trochy dokumentace by autorovi jiste neskodilo Stouru jsem na celou situaci upozornil ja a to uz pred casem. Vedlo mne k tomu kuriozni zjisteni - ne u PES.CZ, ale u CZECHIA.COM - tam totiz ve 14. duvodech proc volit Czechii uvadeji, ze:
> 12. Autonomní doménový systém
> Czechia má autonomní doménový systém. Nově vąechny domény
> registrujeme na DNS servery ns1.czechia.cz a
> ns2.czechia.com. Jedinečnou výhodou Czechie je, ľe oba
> DNS servery jsou na různých sítích a mají různé doménové
> jméno, takľe výpadky konkrétního poskytovatele nebo DNS
> serverů registrátorů se netýkají domén na Czechii.

Kdyz jsem to nasel, tak jsem si nejdriv rekl "to je dobry napad s temi .cz a .com domenami.." a aplikoval to i u nas (DNS u ruznych poskytovatelu jsme tehdy uz samozrejme meli) - od te doby se pro registraci novych domen pro domeny.cz pouzivaji ns.servery.cz a ns.servery.com umisteny kazdy skutecne na jine siti a i v jine domene.. Pri te prilezitosti mne take napadlo si udelat traceroute na oba uvadene servery (ns1.czechia.cz a ns2.czechia.com) a dosel jsem ke kurioznimu zjisteni - oba jsou sice na jine siti (nelze takto na dalku overit, ale mozna ano), ale kupodivu k nim vede stejna cesta - na sit NEXTRA..

Stouru jsem upozornil jeste jednou - po vypadku site IOL v jedne z predchazejicich noci (kdy mimo jine i cela slavna "nepretrzita" technicka podpora IOL hlasila stale, ze vsichni operatori jsou obsazeni :-)) a kdy jsem zjistil, ze neni diky tomu dostupny ani jeden z nameserveru PES.CZ..

Diky za citace RFC. I ja jsem jej cetl. Nikde mi z nej vsak nevyplyva, ze ono topologicke oddeleni MUSI byt nutne na urovni providera. Jak jsem rikal v predchozim prispevku: Proc by nemohly byt ony servery v RUZNYCH IP SEGMENTECH? Samozrejme jsem myslel i v jinych fyzickych lokalitach.
Predpokladam, ze do siti o kterych se bavime LZE vstoupit ruznymi cestami.

Mate pravdu v tom, ze je lepsi, kdyz jsou servery rozdeleny mezi vice provideru, ale jak rikam NEMUSI TO BYT NUTNOST.

Dobry den!

Je pravda, ze ve zminovanem RFC neni rec o ruznych providerech - lze tedy samozrejme mit oba servery u stejneho providera v ruznych lokalitach nebo ruznych sitich.. Lze si ale snadno overit, ze ani Pes ani Czechia (alespon podle traceroute) nic takoveho nema..

Ano, namitku prijimam.. I kdyz mne napada - pokud se bude jednat o jednoho providera, ktery ma routing ve vlastni siti manageovany centralne a chyba v routingu, ktera zpusobi vypadek se proto promitne do cele jeho site, pak to bude problem.. Jedna se samozrejme pouze o hypotezu.. (ale chybu v routingu jako duvod nedostupnosti uvadi RFC a proto mne take tato konstrukce napadla..)

ale panove...
v puvodnim prispevku se mluvilo o upgrade PHP 4.0.2 na PHP 4.0.4pl1, tzn zadna podstatna zmena
takze upgrade znamena pouze rozbalit zdrojaky php, ./configure --s-puvodnim-nastavenim, make, make install, apachectl restart
v pripade, ze mate php zkompilovane jako dso a zalohovany konfigurak, je to vcetne downloadu prace na 10 minut.

Mate pravdu, prekompilovat apache, pripadne vymenit modul, je v idealnim pripade prace na deset minut.
Problem je ale v tom, ze pokud provozujete webhosting s radove tisici weby, z nichz zhruba desetina pouziva php, problemy s nekompatibilitou se temer urcite vyskytnou, i kdyz se jedna o upgrade minor verzi. Zkuste se podivat na opravdu velke servery, v jake bezi konfiguraci, a zjistite, ze do upgradu se adminum nijak moc nechce.
Na druhou stranu je jasne, ze pokud se jedna o bezpectnostni zaplatu, je treba provest upgrade co nejrychleji. Z meho pohledu se mi jevi schudne vystavit na strankach informaci o upgradu, duvod, pripadne mozne komplikace a take konkretni datum prechodu. Nebylo by na skodu poslat klientum webhostingu take email. Pokud by se u klientskych webu objevily potize, mela by byt moznost okamzite zajistit prechod na puvodni konfiguraci.

to snad nemyslite vazne? vezmu to selskym rozumem: dela se (mela by se) delat napriklad denni nebo tydenni zaloha. co brani dotycenmu zazalohovat, upgradovat a pripadne obnovit? ztrata dat za nekolik hodin ktere si mezitim nekdo ulozi? najit hodiny s nejmensim provozem, dat to dopredu vedet at s tim lide pocitaji pro "sichr" a hotovo.
2. varianta - nejlepsi proste cely uprade provest nejprve na zaloznim stroji (nemusi byt tak vykonny), otestovat, spustit ladit.... posleze pustit na hlavnim stroji

nebo mi snad chcete rici ze takhle to nefunguje, pripadne ze "velky" "slavny" "nejlepsi" apod. privlastky, ktery si kazdy poskytovatel dava nema treba zalozni masinu nebo nejake zalohy? v tom pripade at bezi slusne "nekam", to si to muzu provozovat na svem stroji bez zalohovani apod a budu na tom stejne....

Pan Grill mi (telefonicky) vytknul, ze jsem sve dva predchozi prispevky nepodepsal, takze timto tak cinim. Mel jsem za tom, ze me jmeno neni podstatne (viz napr. prispevek od 'm') a ze obsah je podstatnejsi. Takze svuj omyl ted napravuji.

Uvedene Dungeony.cz nebyly mimo provoz ne kvuli Psu.cz, ale kvuli jinemu problemu.

Jojo, Mawerick me podrobne informoval :o))) BTW: kdyz to nebylo kvuli PSU, proc chtel jit do Prachovic nebo jaxe ta dira jmenuje hazet granaty? :o)))

Když už jsme u té bezpečnosti hostingových firem. Podívejte se schválně do jejich nabídek. Většina z nich nabízí přístup k pronajatému prostoru jen přes FTP nebo FrontPage extenze. Oba dva protokoly přenášejí jméno a heslo v otevřené podobě, takový ráj pro hackery.

Těším se na dobu, až místo FTP a FP uvidím v nabídkách jen FTPS a SCP. Jestli chcete něco udělat pro zvýšení bezpečnosti stránek zákazníků, nabídněte jim přístup přes SCP a program WinSCP (http://winscp.vse.cz), který nabízí grafické prostředí ala Norton Commander pro práci se vzdálenými soubory přes SCP.

Hmmm, SCP a co takhle Safe FTP ???

http://www.cs.berkeley.edu/~smcpeak/SafeTP/

Ahoj!

Napad dobry, je fakt, ze kdyz jsem se dozvedel o WinSCP tak jsem o tom uvazoval.. Bohuzel je problem - aby to fungovalo, musi mit uzivatel povoleny shell - pokud nema, WinSCP (a vubec scp) nefunguje... A na hostingu maji uzivatele nastaveny shell na /bin/false - tedy jako by ho nemeli.. A povolovat jim ho kvuli tomu se nam z bezpecnostnich duvodu nechce..

Nazdárek!

Co takhle přidat "/bin/false" do "/etc/shells"? Nebo vzít nějaký jiný (z hlediska bezpečnosti) "false" program, přidat ho do "/etc/shells" a uživatelům jediným scriptem v "sed"u nahradit zatím invalidní shell validním?

http://www.explorer.cz/konf.html

dokazuje, že explorer.cz má tři servery, jeden IBM. V reklame se píše že "běží na serverech IBM Netfinity". Že by podvod?