SSH/SFTP jail question

Remember, security is more than just "can nasty people login and backdoor my system / use me to spam / use me to attack others".

Security is also about the files you store and serve up.

If your client uses a weak password that can be guessed and a hackers breaks in using it then that hacker would be able to modify your web files; maybe update the site so that it hosts trojans (which is very common use of compromised web servers). At the very least it could lead to the site being defaced.

However the risk evaluation (how likely is it to happen) is up to you to determine.

yep. it's always a risk, giving a client access to the server at all, but in the real world, it's got to be done sometimes. what i want to know is; if i manage to setup SSH so the client is jailed into her own directory eg. /var/www/herdomain.com, will that decrease the security of the rest of my server if [worst case scenario] someone guesses her password. ie. how strong are the walls on this SSH jail and how thick the bars?

if someone gets hold of her password and manages to wreck her site or mess with her files, that's bad, but as long as the rest of the server is still secure, i can live with that.

OK - here's were i'm getting stuck with setting up this user with SSH access. when i try and connect via SFTP with cyberduck, i get a 'login failed' error.

when i try to SSH into the user's account via a terminal it accepts the password but then drops the connection:

debug1: Next authentication method: password
clientname@xxx.xxx.xxx.xxx's password: 
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: channel 0: free: client-session, nchannels 1
Connection to xxx.xxx.xxx.xxx closed by remote host.
Connection to xxx.xxx.xxx.xxx closed.
Transferred: sent 1632, received 1800 bytes, in 0.0 seconds
Bytes per second: sent 491428.3, received 542016.5
debug1: Exit status -1

i'm stumped!

Wild Guess: You set up chrooting in SSH, but forgot to enable internal-sftp, and both the external sftp-server binary and the user's shell dies (or more precisely, can't start in first place) because there's no libraries nor device files inside the chroot?

@rsk:

…chrooting in SSH, but forgot to enable internal-sftp…

as per the tutorial, i've added:

Subsystem sftp internal-sftp

...

Match group filetransfer
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

to sshd_config. i presume that takes care of the enabling internal-sftp bit?

@rsk:

…the user's shell dies (or more precisely, can't start in first place) because there's no libraries nor device files inside the chroot?

ah! - now that sounds a distinct possibility. the tutorial chowns root:root the user's home directory, so they cannae create new files there and then sets them up a subdirectory within that home directory, to which they do have full access. i just used usermod -d to change my user's home directory to /var/www/theirdomain.com so, of course there is nothing in there, apart from their website files.

looks like i'll need to go back and do it the tutorial way but put a symbolic link inside their home directory, to their website directory. that should work [he said hopefully!]

hmmm… well, we seem to be advancing slowly here. after making the changes above, i no longer get the 'session closed by the remote host', when trying to ssh in. but the connection just hangs at the 'entering interactive session' stage:

debug1: Next authentication method: password
client@xxx.xxx.xxx.xxx's password: 
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.

.... hangs at this point.....

here is the listing of the user's home directory:

drwxr-xr-x 2 root    root    4096 2010-05-17 09:15 .
drwxr-xr-x 4 root    root    4096 2010-05-16 16:39 ..
-rw-r--r-- 1 client client  220 2010-05-16 16:39 .bash_logout
-rw-r--r-- 1 client client 3103 2010-05-16 16:39 .bashrc
-rw-r--r-- 1 client client  675 2010-05-16 16:39 .profile
lrwxrwxrwx 1 client client   25 2010-05-17 09:15 domain.com -> /var/www/domain.com

First, check out syslog and auth.log for clues. sshd writes there what happens on its end. Second, you may want to read http://www.minstrel.org.uk/papers/sftp/builtin/ in addition to the Library tutorial - for example, step 8 states clearly > Important (OpenSSH tests for this condition): ensure their home directory is owned by root, and is not writable by any other user or group. This must also be the case for each directory in the path up to the root of your system. . Anyway, with a chroot setup you WON'T be able to ssh in, only sftp in, and the ssh interactive session WILL hang because ForceCommand launces the sftp server even in this case (a bit like if you'd do "ssh user@host /usr/lib/ssh/sftp-server") which expects SFTP packets, not keyboard input. Can you SFTP in?

no. i cannae SFTP in. i just get a 'login failed' alert, asking me to re-enter the password.

there's nothing relevant written into /var/log/syslog.

/var/log/auth.log shows the following:

May 17 18:28:48 madraserver sshd[11372]: Connection from 75.101.185.99 port 33530
May 17 18:30:42 madraserver sshd[11378]: Connection from 173.45.245.239 port 40255
May 17 18:31:18 madraserver sshd[11385]: Connection from 75.101.185.99 port 33766
May 17 18:33:12 madraserver sshd[11391]: Connection from 173.45.245.239 port 43320

i'm not convinced that's relevant either, as none of those are the port i'm trying to connect on.

Run a debugging version of sshd on another port (eg 2222) using "sshd -d -p 2222" and then attempt to sftp to that ("-oPort=2222") and then you'll get lots of diagnostic data from sshd to see what's going on :-)

@madra:

May 17 18:28:48 madraserver sshd[11372]: Connection from 75.101.185.99 port 33530
May 17 18:30:42 madraserver sshd[11378]: Connection from 173.45.245.239 port 40255
May 17 18:31:18 madraserver sshd[11385]: Connection from 75.101.185.99 port 33766
May 17 18:33:12 madraserver sshd[11391]: Connection from 173.45.245.239 port 43320

i'm not convinced that's relevant either, as none of those are the port i'm trying to connect on.

Don't worry about that, it's the port the client uses (computer that runs the client) to connect to your server.

OK. here's what i get in auth.log, when i run sshd in debug mode:

May 20 21:17:48 madraserver sshd[30298]: debug1: do_cleanup
May 20 21:18:06 madraserver sshd[30256]: debug1: Forked child 30302.
May 20 21:18:06 madraserver sshd[30302]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
May 20 21:18:06 madraserver sshd[30302]: debug1: inetd sockets after dupping: 3, 3
May 20 21:18:06 madraserver sshd[30302]: Connection from 75.101.185.99 port 60910
May 20 21:18:06 madraserver sshd[30302]: debug1: Client protocol version 2.0; client software version libssh2_1.2.4
May 20 21:18:06 madraserver sshd[30302]: debug1: no match: libssh2_1.2.4
May 20 21:18:06 madraserver sshd[30302]: debug1: Enabling compatibility mode for protocol 2.0
May 20 21:18:06 madraserver sshd[30302]: debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu3
May 20 21:18:07 madraserver sshd[30302]: debug1: do_cleanup

does that shed any light on proceedings?

Alternatively you can use the scponly package. It comes with two additional shells: scponly and scponlyc, the latter for chrooted logins. It also has a setup_chroot script to create users with chrooted environment.