Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

A user requires shell access to an Ubuntu server from the WAN side. There are many shell accounts with simple passwords. So shell port (port 22) is blocked in the firewall. For my WAN side user I am planning to run a ssh server in a Debian chroot, and open its port in the firewall. If this kind of setup is feasible, what is the best way of achieving it?

share|improve this question
add comment

1 Answer

up vote 5 down vote accepted

Single ssh server

If the only reason you're planning to run an SSH server in a chroot is to restrict password authentication to some users, you don't need that: you can tell sshd to allow passwords only for a whitelist of users. In /etc/ssh/sshd_config, use a Match directive:

PasswordAuthentication No
Match User trusted_user_1,trusted_user_2
    PasswordAuthentication yes

If you do want to chroot some users, you can still run a single ssh daemon, and use a ChrootDirectory directive in sshd_config (within the scope of a Match directive).

Two ssh servers, listening on different addresses

You can have two ssh daemons listening on the same port, if they're listening on different addresses. Put a ListenAddress directive in each /etc/ssh/sshd_config, each with the IP address(es) you want that server to listen on (listen on, not listen to, i.e. these are addresses of your server's network interfaces). This is of limited applicability, only if your server machine is the node doing the LAN/WAN filtering. It also means that things like ssh localhost won't be transparent (you can still access the daemon that's not listening on localhost with ssh -b).

Two ssh servers, listening on different ports

You can make the ssh daemon in the chroot listen on a different port, with the Port directive in /etc/ssh/sshd_config. Keep blocking port 22 from outside on your firewall and don't block the other port you selected for the chroot sshd.

Two ssh servers, routing performed by the firewall

If you have two daemons listening on different ports (as above), you can still give the illusion that they're both listening on port 22. For example make the chrooted ssh daemon listen on port 2201, and redirect traffic coming on port 22 on eth1 to port 2201:

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 22 -j REDIRECT --to-ports 2201

Then ssh connections from localhost or over eth0 to port 22 will reach the non-chrooted server, while ssh connections over eth1 to port 22 will reach the chrooted server. Connections on port 2201 will reach the chrooted server. You can use other criteria than -i eth, for example ! -s 10.1.0.0/16 ! -s 127.0.0.0/8 to match everything with a source address other than 10.1.x.y or loopback.

share|improve this answer
    
Is it possible to specify in sshd_conf which users can login through an interface? For example, eventhough I have hundereds of shell users, only one user is allow to login via the WAN interface. –  nixnotwin Jul 12 '11 at 0:44
    
@nixnotwin No, any user can log in on any interface that sshd is listening on. With a single sshd, you can mainly tune the permitted authentication methods for each user. To restrict an interface to some users, run a second sshd listening on a different port (which can be seen on port 22 from the outside as per the last section of my answer). –  Gilles Jul 12 '11 at 6:42
    
I'm successfully running a second sshd on chroot. I can log into it from a WAN side too. But one issue is when I do ifconfig -a on chroot distro, it shows the interfaces of the host OS (Ubuntu Server). Even I can assign ip address from the chroot os via the ifconfig tool. Top command also shows processes of the host OS. –  nixnotwin Jul 12 '11 at 7:38
    
@nixnotwin That's the normal behavior for a chroot. It only provides filesystem containment (and only for non-root processes, and only if the administrator hasn't introduced any leak in the chroot). If you want more containment, you need a real virtualization technology; LXC provides network and process containment on any recent Linux kernel. –  Gilles Jul 12 '11 at 8:54
add comment

Your Answer

 
discard

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.