0

I tried to setup a chroot jail for a user account I specifically setup for ssh.

I set it up and it seemed to work fine yesterday but today it is not working. It doesn't seem to be an SSH issue since I can SSH in with other user account just fine. Here is the verbose ssh plus the error I am getting

OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: /etc/ssh/ssh_config line 102: Applying options for *
debug1: Connecting to 130.191.240.69 [130.191.240.69] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/client/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/client/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/client/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/client/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/client/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/client/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/client/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/client/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to 130.191.240.69:22 as 'jaileduser'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:I7TPrpH1RDXr2pnfVc8xpjHiZ9okuzsIJkAm4dBOHHI
debug1: Host '130.191.240.69' is known and matches the RSA host key.
debug1: Found key in /Users/client/.ssh/known_hosts:2
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/client/.ssh/id_rsa
debug1: Trying private key: /Users/client/.ssh/id_dsa
debug1: Trying private key: /Users/client/.ssh/id_ecdsa
debug1: Trying private key: /Users/client/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 130.191.240.69 ([130.191.240.69]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: channel 0: free: client-session, nchannels 1
Connection to 130.191.240.69 closed by remote host.
Connection to 130.191.240.69 closed.
Transferred: sent 2840, received 2344 bytes, in 0.5 seconds
Bytes per second: sent 6236.2, received 5147.1
debug1: Exit status -1

As far as I can tell I am able to connect then immediately have the connection closed. I suspect it might be something missing within the chroot jail but I haven't been able to figure it out. Any help would be greatly appreciated

Commenting out the ChrootDirectory command will let the user loose and allow connection but the permission are correct in line with the linked fix so I don't believe that is the problem. I also do not have that error in my output.

I thought I should also add output for /usr/sbin/sshd -d hopefully that adds more useful info

/usr/sbin/sshd -d
debug1: sshd version OpenSSH_5.2p1
Could not load host key: /etc/ssh_host_rsa_key
Could not load host key: /etc/ssh_host_dsa_key
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Permission denied.
debug1: Bind to port 22 on ::.
Bind to port 22 on :: failed: Permission denied.
Cannot bind any address.
2

2 Answers 2

1

Chrooting your SSH connection jails everything, including the shell you're trying to start. So first of all, /bin/bash (or /bin/zsh or whatever shell you prefer) needs to exist. Secondly, all libraries required to run the shell must be present as well.

To provide all the needed files you need to add some bind mounts to your chroot directory. Which exactly these are may vary from distribution to distribution, but usually these are at least:

  • /bin
  • /lib (or /lib64, maybe even both)
  • /usr/lib (/usr/lib64)

You may also want to provide /usr/bin.

Note: Although you need /usr/lib and possibly /usr/bin, you usually do NOT need /usr itself. Just create an empty directory and place the two needed subdirectories inside.

To create the bind mount for /bin, create the folder /chrootdir/bin (replace /chrootdir with your actual location) and then mount using

mount -o bind /bin /chrootdir/bin

Do so for any other needed directory as well.

On a side note: your sshd debugging attempt failed because the daemon couldn't bind to port 22. You can see that from the message. I assume you didn't start it with root privileges.

5
  • The sshd debugging was run as root. I didn't use the mount command for the chroot jail the way you have suggested. I did however copy over all the necessary components to run bash and the few commands I wanted the jailed user to have. Which included bash and scp. I was able to successfully use scp to copy a folder yesterday so I am a little stumped as to why things changed.
    – yz426f
    Feb 11, 2016 at 23:51
  • @yz426f But as you can see, it still couldn't bind to port 22. I don't think it was still in use because then the message would probably be different. But whatever reason it was, the sshd didn't even start. Feb 11, 2016 at 23:54
  • In that case you should have a look at your system log. Maybe there is some clue in it. Assuming you are using systemd, run sudo journalctl -f and try the SSH login again. Feb 12, 2016 at 0:10
  • So I should add that I am using MacOSx here which may also be part of the problem. It does not have journalctl. I think I may be a little closer though with your help. I now have from the /var/log/secure.log: Feb 11 16:24:37 MacPro sshd[1711]: fatal: bad ownership or modes for chroot directory "/Users/jaileduser/jail"
    – yz426f
    Feb 12, 2016 at 0:25
  • However, I am looking in the jailed directory and all the ownerships say they are to root and group wheel
    – yz426f
    Feb 12, 2016 at 0:32
0

So I found the solution to my problem it was quite a foolish oversight:

sudo chmod 755 /Users/jaileduser/jail/

I had set these permission yesterday and somehow they were modified and I am unclear on how that happened but regardless I got ssh jaileduser working.

Many thanks to those that attempted to help

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .