<p>SPANISH: Puede que a veces podamos necesitar crear un t&uacute;nel y dejarlo funcionando como si se tratase de un servicio cualquiera, pero por defecto, el cliente de 'ssh' no se lanza correctamente usando el m&eacute;todo com&uacute;n de usar '&amp;' y tampoco se lanza correctamente cuando lo colocas en un script de systemvinit/upstart. En estos casos, podemos usar estas opciones para lanzarlo: '-f -N' Se recomienda el uso de autenticaci&oacute;n por certificados, ya que de otra manera nos pedir&iacute;a el password y no ser&iacute;a muy &uacute;til :P Concretamente, el ejemplo que expongo lo he usado esto para hacer un mapeo de puertos desde un VirtualBox (hierro) y una VM alojada y conectada en &eacute;l por NAT :] Esta conexi&oacute;n se hac&iacute;a desde la VM al hierro.</p> <p>ENGLISH: Sometimes we may need create a tunnel and leave it running in background as if it were any other service, but 'ssh' client by default does not forks into background well using the common '&amp;' and it is not forked neither when you try to launch it via systemvinit/upstart script. In these cases, we can use this arguments to launch it into background: '-f -N'. It is recommended to use certs to authenticate with the foreign host, since in other way, it will prompt us for password and wouldn't be too useful as service :P I have used this to setup a NAT port forwarding between a VirtualBox host and a VM :]</p>

Para navegar, usar el correo o cualquier otra aplicación con la que necesitemos conectar de forma segura desde una red insegura (WIFI público, red de tu primo el mafioso, etc...), sin tener que configurar una VPN, solo necesitamos acceso remoto a un ordenador (de nuestra confianza) por SSH. Usando la (muchas veces desconocida) opción -D, podremos abrir localmente un servidor SOCKS (soporta SOCKS4 y SOCKS5) seguro en el puerto que se le indique. Así podremos usar la conexión SSH a modo de túnel privado. Para aplicaciones que no dispongan de configuración proxy, podemos utilizar tsocks.

Muchas veces nos encontramos entrando varias veces a un mismo servidor por ssh y por cada conexión hay que escribir de nuevo la contraseña y esperar el método de autenticación. OpenSSH proporciona un método mediante el cual no hace falta esto, sino que para toda conexión se utiliza el mismo socket. Sólo hay que crear un fichero en .ssh/config con el siguiente contenido:

If you want to make rsync-over-ssh to use specific 'ssh' options like, using a different identity key than the default one, you can use the '-e' rsync argument to pass options to the ssh command. Example above :]

Me he encontrado varias veces, en el caso de tener en una misma IP, dos servidores ssh en distintos puertos, con lo que el cliente de ssh se queja de que la key que el servidor le ofrece es distinta a la que [primero] aceptaste para esta IP. Esto, es una medida de seguridad para evitar ataques man-in-the-middle, por ejemplo, pero a veces como en el caso que comentaba es una coña... También podemos encontrarnos con el mismo caso cuando tenemos 2 servidores en alta disponibilidad que van compartiendo una misma IP de frontend. Para estos casos en los que quizá nos interese saltarnos estos warnings y sus correspondientes preguntas yes/no, podemos usar esta opción del cliente ssh.