[Mini Howto] Chroot SFTP met Public/Private Keys

[Stacheldraht]

Ik had weer eens zin in het schrijven van een mini howto. Misschien hebben jullie er iets aan Btw ik heb dit getest met behulp van Debian Lenny.

Chroot SFTP met Public/Private Keys Howto:

Een kleine howto hoe je sftp users kan chrooten. Let op, let op: maak beslist geen enkele fout met het instellen van permissies anders gaat het onderstaande niet werken ;-)

Op de server /etc/sshd/sshd_config zo aanpassen:

code:

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem       sftp    internal-sftp

Match Group sftpusr
ForceCommand internal-sftp
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no

Daarna sshd restarten:

server1:/home/jdoe/.ssh# invoke-rc.d ssh restart
Restarting OpenBSD Secure Shell server: sshd.

Daarna een sftp groep aanmaken:

server1:~# addgroup sftpusr
Adding group `sftpusr' (GID 1001) ...
Done.

En natuurlijk de user die we willen chrooten:

server1:/home# adduser --disabled-password --shell /bin/false --gecos "John Doe" --uid 920677 jdoe
Adding user `jdoe' ...
Adding new group `jdoe' (920677) ...
Adding new user `jdoe' (920677) with group `jdoe' ...
Creating home directory `/home/jdoe' ...
Copying files from `/etc/skel' ...

Deze user voegen we aan de chroot groep toe:

server1:/home/jdoe/.ssh# adduser jdoe sftpusr
Adding user `jdoe' to group `sftpusr' ...
Adding user jdoe to group sftpusr
Done.

Daarna passen we de homedir van de te chrooten user aan:

server1:/home# chown root:root jdoe
server1:/home/jdoe# mkdir uploads
server1:/home/jdoe# chown jdoe:jdoe uploads
server1:/home/jdoe# mkdir .ssh
server1:/home/jdoe# chmod 0700 .ssh
server1:/home/jdoe# chown jdoe:jdoe .ssh
server1:/home/jdoe# touch .ssh/authorized_keys
server1:/home/jdoe# chmod 0600 .ssh/authorized_keys 
server1:/home/jdoe# chown jdoe:jdoe .ssh/authorized_keys

Juiste key uploaden en klaar Kijk maar:

jdoe@desktop1:~/.ssh$ sftp -o IdentityFile=~/.ssh/testkey_rsa jdoe@server1
Connecting to server...
sftp> ls
uploads   
sftp> cd ..
sftp> pwd
Remote working directory: /
sftp> ls -al
drwxr-xr-x    4 0        0              31 Aug 28 12:13 .
drwxr-xr-x    4 0        0              31 Aug 28 12:13 ..
drwx------    2 920677   920677         28 Aug 28 11:26 .ssh
drwxr-xr-x    2 920677   920677          6 Aug 28 12:16 uploads
sftp> cd ../../
sftp> pwd
Remote working directory: /
sftp> ls -al
drwxr-xr-x    4 0        0              31 Aug 28 12:13 .
drwxr-xr-x    4 0        0              31 Aug 28 12:13 ..
drwx------    2 920677   920677         28 Aug 28 11:26 .ssh
drwxr-xr-x    2 920677   920677          6 Aug 28 12:16 uploads
sftp> 

[ Voor 2% gewijzigd door een moderator op 01-09-2009 22:52 . Reden: leesbaar gemaakt :) ]

[mithras]

Nice

Ik was hier al wat naar opzoek, maar wegens gebrek aan een goed stappenplan heb ik het nooit doorgezet. Maar misschien is het wel handig om dit in een leesbaar formaat te zetten

[Stacheldraht]

mithras schreef op vrijdag 28 augustus 2009 @ 15:55:
Nice
Maar misschien is het wel handig om dit in een leesbaar formaat te zetten

Ga je gang

[gertvdijk]

Zijn er nog aanpassingen nodig voor picky SFTP clients als Filezilla en vooral WinSCP? Die willen perse een /etc/groups file en een /bin/group en een /dev/null etcetera...
Daarvoor was er dan een setup_chroot.sh shellscript in Etch, die dan enkele dingen deed, en zelf moest je nog wat mknodden en cp'en...

Verder is het goed om te melden dat dit pas werkt vanaf Debian Lenny, vanwege de versie van OpenSSH die dat chrooten pas ondersteunt vanaf de versie die in Lenny zit. Of, dat je dus OpenSSH 4.8p1 of hoger nodig hebt.

Verder... is het misschien handiger om de chroot directory op te geven als de homedir in plaats van het billige '/home/%u' dus %h.

[ Voor 15% gewijzigd door gertvdijk op 28-08-2009 16:30 ]

[Stacheldraht]

gertvdijk schreef op vrijdag 28 augustus 2009 @ 16:27:
Zijn er nog aanpassingen nodig voor picky SFTP clients als Filezilla en vooral WinSCP? Die willen perse een /etc/groups file en een /bin/group en een /dev/null etcetera...
Daarvoor was er dan een setup_chroot.sh shellscript in Etch, die dan enkele dingen deed, en zelf moest je nog wat mknodden en cp'en...

Nee dat is niet nodig. Wel als je een chroot ssh omgeving wilt.

Verder is het goed om te melden dat dit pas werkt vanaf Debian Lenny, vanwege de versie van OpenSSH die dat chrooten pas ondersteunt vanaf de versie die in Lenny zit. Of, dat je dus OpenSSH 4.8p1 of hoger nodig hebt.

Het staat bovenaan mijn post dat dit stukje is geschreven met behulp van Debian Lenny.

Verder... is het misschien handiger om de chroot directory op te geven als de homedir in plaats van het billige '/home/%u' dus %h.

Waarom?

[gertvdijk]

Stacheldraht schreef op vrijdag 28 augustus 2009 @ 16:44:
Waarom?

Omdat niet elke user een homedir in /home heeft misschien? Denk aan mass virtualhost omgevingen of wat minder-standaard gevallen.

%h is algemener en werkt altijd.

[ Voor 6% gewijzigd door gertvdijk op 28-08-2009 17:00 ]

[Stacheldraht]

@gert Tsja, ik heb een mini howto geschreven om de mensen op weg te helpen, elk denkbaar scenario staat niet beschreven. Ik houd het zelf altijd bij %u maar mochten mensen %h willen gebruiken dan moeten ze dat zeker doen.

[Anoniem: 147417]

Just on a sidenote:

mocht je dit op Solaris 10 willen doen, dan moet je de standaard sshd disabelen en een versie > 4.8 installeren.

edit: beetje wat GertvDijk ook zal zegt dus

[ Voor 17% gewijzigd door Anoniem: 147417 op 01-09-2009 22:01 ]

[Pim.]

Stacheldraht schreef op vrijdag 28 augustus 2009 @ 16:25:
[...]


Ga je gang

OK


Goed initiatief trouwens, ik zal em opnemen in de FAQ als ik achter een betere lijn zit

[ Voor 23% gewijzigd door Pim. op 01-09-2009 22:33 ]

[Stacheldraht]

Thx Pim de howto is nu wat duidelijker. Als jullie het leuk vinden zal ik nog meer van dit soort mini-howto's posten

[Pim.]

Ik ben er helemaal voor, dit soort dingen zijn imo de backbone van GoT. Dit zijn de hits in google waar mensen ook wat aan hebben.

Ik kan er zelfs een aparte sectie voor maken in de FAQ als het er een paar zijn

[silentsnake]

Toevallig heb ik dit ook vandaag gedaan, alleen heb ik in mijn situatie een AD eraan hangen met 200 accounts. Daarbij gebruiken we pam_mkhomedir om de home folders aan te maken aangezien er regelmatig nieuwe users bijkomen. Probleem is alleen dat in deze setup de homefolder geowned moet worden door root, wat pam_mkhomedir dus niet doet (die maakt, terecht, de user de owner van de homefolder). Ik heb uiteindelijk maar in de source code lopen hacken om de permissies goed te krijgen, wat wel gelukt is, maar niet eenvoudig was voor iemand die nog nooit wat met C gedaan heeft. Het is ook een gore hack, maar het werkt.

[WHiZZi]

Ik ben recentelijk bezig geweest om een LDAP/Samba/NFS server te bouwen en ook de bijbehorende stappen om Ubuntu, CentOS en Windows (7) in te laten loggen op dit "domein" en vervolgens de fileserver te kunnen gebruiken.

Ik wil hier ook best een howto van maken voor hier hoor (als daar behoefte aan is). Ik heb hem eigenlijk al gemaakt dus effe copy/pasten voor hier en is klaar.

Goed initiatief trouwens, een paar goede duidelijke howtos

[ Voor 3% gewijzigd door WHiZZi op 02-09-2009 00:15 ]

[Manuel]

Handig topic inderdaad! Misschien wel een idee: "Het grote 'how to' topic". Heb thuis nog een leuke Debian draaien en was toch wat aan het proberen. Verder op de productie server draai ik op CentOS, eens zien of dit ook ongeveer daar betrekking op heeft.

[Pim.]

Ik ben per definitie niet voor "grote" topic aangezien er bijna nooit meer iets terug te vinden is uit zo'n topic. Als mensen een leuke how to maken en die hier plaatsen dan gooi ik ze wel in de NOS FAQ en dan hebben we er meer plezier van denk ik

Ook deze opgenomen

[mithras]

Toch even een kickje Het volgen van de howto is niet zo moeilijk, maar inloggen wil nog niet lukken met de key:

$ sftp -o IdentityFile=~/Desktop/ssh user@domain
Connecting to domain...
user@domain's password:
[...]
Permission denied (publickey,password).

Ik dus: password Wat gaat hier fout, iemand een idee?

[gertvdijk]

mithras schreef op woensdag 02 december 2009 @ 13:38:
Wat gaat hier fout, iemand een idee?

Post de logs (/var/log/auth.log) van de server. Daar staat waarschijnlijk zowel oorzaak als oplossing.

[ Voor 11% gewijzigd door gertvdijk op 02-12-2009 13:54 ]

[Stacheldraht]

1 tip: je moet heel goed opletten of de rechten goed staan 1 klein foutje en de boel werkt niet meer!!!

[mithras]

gertvdijk schreef op woensdag 02 december 2009 @ 13:54:
[...]

Post de logs (/var/log/auth.log) van de server. Daar staat waarschijnlijk zowel oorzaak als oplossing.

Dat had ik nog niet gedaan. Maar er staat voor de desbetreffende inlogpoging ook niet zo heel veel in:

Dec  2 15:21:06 karlijn sshd[7724]: Failed password for user from ip.ad.re.ss port 62145 ssh2
Dec  2 15:21:06 karlijn sshd[7724]: Failed password for user from ip.ad.re.ss port 62145 ssh2
Dec  2 15:21:07 karlijn sshd[7724]: Failed password for user from ip.ad.re.ss port 62145 ssh2

Stacheldraht schreef op woensdag 02 december 2009 @ 14:31:
1 tip: je moet heel goed opletten of de rechten goed staan 1 klein foutje en de boel werkt niet meer!!!

Ik heb dat ook gechecked en het moet 100% in orde zijn. Ik gok dat het mis gaat bij de key overbrengen. Ik log in (IdentityFile bij sftp) met de private key. De pub part van de key heb ik in het bestandje .ssh/authorized_keys gezet. Dit klopt toch? Keys zijn afkomstig van ssh-keygen.

[gertvdijk]

mithras schreef op woensdag 02 december 2009 @ 15:26:
Maar er staat voor de desbetreffende inlogpoging ook niet zo heel veel in:

Dec  2 15:21:06 karlijn sshd\[7724]: Failed password for user from ip.ad.re.ss port 62145 ssh2
Dec  2 15:21:06 karlijn sshd\[7724]: Failed password for user from ip.ad.re.ss port 62145 ssh2
Dec  2 15:21:07 karlijn sshd\[7724]: Failed password for user from ip.ad.re.ss port 62145 ssh2

Weet je zeker dat dat alles is? Heb je key auth überhaupt aanstaan (op server: sshd_config)? Werkt de key auth met standaard SSH login wel op een niet-chrooted accountje? Heeft de user überhaupt toegang via SSHD (AllowUser lijstje die je gebruikt misschien)? En wat zegt je SSH client over de gebruikte auth methods aangeboden door de server:

ssh -i ~/.ssh/id_rsa -v user@host

Met de -v optie zie je wat er gebeurt op de client kant.

mithras schreef op woensdag 02 december 2009 @ 15:26:
Ik log in (IdentityFile bij sftp) met de private key. De pub part van de key heb ik in het bestandje .ssh/authorized_keys gezet. Dit klopt toch? Keys zijn afkomstig van ssh-keygen.

Dat is goed in elk geval; dat deel snap je.

[ Voor 3% gewijzigd door gertvdijk op 02-12-2009 16:50 ]

[mithras]

Goed idee om even verbose ssh te proberen. Nog steeds snap ik het niet, maar voila:

$ ssh -i /home/jurian/Desktop/ssh -v [e-mail]
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007                       
debug1: Reading configuration data /home/jurian/.ssh/config                     
debug1: Reading configuration data /etc/ssh/ssh_config                          
debug1: Applying options for *                                                  
debug1: Connecting to home.juriansluiman.nl [145.94.57.226] port 22.            
debug1: Connection established.                                                 
debug1: identity file /home/jurian/Desktop/ssh type 1                           
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-6ubuntu2
debug1: match: OpenSSH_5.1p1 Debian-6ubuntu2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'home.juriansluiman.nl' is known and matches the RSA host key.
debug1: Found key in /home/jurian/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/jurian/Desktop/ssh
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
[e-mail]'s password:

Het gaat dus wél goed met de key, maar ik moet alsnog een password invoeren? Ik weet zeker (net nog een extra key gemaakt) waar geen passphrase aan vastzit namelijk

[Stacheldraht]

Met mijn howto kan je niet met SSH inloggen alleen middels SFTP.