1. Install The Chrooted OpenSSH

First we install some prerequisites:

Then we download the patched OpenSSH sources, and we configure them with/usras directory for the SSH executable files, with/etc/sshas the directory where the chrooted SSH will look for configuration files, and we also allow PAM authentication:

2. Create The Chroot Environment

Next I create a chroot environment under/home/chroot. This is the directory that all chrooted SSH users will get jailed in, i.e. they will not be able to see any files/directories outside/home/chroot.

I have to create some directories in/home/chroot, and I have to copy a few binaries like/bin/bash,/bin/ls, etc. as well as the libraries on which these binaries depend into the chroot environment so that they are available to any chrooted user.

Now that we have created the necessary directories, we are going to copy some binaries and all the libraries on which they depend into the chroot environment. This is an excerpt of a script that I found on http://mail.incredimail.com/howto/openssh/create_chroot_env that does this. I’ve modified it a little bit:

(If you want to make more programs available to your chrooted users, just add these programs to the APPS line.)

Now we make the script executable and run it:

Next we have to copy a few additional files and libraries to the chroot jail:

Then we do this:

You should also copy the line of the group in which you will create new users from/etc/groupto/home/chroot/etc/group. In this tutorial we will create users in the group users, so we do this:

and restart OpenSSH:

3. Create A Chrooted User

Even with the chrooted SSH that we have just installed you can log in without being chrooted (which makes sense if you log in as root, for example). Now, how does the chrooted SSH decide whom to chroot and whom not? That’s easy: the chrooted SSH looks up the user who is trying to log in in/etc/passwd. If the user’s home directory in/etc/passwdhas a . (dot) in it, then the user is going to be chrooted.

This user will not be chrooted.

This user will be chrooted.

Now we create the user testuser with the home directory/home/chroot/./home/testuserand the group users (which is the default group for users on Debian so you do not have to specify it explicitly):

Then we give testuser a password:

Finally, we have to copy the line for testuser in/etc/passwdto/home/chroot/etc/passwd:

We have already copied the users group line from/etc/groupto/home/chroot/etc/groupso we do not have to do this here again. If you create a chrooted user in another group than users, add this group to/home/chroot/etc/group:

Now try to log in to SSH or SFTP as testuser. You should be chrooted and not be able to browse files/directories outside/home/chroot.

Cargar el módulo fuse (lsmod | grep fuse)

Agregar el usuario user al grupo fuse y cambiar el grupo a/dev/fuse

Finalmente, montar el directorio remoto

Para desmontar

La idea es abrir un puerto en el gateway (por encima del 1023) y redireccionar todas las conexiones entrantes al puerto 80 de nuestra máquina interna, que es donde está escuchando nuestro servidor web. Para ello crearemos un túnel SSH entre el gateway y nuestra máquina:

Este comando debemos ejecutarlo desde el gateway, ya que estamos usando la opción-L(local).

La opción -g (que equivale a ‘GatewayPorts yes’ en~/.ssh/configo/etc/ssh/ssh_config) es muy importante, ya que sin ella el túnel sólo estaría disponible para conexiones desde localhost y nosotros queremos que cualquier persona en Internet pueda acceder a nuestro servidor web.

Para comprobar esto basta con ejecutar:

Deberíamos ver una línea como la siguiente:

Lo que nos indica que el puerto 10080 está escuchando conexiones provenientes desde cualquier dirección y no sólo desde 127.0.0.1.

Por último, la opción-Nle indica a SSH que luego de crear el túnel no nos devuelva el prompt del shell.

Listo. Sólo basta abrir un navegador e ingresar:

A common use of SSH is port forwarding (tunneling). This use causes traffic directed to a particular port to be sent to a specified port on another computer. Because traffic is sent through SSH, the traffic is encrypted, allowing the transmission of sensitive data through arbitrary services.

Example: Tunneling Connections From a Local Host on Port 8080 to Port 80 on a Web Server

The following command is an example that would tunnel connections from a local host on port 8080 to port 80 on the web server www.my-domain.com:

ssh -N -L 8080:localhost:80 www.my-domain.com

In the preceding command:

* The

switch prevents the creation of an interactive SSH session.
* The

switch accepts an argument of the form port:host:hostport, indicating that the local port is to be forwarded to hostport on the destination host. Therefore, the argument localhost is relative to www.my-domain.com, not to the machine at which you enter the command.

Example: Accessing a Corporate Network Web Server That Allows Logins Through a Proxy Server

It follows that one could create a sequence of secure tunnels, linking one computer to another through intermediate computers. The most likely use for this scenario would be to enter a private network that requires external logins to be performed through a proxy server.

Suppose you wanted to access a web server in a corporate network that allowed logins through a proxy server. This could be done in two steps:

1. Log in to the proxy server using SSH, while simultaneously creating a tunnel. Use the following command:

ssh -l proxyuser -L 8080:localhost:8181 proxy.my-domain.com

This command logs the user proxyuser into proxy.my-domain.com, as well as forwards access to localhost’s port 8080 to 8181 on the proxy server. (Note that the port on the proxy server should not interfere with other users’ tunnels. The administrator of the proxy server should assign ports to users that can be used in this manner.)

2. Once logged in, create a second tunnel from the proxy server to the internal server:

ssh -l internaluser -L 8181:internalserver:80 internalserver

However, SSH can be used to run arbitrary commands on a remote machine. This capability allows you to create the tunnel in one step, with a single command line:

ssh -t -l proxyuser -L 8080:localhost:8181 proxy.my-domain.com \

ssh -l internaluser -L 8181:internalserver:80 internalserver

The

switch forces pseudo-tty allocation, which is necessary to run the SSH instance on the proxy server.

After you run the command, a user has a login session on the internal machine, and local port 8080 is forwarded to port 80 on the internal machine. When the user logs out of the internal machine, the port forwarding stops.

A Practical Application: Allowing Remote Access to the Perforce Master Source Repository

An example of a practical application of this technique comes from a solution I created for a client. Software developers using the Perforce source-code management system wanted remote access to the master source repository. Their corporate firewall software did not support Linux-based VPNs. For those developers using laptops or developers whose ISPs did not provide static IP addresses, access could not be provided through the firewall based on IPs.

To allow remote use of Perforce under these restrictions, I decided to tunnel the connections.

To create a tunnel for Perforce through SSH, clients run the following command, entering pass phrases or passwords as prompted:

ssh -P -t -l proxyuser -L 1616:localhost:2468 proxy.my-domain.com \

ssh -l internaluser -L 2468:internalserver:1616 internalserver

The

switch causes SSH to use a non-privileged port for outgoing connections, which may be required for some firewalls, as it was for this client. In the command above, 1616 is the standard Perforce port, and 2468 is an arbitrarily selected port, allocated for a particular user on the proxy server. (Each user had two unprivileged ports assigned for the user’s own use.) By having the local port set to 1616, Perforce clients worked with no configuration changes, as though a Perforce server were running locally.

Conclusion

SSH tunneling through a proxy server can be done quickly and simply using a single command line, providing transparent, secure access to network services.

Note

sshd must allow port forwarding for this technique to work. If this capability is not allowed by default, the parameter AllowTcpForwarding must be set to yes in the sshd configuration file.

About the Author

Terry Labach has been a system administrator since the last century, supporting the Solaris OS and other versions of UNIX. He holds university degrees in Physics and Computer Science.

http://www.sun.com/bigadmin/content/submitted/ssh_port_fwd.html