Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to setup a remote-only user account on my MacBook Pro that is chrooted to /chroot/tmux. I've followed the steps outlined here (, but when I try to login in with (on my local network):

ssh tmux@

... I get an immediate connection closed:

❯ ssh tmux@                                                                                                        
Connection to closed by remote host.
Connection to closed.

Removing this line in /etc/sshd_config allows me to login fine, but my tmux user is no longer chrooted:

Match User tmux
  # ...
  ChrootDirectory /chroot/tmux # removing this allows me to login

What do I have to do to get this to work?

This is what I get after the password prompt when I try to login from the client with ssh -vv tmux@

debug2: input_userauth_info_req 
debug2: input_userauth_info_req: num_prompts 0 
debug1: Authentication succeeded (keyboard-interactive). 
Authenticated to ([]:22). 
debug1: channel 0: new [client-session] 
debug2: channel 0: send open 
debug1: Requesting 
debug1: Entering interactive session. 
debug1: channel 0: free: client-session, nchannels 1 
Connection to closed by remote host.
Connection to closed.
Transferred: sent 1872, received 1880 bytes, in 0.0 seconds
Bytes per second: sent 100689.1, received 101119.4
debug1: Exit status -1

Encouragingly, Mac's Console reports this:

6/15/12 9:57:42.679 AM sshd: fatal: bad ownership or modes for chroot directory "/chroot/tmux"

My current directory permissions:

~ ❯ ls -al /chroot/tmux                                                                                                                      
total 8
drwxr-xr-x  7 tmux  wheel  238 Jun 14 11:18 .
drwxr-xr-x  3 root  wheel  102 Jun 14 10:34 ..
share|improve this question
Those instructions you are looking at are for an SFTP connection only, but you appear to be trying to connect with SSH. Are you expecting to get a chroot shell? – Zoredache Jun 14 '12 at 19:52
Yeah, want a chrooted shell. I couldn't find any article detailing how to get that, and the SFTP one seemed to closest fit. – neezer Jun 14 '12 at 21:06
Can you try adding "-vv" to your ssh login session on the client? Also check Console on the Mac to see what the SSH server says about it. – JamesHannah Jun 15 '12 at 13:07
@JamesHannah Console app seems to give me the cause here, which seems to be a permissions issue. Should I have them set to something other than what was outlined in the article mentioned in my post? – neezer Jun 15 '12 at 17:00
@neezer the SSH manpage is very specific about this: "All components of the pathname [provided to ChrootDirectory] must be root-owned directories that are not writable by any other user or group. – JamesHannah Jun 19 '12 at 11:00

The problem here is the ownership and permissions on the directory /chroot/tmux.

The SSHD manpage states:


         Specifies the pathname of a directory to chroot(2) to after
         authentication.  All components of the pathname must be root-
         owned directories that are not writable by any other user or
         group.  After the chroot, sshd(8) changes the working directory
         to the user's home directory.

I believe the specific path given to ChrootDirectory (in your case /home/tmux) must be root:root and at most 755 permissions, it looks like your directory is owned by 'tmux'.

Also note however, the ChrootDirectory command works best with SFTP, which doesn't require a specific shell, if you're trying to run interactive SSH command-line sessions (and a shell) from this directory, you'll need to add some files to the chroot first, as described in the sshd_config manpage:

The ChrootDirectory must contain the necessary files and directo-ries to support the user's session. For an interactive session this requires at least a shell, typically sh(1), and basic /dev nodes such as null(4), zero(4), stdin(4), stdout(4), stderr(4), arandom(4) and tty(4) devices. For file transfer sessions using ``sftp'', no additional configuration of the environment is nec-essary if the in-process sftp server is used, though sessions which use logging do require /dev/log inside the chroot directory (see sftp-server(8) for details).

share|improve this answer
Yeah, I was playing with this the other day. What I'm ultimately after is to create an SSH bridge from some other computer on my network through my computer to a Vagrant VM hosted on my computer. What I've done up until now is provided shell access into my machine so they can then run SSH from within that into Vagrant. (so a SFTP setup doesn't really solve my issue). I've tried setting up the files and directories, but I keep getting errors about ttys005... so that's where I'm at currently. Any thoughts? – neezer Jun 19 '12 at 22:35
So you're just trying to do a sort of port forward? SSH has options for that if you are, and you can configure it so that port forwarding's the only thing that can be done. – JamesHannah Jun 20 '12 at 15:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.