Onderwerp: Hoe sFTP aan te bieden

In http://www.webhostingtalk.nl/overige...-over-ssl.html wordt ook geponeerd dat het makkelijk is om sFTP aan te bieden aan klanten van shared hosting. Er wordt echter niet ingegaan op hoe je dat dan technisch kunt uitvoeren. Hoe doe je dat, hoe makkelijk is het?

In het oorspronkelijke topic worden sFTP en ftps door elkaar gebruikt. Over het algemeen bedoelt men met SFTP het SSH File Transfer Protocol en met ftps wordt FTP-over-SSL bedoeld. Beiden zijn in principe even veilig (SFTP gebruikt geen certificaten maar fingerprints die je eventueel in DNS kunt zetten) maar SFTP is iets NAT-vriendelijker aan de client-kant (er wordt geen verbinding geopend richting de client, wat bij klassiek FTP wel het geval is).

Als je je klanten shell (over SSH) aanbiedt dan kunnen ze daar in de meeste gevallen al naar SFTP-en.

Voor ProFTPd bestaan modules voor zowel SFTP als ftps:

- http://www.proftpd.org/docs/contrib/mod_sftp.html voor SFTP-support - hoewel deze module wel wat configuratiemogelijkheden kent zijn deze volgens mij voor het meerendeel optioneel. Kwestie van de module inschakelen en gaan dus.

- http://www.proftpd.org/docs/contrib/mod_tls.html voor FTPS-support. Dit is wat ingewikkelder omdat je de certificaten (inclusief eventuele intermediate certificaten) moet configureren (met TLSRSACertificateFile, TLSRSACertificateKeyFile en eventueel dus TLSCertificateChainFile).

In het oorspronkelijke topic was het een en ander te doen over het al dan niet gebruiken van self-signed certificaten. Ik zou zeggen: vooral niet doen. Laat in plaats daarvan klanten secure inloggen via ftp.<providernaam> en zorg dat de certificaten in orde zijn. We doen dit hier voor alles waar klanten op moeten inloggen (dus ook e-mail, webmail, etc.) en dat werkt prima. Als je hier toch problemen in ziet laat FTPS dan achterwege en gebruik alleen SFTP dat alleen vraagt om eenmalig een fingerprint te controleren.

Als je klanten moderne SFTP/SSH-clients gebruiken dan kun je een SSH/SFTP-fingerprint eventueel ook publiceren als een SSHFP-record in je DNSSEC-signed zone; dit is dan in principe net zo veilig als SSL-certificaten.

Wij hebben ons er met Pure-FTPd (wat wij gebruiken) nog eens aan gewaagd, maar oa FileZilla doet érg moeilijk, die schijnen zelfs geen commercieële certificaten te accepteren.

Wij raden altijd iedereen aan sFTP (over SSH) te gebruiken, maar lang niet iedereen doet dat.

Overigens vind ik virussen die FTP wachtwoorden op PC's sniffen een groter probleem dan het plain-text over het internet sturen.

De vraag gaat expliciet over sFTP. FTPs is makkelijk (aan de serverkant tenminste) en niets nieuws voor mij. Ik adviseer klanten al jaren om FTPs te gebruiken op een serverdomein dat uiteraard een geldig certiifcaat heeft.

Het probleem met zo'n mod_sftp is dat deze poort 22 claimt en dan krijg je daar weer gezeik mee. Serverbeheer, rsync, scp, sshfs, vanalles loopt over poort 22 en dat wil ik graag zo laten. En ik ga niet iedereen zomaar SSH toegang geven. Een jail voor ieder account valt in mijn ogen namelijk niet meer onder "makkelijk".

Kortom nog geen idee hoe je makkelijk de beveiligingstip van het andere draadje in de praktijk kunt brengen.

Oorspronkelijk geplaatst door t.bloo

Het probleem met zo'n mod_sftp is dat deze poort 22 claimt en dan krijg je daar weer gezeik mee. Serverbeheer, rsync, scp, sshfs, vanalles loopt over poort 22 en dat wil ik graag zo laten. En ik ga niet iedereen zomaar SSH toegang geven. Een jail voor ieder account valt in mijn ogen namelijk niet meer onder "makkelijk".

Hier zijn meerdere oplossingen voor:

- je 'echte' SSH op een andere poort draaien (iets dat sowieso populair schijnt te zijn als security-by-obscurity-maatregel)
- een apart IP-adres configureren en hier specifiek de SFTP-service aan binden (zorgen dat de SSH-server hier niet aan hangt)
- als je gebruikmaakt van loadbalancers dan heb je ook nog de mogelijkheid de SFTP-service op een andere poort te zetten en het verkeer vanaf je loadbalancer te laten redirecten naar die poort,
- je kunt je klanten SSH-toegang geven maar ze zo configureren dat ze alleen SFTP kunnen gebruiken en geen shell (even Googlen op "ssh restrict user to sftp" en de howto van je favoriete distributie vinden),
- de laatste oplossing is je klanten een andere poort te laten gebruiken.

Oorspronkelijk geplaatst door t.bloo

De vraag gaat expliciet over sFTP. Het probleem met zo'n mod_sftp is dat deze poort 22 claimt en dan krijg je daar weer gezeik mee. Serverbeheer, rsync, scp, sshfs, vanalles loopt over poort 22 en dat wil ik graag zo laten. En ik ga niet iedereen zomaar SSH toegang geven. Een jail voor ieder account valt in mijn ogen namelijk niet meer onder "makkelijk".

Kortom nog geen idee hoe je makkelijk de beveiligingstip van het andere draadje in de praktijk kunt brengen.

Als je key based SSH gebruikt, dan is een ding wat je zou kunnen doen is per key aangeven wat je er mee mag doen. Je kan namelijk de toegestane commando's en rechten per key volledig limiteren.

Zie daarvoor deze serie van artikelen, begin hier:
Secure Passwordless Logins with SSH Part 1
(en klik rechtsboven op "next") en bij Part3 en Part4 krijg je de details om de zaak te beperken.

Wat is er mis met SCP. Geef klanten /bin/scponly als shell.

Oorspronkelijk geplaatst door Randy

Wat is er mis met SCP. Geef klanten /bin/scponly als shell.

Het feit dat je ze da nog steeds in sshd_conf moet gaan chrooten, omdat ze anders aan elke folder op het systeem kunnen waar ze lees rechten op hebben (zoals /etc). Verder is scp lang niet zo breed ondersteund als sftp, of toch zeker niet in de doorsnee tools van een webdeveloper/webdesigner.