HowTo - Chroota SFTP med MySecureShell

[northface]

MySecureShell är en SFTP server som använder sig av OpenSSH. Den är flexibel och man har bl.a. möjlighet att fånga användarna i sina hemfoldrar eller andra foldrar. Man kan även styra bandbredd för upp- och nedladdning för enskilda användare. En annan finess är att det går att styra användarnas behörigheter genom grupper och ipnr. Av säkerhetsskäl ska man inte låta användare med root rättigheter köra MySecureShell.

MySecureShell med SFTP är mycket bra alternativ till vanlig FTP/FTPS, om man inte ska överföra alltför stora datamängder. Den är inte lika snabb som FTP/FTPS. I och med man kör SFTP är trafiken krypterad.

Avsikten med handledningen är att ge en introduktion till MySecureShell och är långt ifrån heltäckande. Mer information finns att hämta på webbplatsen http://mysecureshell.sourceforge.net


Installation

MySecureShell kräver libssl och openssh

Kod: Markera allt

sudo apt-get install libssl0.9.8 ssh openssh-server

Före hämtning förflyttar vi oss först förslagsvis till /tmp

Kod: Markera allt

cd /tmp

Hämta (version 1.0 gäller i skrivandes stund):

Kod: Markera allt

wget http://ovh.dl.sourceforge.net/sourceforge/mysecureshell/mysecureshell_1.0_i386.deb

Installera:

Kod: Markera allt

sudo dpkg -i mysecureshell_1.0_i386.deb

För att få uppdateringar förtsättningsvis lägg till nedanstående rad i /etc/apt/sources.list:
deb http://mysecureshell.free.fr/repository/debian testing main

Verifiera installationen

För att kolla att samtliga filer finns och att rättigheterna är som de ska, så kör kommandot härunder. Reparera vid behov enligt förslag.

Kod: Markera allt

sudo sftp-verif

Hantering av användare och grupper

För användare som redan har konto maskinen behöver man byta skal för dessa till /bin/MySecureShell om de ska att kunna köra MySecureShell

Kod: Markera allt

sudo usermod -s /bin/MySecureShell <användare>

Ett varningens ord: Ändrar man en användares skal (från normalt bin/bash) till /bin/MySecureShell kan behörigheterna för användaren komma att påverkas efter inloggning i systemet!

I stället är det bättre (tycker jag) att skapa helt nya användarkonton bara för att användas av SFTP med MySecureShell. Nya användare skapas så här:

Kod: Markera allt

sudo useradd -m -s /bin/MySecureShell <användare>

Skapa lösenord för användaren:

Kod: Markera allt

sudo passwd <användare>

Vill man ha koll på vilka användare som kan köra sftp med MySecureShell:

Kod: Markera allt

sudo sftp-user list

Konfigurering

Konfigurering görs med en texteditor i filen /etc/ssh/sftp_config. Vi öppnar således denna:

Kod: Markera allt

gksudo gedit /etc/ssh/sftp_config

Filen är väldokumenterad och självförklarande med sina kommentarer, men det viktiga är att det som står mellan <Default> och </Default> är globala parametrar, som gäller för samtliga användare. Vill man göra avsteg från vissa av dessa för speciella användare görs det med att skapa taggar för användare, grupper eller ipnr serier och knyta användaren till dessa. Exempel på grupper och ipnr serier finns i senare delen av filen. Man kan även använda taggar för enskild användare, typ <User nisse> ....</User>.

Men börja med att köra med konfigurationsfilen som den är - med ett undantag - ändra raden LimitConnectionByUser 1 till LimitConnectionByUser 2 för undvika strul vid anslutningsförsöken. Först när allt fungerar med de globala parametrarna, kan det finnas behov att experimentera och finlira med de övriga taggarna!

Skriver man in en ny grupp i konfigurationsfilen måste den också skapas på maskinen.

Efter att ha ändrat i konfigurationsfilen startar vi om MySecureShell:

Kod: Markera allt

sudo /etc/init.d/mysecureshell restart

Övervakning

När vi väl fått allt att fungera finns det några bra kommandon att känna till:

Sftp-serverns status:

Kod: Markera allt

sudo sftp-state

Se vilka som är anslutna:

Kod: Markera allt

sudo sftp-who

Kasta ut användare:

Kod: Markera allt

sudo sftp-kill <användare>

Klienter

FileZilla, gftp och SCP kan användas för att köra SFTP.

Övrigt

- Handledningen (med de globala parametrarna) är verifierad på en Gutsy desktop maskin.
- Har man inte haft OpenSSH installerat tidigare rekommenderas några ändringar i konfigurationsfilen /etc/ssh/sshd_config för att stärka ssh säkerheten. Hur detta görs finns beskrivit på annan plats i forumet.
- Glöm inte att öppna i brandvägg/router för portforwarding av port 22 av inkommande trafik till maskinen!

[Mekaniserad Apelsin]

Är det inte en lösning som grundar sig på "chroot jailing"? Vilket utvecklarna utav chroot flertalet gånger uttalat sig väldigt negativa mot för att det inte fungerar eftersom chroot inte är gjord med den typen av säkerhet i åtanke?

Inte för att det gör det här till en dålig guide, ett chroot-jail är extremt svårt att bryta sig igenom, och antagligen helt acceptabelt som lösning när man har någorlunda kontroll över accessen.

[northface]

Före jag satte ihop guiden har jag naturligtvis kollat upp, men inte kunnat hitta något negativt om MySecureShell och dess säkerhet. Tvärtom om man ser till alternativet, som många här på forumet använder sig av - bara OpenSSH och en sftp-klient som exponerar hela filsystemet.

[andol]

Rätt övertygad om att MA:s invändning inte är specifikt mot MySecureshell utan snarare det generella konceptet att tillämpa chroot på sftp-inloggningar och liknande. Vad gäller tillgång till filsystemet i stort är det ju annars något man skyddar med vettiga filepermissions?

[Mekaniserad Apelsin]

Det är väl onödigt? Jag säger ju som du, chroot är bättre än inget chroot. Jag bara undrade hur säkerhetsläget var, speciellt md tanke på den diskussion som skedde när det tidigare diskuterades att ändra i chroot, men som inte gjordes pga posix-standarden.

Kort sagt: existerar inte ens en skruvmejsel, så är en hammare det bästa som finns för att dra i en skruv.

[KiviE]

Jag har ingen större koll men då de har lagt in chroot i OpenSSH så man när man loggar in med ssh bara kommer åt en del av filträdet och att apache2 är chrootat som standard i OpenBSD så känns det som om att chroot är väldigt bra, även om det inte är lika bra som att ha en egen dator för varje program man kör.

Tycker att howton är väldigt bra, ta inte bort den! Finns ingen anledning att göra det.

[andol]

Jag har ingen större koll men då de har lagt in chroot i OpenSSH så man när man loggar in med ssh bara kommer åt en del av filträdet

Sen när började OpenSSH skeppas med chroot-stöd?
Förvisso finns det patchar och tillägg, men inget som officiellt stöds.

och att apache2 är chrootat som standard i OpenBSD så känns det som om att chroot är väldigt bra, även om det inte är lika bra som att ha en egen dator för varje program man kör.

Det är en väldig skillnad på att chroota Apache, bind, etc i jämförelse med att chroota sftp. I det första fallet vill man skydda sig mot sårbarheter i demonen/applikationen medans man i det senare fallet försöker skydda sig mot en inloggad användare.

Fast om vi nu ska göra det lätt för oss och se OpenBSD som mallen för vad som är bra och säkert; hur kommer det sig då att OpenBSD inte som standard har stöd för att chroota SFTP-inloggningar?

Nu säger jag dock inte att det alltid skulle vara Fel att med chrootad SFTP. Poängen jag vill trycka på är dock att det inte nödvändigtvis är den silverkula som vissa verkar tro.

EDIT: Förövrigt så tycker även jag att HOWTOn ska vara kvar.

[KiviE]

Chrootet i OpenSSH är inte samma sak kanske iofs. http://it.slashdot.org/article.pl?sid=0 ... 9&from=rss


Som sagt jag är ingen höjdare på chroot Du har säkert helt rätt men är det egentligen någon nackdel med chroot? Säger inte heller att OpenBSD borde vara en måttstock, visste bara att de hade det så med apache...

[andol]

Chrootet i OpenSSH är inte samma sak kanske iofs. http://it.slashdot.org/article.pl?sid=0 ... 9&from=rss

Jomentitta, det hade jag faktiskt helt missat. Tack för upplysningen.

men är det egentligen någon nackdel med chroot?

Det beror lite på.

Först och främst så har vi själva chroot-fängelset. Är man inte helt säker på vad man sysslar med finns det helt klart potential för att skjuta sig själv i foten där. Ska man bara köra sftp så är det i och för sig inte överdrivet avancerat. Vill man däremot kunna göra roligare partytryck i sin chroot så ökar helt klart komplexiteten och därmed risken.

Sen så är alltid själva chroot-processen ett riskmoment. Måhända inte så mycket om det går direkt genom OpenSSH, som om man använder en (okänd) tredjepartsmodul som startas med root-rättigheter. Det finns helt enkelt ytterligare ett ställe det kan gå fel på.