Este artículo ha sido consultado en 952 ocasiones.

SSH (secure shell) es el reemplazo de Telnet y FTP, el problema con estos dos protocolos es que envían las contraseñas y la información en texto plano, de manera que si alguien colocó un sniffer para escuchar el tráfico de nuestra red, es cosa de tiempo para que intercepte nuestro password (incluso el de root) y pueda acceder al sistema.

Por otro lado, SSH transmite los datos de manera cifrada. Cifrar los datos no hace imposible que un hacker o cracker intercepte los datos que enviamos sobre Internet, sin embargo la información interceptada será inútil para el atacante pues estará compuesta por una secuencia de bits sin sentido para el maldoso ;-).

SSH utiliza un algoritmo de encriptación propietario, la versión libre de SSH fue desarrollada por la gente de OpenBSD (los especialistas en seguridad) y es conocida como OpenSSH.

Instalar ssh en Debian es muy sencillo:

# apt-get install ssh

Este paquete instala tanto el servidor (sshd) como el cliente. Elija las opciones por omisión. Al instalarse, SSH creará una llave para identificar al servidor (la hostkey). SSH utiliza el puerto 22. Puede configurar el servidor SSH editando el archivo /etc/ssh/sshd_config.

Bien, supongamos que hemos instalado SSH en el servidor mononeurona.org, si tenemos un usuario con login “mmontoya” en este servidor tecleamos desde un equipo remoto:

$ ssh mmontoya@mononeurona.org

Si es la primera vez que entramos, SSH nos preguntará si deseamos agregar este servidor, le decimos “yes”. Luego de logearnos estaremos colocados en el $HOME del usuario,en este caso /home/mmontoya. Por omisión SSH no permite el logeo remoto del usuario root, pero no importa, puede usar el comando “su” para cambiarse a root después de logearse en el sistema, lo cual sin duda es más seguro que estar enviando la contraseña del administrador por la red.

Si está en un equipo Windows, descargue el programa Putty pues el cliente Telnet no sirve para SSH. Putty es un programa de código abierto con licencia MIT, similar a la licencia BSD.

Todo lo que podemos hacer frente al monitor del servidor lo podemos hacer con SSH, podemos usar Midnight Commander (mc), wget o nano, incluso podemos apagar o reiniciar el equipo. Para abandonar una sesión de SSH y desconectarse del servidor utilice el comando “exit”.

Además de permitir el login remoto, el servidor SSH hace posible transferir archivos en ambas direcciones con el comando “scp” (secury copy). Por ejemplo, para transferir una imagen de Gimp del directorio actual al servidor tecleamos:

$ scp imagen.xcf mmontoya@mononeurona.org:/home/mmontoya

Al usar scp no es necesario especificar binary o ASCII como en FTP. Por supuesto, usted debe tener permiso de escritura del directorio remoto donde desea escribir. Para transferir un directorio completo se usa el parámetro “-r” :

$ scp -r ./imagenes mmontoya@mononeurona.org:/home/mmontoya

Para transferir archivos en sentido inverso, (del servidor al disco local) simplemente se invierte el orden:

$scp mmontoya@mononeurona.org:/home/mmontoya/archivo.tgz ./

Siempre que usemos scp, se nos pedirá nuestra contraseña de usuario para abrir una sesión de transferencia, la sesión concluye al terminarse de transferir el archivo. (Ve más abajo como crear una llave pública para no tener que volver a teclear el password).

A pesar de que scp es muy útil existen pocos clientes que puedan competir con los desarrollados para FTP, como gFTP, Kbear o incluso Nautilus. Es por esto que es conveniente instalar un servidor FTP sobre SSL como vsFTP. Espero que con el tiempo podamos ver más plugins para SSH como los que vemos para FTP, pero eso si, borre Telnet (cliente y servidor) de su sistema.

Actualización Mayo del 2005: Esto lo escribi hace un año y de hecho las modernas versiones de MC pueden ya transferir archivos por SSH de manera más cómoda, además el editor Jedit.org ya puede editar páginas remotas usando SSH. De modo que el número de casos donde se puede prescindir del FTP ha aumentado.

Otro de los usos de SSH es que se puede utilizar con el X server, de esta manera podemos entrar a una sesión gráfica de manera remota y segura. Sin embargo, esto nunca lo he hecho así que no intehto explicarlo ;-)

Confianza entre equipos

Si usted (como muchos de nosotros) está constantemente administrado servidores de manera remota (una vez arregle un PostgreSQL a 800 kilómetros de distancia desde un viejo cibercafé de Oaxaca [sé que la anécdota no viene mucho al caso pero estoy muy orgulloso de ella ;-) ]) le parecerá chocante estar tecleando los kilométricos passwords que (como muchos de nosotros) seleccionamos por aquello de alcanzar una alta seguridad.

Sin embargo, es posible crear confianza entre dos equipos de manera que no tengamos que volver a teclear nunca más el password y sin perder seguridad (de hecho las llaves públicas son más seguras). Para crear confianza entre dos equipos es necesario crear una llave pública y agregarla al archivo authorized_keys del equipo remoto. Por ejemplo, soy el usuario "manuel" en una WorkStation NetBSD cuyo hostname es "andromeda" y deseo conectarme al equipo mononeurona.org usando mi cuenta de usuario "httpuser". La cosa es así:

Creamos la llave pùblica con el comando keygen-ssh (cuando le pregunte la frase sólo de enter):

$ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/manuel/.ssh/id_dsa):
Created directory '/home/manuel/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/manuel/.ssh/id_dsa.
Your public key has been saved in /home/manuel/.ssh/id_dsa.pub.
The key fingerprint is:
ca:6d:4e:6c:f5:fd:10:3b:59:7b:11:80:59:7d:8b:54 manuel@andromeda

Ahora copiamos la llave pública al equipo remoto:

$ scp .ssh/id_dsa.pub httpuser@mononeurona.org:/home/httpuser/.ssh/andromeda_id_dsa.pub

Nos metemos al otro equipo (¡tecleando el password por última vez!):

$ ssh httpuser@mononeurona.org

Una vez adentro, insertamos el archivo con nuestra llave pública al archivo authorized_keys:

$ cat .ssh/andromeda_id_dsa.pub >> .ssh/authorized_keys

Comprobamos los permisos. El directorio .ssh debe tener permisos de ejecución y lectura pero no de escritura:

$ chmod 555 .ssh && chmod 644 .ssh/authorized_keys

Nos salimos del servidor remoto con exit y volvemos a teclear:

$ ssh httpuser@mononeurona.org

Tarárárarán! Entramos automáticamente sin teclear nada. Además, agrego:

alias mono='ssh httpuser@mononeurona.org'

a mi archivo $HOME/.bashrc de modo que de ahora en adelante, basta con teclear "mono" para entrar automaticamente al equipo remoto, ¡cuatro letras en lugar de 42!

Y eso es todo, ¡hasta el próximo tutorial!

Última actualización: 2007-04-29 10:57:00-05

chilicuil está:
Leyendo sobre servidores gnu/linux
1 hour, 1 minute ago

asarch está:
Comprendiendo el proceso de instalacion del ArchLinux con QEMU en NetBSD...
6 hours, 2 minutes ago

luzbel está:
Reviviendo mi primer compu (Celeron 400 Mhz)con NetBSD 4.0
7 hours, 55 minutes ago

chilicuil está:
bambi, bambi, te espero
11 hours, 28 minutes ago

starkad está:
ayer lo baje y estuve jugando el wesnoth, deja le agarro la onda y vemos
13 hours, 49 minutes ago

chilicuil está:
entonces que pedo, quien se rifa la reta de wesnoth conmigo?
1 day, 2 hours ago

Que estuvimos haciendo >>

Consultoría y Soporte