La configuración es bastante sencilla. Instalamos y configuramos Tor en nuestro PC o servidor para configurar un servicio oculto. Habilitamos el servicio de ssh para ser escuchado como un servicio .onion. Para esto editamos el archivo /etc/tor/torrc y añadimos las siguientes líneas:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 22 127.0.0.1:22

Para saber nuestro url .onion:

# cat /var/lib/tor/hidden_service/hostname
adn6xndfyhgcpl5o.onion

Este es un url aleatorio que no es recomendable compartirlo. Si queremos generar otro url .onion, básicamente se borra los archivos dentro de /var/lib/tor/hidden_service/ y se reinicia Tor.

En la máquina desde donde queremos acceder al servicio también debemos tener instalado Tor (ver sección instalar Tor) y torsocks.

apt-get install tor  torsocks

Ahora podemos hacer ssh al servicio oculto utilizando torsocks

$ torsocks ssh usuario@adn6xndfyhgcpl5o.onion
usuario@adn6xndfyhgcpl5o.onion's password:


Listo ya puedo acceder a mi computadora de forma remota, con ssh sin necesidad de ip público.

Una última medida podría ser configurar ssh para que escuche solo en localhost. Para esto editamos el archivo /etc/ssh/sshd_config y añadimos la siguiente línea:

ListenAddress 127.0.0.1

1. SSH con Llaves Públicas y Privadas: Autentificar un usuario con contraseñas tiene sus problemas. Si administramos varios servidores debemos recordar la clave de todos y muchas veces para no olvidaras utilizamos claves débiles. Al utilizar llaves públicas y privadas solucionamos estos 2 problemas.
2. Túneles SSH (parte 1): Es muy probable que alguna vez sea necesario ingresar a un servidor dentro de una Intranet con IP privada desde Internet. Si tenemos un servidor con acceso a SSH accesible desde Internet y que puede ver esta IP privada, asunto solucionado con túnles SSH
3. Túneles SSH (parte 2): En este how to se aprende como compartir servicios desde mi máquina con IP privada hacia Internet gracias a los túneles SSH. El ejemplo más interesante es como con un servidor SSH en un ip pública, 2 máquinas con IPs privadas en distintas redes se pueden ver entre sí sin necesidad de VPNs.
4. Aplicaciones Gráficas en Red con SSH: Todos usamos SSH para acceder a línea de comandos en un servidor. No todos saben que también podemos usar SSH para acceder a aplicaciones gráfica en nuestra red.
5. SSH y Proxy Socks navegación segura en Internet: Con una simple opción de SSH podemos navegar en Internet de forma encriptada y sin restricciones. Muy útil cuando navegamos en sitios done los servidores proxy no dejan navegar a ningún lugar o donde queremos tener mayor seguridad al navegar.
6. SSH y HTTPS en el puerto 443: Muchas veces el puerto 22 puede estar bloqueado en una red, haciendo que la mayoría de estos tips no sean útiles. Sin embargo, muy rara vez una red bloqueaa el puerto 443, en este ejemplo se enseña como hacer para compartir el puerto 443 para HTTPS y SSH de manera simultanea.
7. Copia Remota con SCP: La herramienta SCP permite copiar archivos a través de la red utilizando el protocolo SSH. En este tip aprenderemos como hacer esto y además como hacerlo limitando el ancho de banda si queremos copiar archivos muy grandes.
8. Simplifica tu vida gracias a  ~/.ssh/config: Manejamos varios servidores, cada uno de ellos utiliza puertos diferentes. Podemos configurar nuestro cliente SSH para que algo como «ssh -p 2200 usuariox@servidorremoto.com» sea tan simple como «ssh serv«
9. SSH y SFTP con usuarios enjaulados: Muchas veces se tiene la necesidad de dar acceso a nuestro servidor a personas en las que no confiamos. En este tip se aprende como hacer para crear un ambiente limitado para estos usuarios y que tengan solamente las herramientas que necesitan.
10. Sincronizar Directorios con SSH y RSYNC: RSYNC, es una poderosa herramienta de sincronización a través de la red. En este tip se aprende como combinar su poder con SSH y poder sacar respaldos o crear mirrors de forma segura.
11. Proteger SSH con Fail2Ban: Muchas personas creen que cambiar el puerto de SSH significa asegurar su servidor. Cualquier persona que conoce poco de nmap y sabe usar Google seguro podrá descubrir en que puerto se ejecuta SSH. Fail2Ban es una herramienta mucho más poderosa que bloquea los IPs luego de X números de intentos fallido por un tiempo Y. De esta manera se hacen inútiles los ataques de diccionario.
12. Acceder a un Computador a través de Tor sin IP Públicor: Los servicios ocultos de Tor permiten que cualquier protocolo TCP sea accedido a través de la red Tor. En este post explico como hacerlo para ssh.

Instalar Fail2Ban

En las distros basadas en Debian, basta con instalar el paquete fail2ban. Supongo que en otras distros la instalación es igual de simple

aptitude install fail2ban


Configurar Fail2Ban

Como cualquier aplicación de Linux, su configuración se encuentra dentro del directorio /etc. En este caso el directorio donde debemos buscar es /etc/fail2ban. El archivo que modicaremos en este mini tutorial es el /etc/fail2ban/jail.conf. Por defecto viene con varios templates para proteger servicios de nuestros servidores, no solo SSH. Algunas variables interesantes para modificar:
Al inicio del archivo encontraremos las variables ignoreip y bantime La primera sirve para que no bloquee mi IP si algo sale mal y la segunda especifica el tiempo a bloquear un IP en segundos. Por defecto son 10 minutos (600 segundos).

ignoreip = 192.168.182.3
bantime = 600


Luego bajamos a la sección de SSH y verificamos que la configuración este correcta:

[ssh]

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6


Reiniciamos fail2ban

/etc/init.d/fail2ban restart


Listo ahora estamos protegidos contra los ataques de diccionario a nuestro servidor SSH

Si bien RSYNC no necesita de SSH para sincronizar, utilizar los 2 en conjunto tiene algunas ventajas entre las que destaco algunas:

• La información viaja encriptada
• No necesito correr un servidor RSYNC
• Solo necesito preocuparme de tener abierto el puerto de SSH

Nota: todos los ejemplos son una sola línea

Ejemplo 1: Sincronizar 2 servidores web

rsync -avz --delete  -e ssh /var/www/sitioweb usuario@servidorremoto.com:/var/www/mirror

Las opciones quieren decir:

• -a Sirve para hacer una sincronización recursiva
• -v Sirve para mostrar en pantalla información de lo que esta haciendo el proceso
• -z Sirve para enviar la información comprimida y ahorrrar ancho de banda
• –delete Sirve para borrar del destino todo lo que no esta en el origen. En otras palabras para tener un mirror 100% igual.
• -e ssh: Es la parte del comando que hace que este artículo sea catalogado como un tip ssh ;). Básicamente sirve para hacer la sincronización utilizando el protocolo ssh

Al igual que SCP el primer directorio es el origen y el segundo es el destino.

Ejemplo 2: Sincronizar con puerto  no Estandard

Algo muy común es que la gente  corra el servidor SSH en un puerto distinto al 22. Inclusive hace unos días publiqué como hacer para que escuche en el puerto 443. Ahora explicamos como sincronizar los 2 directorios donde el puerto del destino no es estandard.

rsync -avz –delete –rsh=’ssh -p 443′ /var/www/sitioweb usuario@servidorremoto.com:/var/www/mirror

Como pueden ver hay un solo cambio en este ejemplo. En lugar de usar -e ssh utilizamos –-rsh=’ssh -p 443′. Básicamente estamos diciendo que se utilice el puerto 443 en lugar del puerto 22.

Recomendaciones

Si desean hacer tareas automatizadas como usar su servidor como un mirror de un tercer (ej. Elastix, Wikileaks ) es muy recomendable crear un ambiente enjaulado para ese usuario SSH y seguro necesitará trabajar con autenticación con llaves públicas y privadas.

Nota: Todos los ejemplos que pongo a continuación con SSH se podría utilizar con cliente SFTP como Filezilla.

Descargar el script make_chroot_jail y guardarlo en /usr/local/sbin:

cd /usr/local/sbin
wget http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/make_chroot_jail.sh
chmod 700 make_chroot_jail.sh


La razón por la que guardamos el archivo en /usr/local/sbin, es porque es una ruta estandard para poner aplicaciones o scripts que no vienen con la distribución que usamos y que deben ser ejecutadas solo por el administrador. Además tiene la ventaja de estar incluido en el path de los administradores por lo que se puede ejecutar directamente escribiendo make_chroot_jail.sh en lugar de la ruta completa.

Modificaciones al script

Antes de ejecutar el script, me encontré con algunos detalles que deben ser cambiados para que funcione perfectamente. El primer cambio que se debe hacer es cambiar la primera línea del archivo. En lugar de decir:

#!/bin/sh

Deberíá decir

#!/bin/bash

Normalmente el comado /bin/sh es un link a /bin/bash, pero esto no es cierto en todas las distros. Para que este script funcione correctamente deberíamos ejecutarlo con el shell bash.

En el caso de mis pruebas con Ubuntu 10.4 y Debian Squeeze es necesario modificar la línea 472 y cambiar la librería:

/lib/libcap.so.1

por

/lib/libcap.so.2

En este script Ubuntu es reconocido como Debian. Así que en los 2 casos hay que modificar la línea 472. Si estas usando una distro como Suse, Fedora u otra, habría que modificar la línea correspondiente.

Personalizar el Ambiente

La última modificación que debemos hacer al script es agregar o quitar (lo dudo) las aplicaciones que queremos darle al usuario. En el caso de Debian/Ubuntu deberíamos modifcar la línea 119.

Crear el primer usuario:
La forma más básica de crear el usuario es:

make_chroot_jail.sh gnu

En este caso creamos el usuario gnu que será un usuario enjaulado. Ahora intentemos ingresar al servidor y listemos algunos directorios para ver si todo esta en orden.

ssh gnu@servidorremoto.com
ls /

Si la salida del comando es la siguiente hemos creado exitosamente nuestra Jaula.

bin dev etc home lib sbin usr

Por defecto la jaula se creará en el directorio /home/jail. Este directorio se podría cambiar pasando argumentos al comando. Para ver lo que se puede hacer con este script podemos ejecutarlo de la siguiente forma

make_chroot_jail.sh | less


Si quisieramos podríamos crear varios usuarios dentro de la misma jaula.

Crear varias Jaulas ssh

Es muy probable que queramos tener varias usuarios y cada uno con su propio ambiente chroot. Esto es algo muy útil si alguien vende hosting y quiere que sus usuarios utilicen SFTP en lugar de FTP, aumentando mucho la seguridad para los usuarios y para el servidor. Para crear los usuarios en un ambiente distinto se les debe asignar un shell propio y un directorio donde estará la jaula.

Con un ejemplo se entiende mejor. Vamos crear 2 ambientes enjaulados. El primero tendrá su shell como /usr/local/bin/shelltuxs y su ambiente chroot estará en /jaulas/tuxs. El segundo tendrá su shell como /usr/local/bin/shellgnues y su ambiente chroot estará en /jaulas/gnues. Podríamos tener tantos ambientes enjaulados como quisieramos, pero cada uno deberá tener su propio shell. Los shells que estamos creando podríán estar en cualquier directorio y llamarse de cualquier forma. El script los creará.

Crear usuarios gnues y su ambiente

make_chroot_jail.sh gnu1 /usr/local/bin/shellgnues /jaulas/gnues/
make_chroot_jail.sh gnu2 /usr/local/bin/shellgnues /jaulas/gnues/
make_chroot_jail.sh gnu3 /usr/local/bin/shellgnues /jaulas/gnues/


Crear usuarios tux y su ambiente:

make_chroot_jail.sh tux1 /usr/local/bin/shelltuxs /jaulas/tuxs/
make_chroot_jail.sh tux2 /usr/local/bin/shelltuxs /jaulas/tuxs/
make_chroot_jail.sh tux3 /usr/local/bin/shelltuxs /jaulas/tuxs/

Listo hemos creado 2 ambientes enjaulados y cada ambiente enjaulado. La verdad esta mucho más fácil que hace algunos años atrás cuando hice esto por primera vez.

Algunas consideraciones.

Si bien este script nos facilita la vida, tiene algunas errores. Si se actualiza varias veces el mismo usuario, habría que revisar el archivo /etc/passwd tanto en el ambiente real como el enjaulado para que no tenga usuarios repetidos. Lo mismo se debería hacer con el comando visudo y borrar los usuarios repetidos.

Supongamos que debemos ingresar a un servidor remoto, con un nombre de usuario que no es el mismo de mi máquina local y además corremos el servidor en un puerto distinto al 22. Cada vez que accedamos a este servidor deberíamos escribir algo así:

ssh -p 443 usuarioremoto@servidorremoto.com

No es el fin del mundo, pero si tenemos muchos servers y una mala memoria se nos complica un poco la vida. Que tal si en lugar de escribir toda esa línea podemos escribir simplemente:

ssh sremoto

Gracias al archivo de configuración ~/.ssh/config  podemos hacer sin problema. Empezamos creando el archivo:

vim ~/.ssh/config

En mi caso estoy utilizando vim como editor, pero podría ser un editor gráfico como gedit. El caracter «~» quiere decir home del usuario con el que estoy trabajando en este momento. En otras palabras si estoy trabajando con el usuario juan entonces lo más probable es que «~» se refiera a /home/juan/.
En el archivo de configuración añadimos las siguientes líneas.


Host sremoto
HostName servidorremoto.com
User usuarioremoto
Port 443

La primera línea es algo así como un alias para este servidor. La segunda línea nos dice el nombre del host para el servidor. En la tercera ponemos el nombre de usuario y en la última el puerto. No existe un orden específico sobre las variables que podemos utilizar. Podemos tener tantos Host como sea necesario.

Listo ahora ingresamos al servidor remoto.

ssh sremoto

Inclusive se puede utilizar el alias «sremoto » para copiar archivos con scp

scp archivo sremoto:

En este ejemplo estamos poniendo solo un servidor remoto, pero podríamos tener los que queramos. Las variables con configuramos aquí no son las únicas. Para más información sobre lo que podemos hacer con este archivo de configuración basta ver su página de manual:

man ssh_config

El comando SCP básicamente sirve para copiar archivos de un computador a otro, de manera encriptada, a través del protocolo SSH. Funciona de manera muy similar a como funciona el comando cp, donde tenemos un origen y un destino. La diferencia es que el origen o el destino van a ser computadores diferentes.

Ejemplo 1: Origen local, destino remoto

scp archivo.tar.gz usuario@servidorremoto.com:

En este caso el origen es un archivo local de la computadora donde estoy trabajando y el destino es el servidor remoto. El «:» al final del nombre del servidor quiere decir que vamos a copiar el archivo en el directorio home del usuario que realiza la copia. Después del : podríamos poner una ruta relativa al home del usuario o una ruta absoluta. Por ejemplo, si quisiera copiar en la ruta /home/usuario/directoriox

Rutas relativas:

scp arhivo.tar.gz usuario@servidorremoto.com:directoriox

Rutas absolutas:

scp arhivo.tar.gz usuario@servidorremoto.com:/home/usuario/directoriox

En este caso es más comodo usar la ruta relativa, pero no siempre será este el caso.

Ejemplo 2: Origen remoto, destino local

scp usuario@servidorremoto.com:arhivo.zip .

En este caso copiamos el archivo remoto archivo.zip (ubicado en el home del usuario) A la carpeta actual donde me encuentro en mi máquina local.
Tanto para el ejemplo 1, como para el 2 si quisieramos copiar un directorio, lo haríamos con la opción «-r». En general las opciones de scp son las mismas que las del comando cp

Ejemplo 3: Puerto alternativo

Muchas personas no corren ssh en el puerto 22, en un post anterior expliqué como hacer para correr ssh en el puerto 443 en conjunto con https. Pues bien, ahora hagamos un ejemplo de copia de scp utilizando el puerto 443.

scp -P 443 -r /ruta/directorio usuario@servidorremoto.com:/ruta/deestino


En este caso copiamos todo un directorio y lo hacemos por el puerto no estadard 443.

Ejemplo 4: Limitar Ancho de Banda

Esta opción no la sabe mucha gente y en ocasiones puede ser muy útil. Que tal si queremos copiar un archivo muy grande desde o hacia Internet. Es muy probable que eso genere mucho tráfico que haga insoportable el uso del Internet para el resto de personas en la red, incluido quien esta subiendo el archivo. Por suerte, parece ser que los desarrolladores de Openssh han pensado en todo y se puede limitar el ancho de banda de la transeferencia. Para esto usamos la opción «-l» seguido por el ancho de banda a limitar en kbits/segundo. (8 kbit/segundo = 1 kbyte/segundo)

scp -l 80 archivgrande.tar.gz usuario@servidorremoto.com:

De esta manera limitaremos la copia a 80 kbits/seg (10 kbytes/segundo).

Una solución simple podría ser ejecutar SSH en el puerto 443, pero lo más probable es que necesitemos correr alguna aplicación HTTPS en ese puerto. La solución a este problema se llama SSLH. Sus autores lo llaman un multiplexor SSH/HTTPS.

Básicamente lo que hace este servicio es redirigir las peticiones de SSH a localhost:22 y las de HTTPS a localhost:443. Para que todo funcione bien debemos deberíamos configurar nuestro servidor web para que escuche en: 127.0.0.1:433 en lugar de *:443.

Manos a la Obra

Nota: Si se va hacer esto en un servidor remoto podría perder la conexión al mismo. Trabaje con atención y mantenga una conexión de ssh abierta por si las moscas.

Lo primero que tenemos que hacer es instalar SSLH. En las distribuciones basadas en Debian (ej. Ubuntu) bastará instalarlo desde repositorios. En otras distros supongo que el procedimiento debe ser muy similar.

aptitude install sslh

Una vez instalado, lo primero que debemos hacer es configurar nuestro servidor web para que el puerto 443 sea solo escuchado en localhost y no en el ip público.  En mi caso personal uso Cherokee y para esto en el Cherokee admin debemos ir a: General-> puertos. Una vez ahí añadimos la dirección ip junto a la directiva de 443.  En el caso de Apache o cualquier otro servidor web se aplica el mismo concepto.

El servicio ssh si queremos lo podemos configurar para que escuche solo en 127.0.0.1:22 ya que ahora podríamos acceder desde el 443. No recomiendo hacer esto hasta que todo este funcionando.

Una vez que tenemos configurado el servidor web, tenemos que configurar el sslh. Para esto editamos el archivo /etc/default/sslh. Básicamente se debe añadir la lista RUN=yes y configurar el ip pública de nuestro servidor. Deberíamos tener algo similar a esto:

DAEMON_OPTS="-u sslh -p 200.200.200.200:443 -s 127.0.0.1:22 -l 127.0.0.1:443 -P /var/run/sslh.pid"
RUN=yes

Nota: Son solo 2 líneas la primera define la variable DAEMON_OPTS y la segunda la variable RUN.

Ahora solo queda arrancar el servicio

/etc/init.d/sslh start

Listo ahora podemos ingresar a nuestro servidor utilizando el puerto 443

ssh -p 443 usuario@servidorremoto.com

Ahora si quisieramos navegar utilizando un proxy socks básicamente deberíamos hacer algo así:

ssh -p 443 -ND 8080 usuario@servidorremoto.com

Ahora ya estamos preparados para redes hostiles donde les gusta bloquear lo que más pueden.

Les recomiendo leer el siguiente artículo de Linux Magazine donde Charlie nos cuenta sobre sslh. Si no hubiera sido por Charlie, no supiera como hacer esto y no hubiera escrito este artículo. Sin lugar a dudas mi columna favorita de Linux Magazine.

Ahora les enseñare como navegar la web de forma ilimitada en una red muy limitada. Por ejemplo la red de una universidad, donde los pobres alumnos casi no pueden navegar a ningún lado porque todo esta bloqueado. Además con esta estragegia nevagaremos de una forma seguro, muy útil para sitios con access points públicos.

Requerimientos

Para que esto funcione, así como la mayoría de los tips ssh que he estado publicando, es importante que ustedes tengan un servidor a donde hacer ssh. Si su proveedor de internet en la casa les da un ip público, se podría usar ese ip para ssh. Otra opción es contratar un servidor virtual dedicado en la nube que puede costar unos $20 al mes. Un poco caro para hacer ssh, pero el costo puede llegar a cero si vendemos hosting a nuestros a migos para que cuelguen sus páginas web. Personalmente uso el servicio de Linode desde hace algún tiempo y me siento feliz.

Se asume que la red local no esta bloqueando el puerto 22 de SSH. Pronto publicaré un how to para correr ssh y un servidor web en el puerto 443 (normalmente https) que podría solucionar este problema.

Manos a la Obra

Dicho esto manos a la obra. Lo primero que vamos a hacer es ssh a nuestro servidor y decirle que use un puerto arbitrario como servidor Socks.

ssh -ND 8080 usuario@servidorremoto.com


La opción -N sirve para que la sesión de ssh no sea interactiva, en otras palabras no tendremos un shell ssh en el servidor. Muy útil si vamos a prestar nuestra computadora a un tercero. La opción -D es la que sirve para crear el servidor Socks. El puerto 8080 es arbitrario y podría ser cualquier puerto que nosotros queramos.
Eso es todo, ahora solo queda configurar nuestro navegador web para que use el servidor Sock recién creado. En el caso de Firefox/Iceweasel vamos a: Editar -> Preferencias -> Avanzadas -> Red. En el recuadro de Conexión ponemeos configuración manual de proxy y configuramos Socks como localhost y puerto 8080.

Listo ahora sí podemos navegar por internet sin las limitaciones del proxy local y de forma privada dentro de la red local.

ssh -X usuario@ipservidor thunderbird

Ahora que tal si queremos ejecutar más de una aplicación gráfica. Podríamos utilizar una sola sesión de ssh para abrir varias aplicaciones.

ssh -X usuario@ipservidor
thunderbird &
oowriter &
gnome-calculator&


En este caso no ponemos la aplicación a ejecutar al momento de hacer ssh, sino que las empezamos a ejecutar desde que ingresamos a la máquina remota. De esta manera podemos ejecutar una aplicación después de la otra añadiendo el carácter "&" al final de cada comando para que se ejecuten en segundo plano. De esta forma podemos ejecutar varios comandos en el mismo terminal.


Conclusión

Como se puede ver ejecutar aplicaciones gráficas en red puede ser muy útil si nos manejamos en pequeñas o grandes redes. Una de las utilidades que más me gusta es para reutilizar computadoras viejas. Se podría en una máquina de pocos recursos ejecutar aplicaciones gráficas a través de la red desde un computador con más recursos. Así podríamos ejecutar aplicaciones como openoffice en computadores de más de 10 años. Hace muchos años escribí un how to sobre el tema en el Ecualug. LTSP o TCOS son mejores soluciones para estos problemas.