SSH

pepe

18 de febrero de 2011

Índice
1. Introducción. 1

2. Instalación. 4

3. Conguración. 4

4. Conectarse a un host remoto. 5

5. Copia de cheros con ssh. 6

6. Conguración del cortafuegos. 7

1. Introducción.
Se puede acceder remotamente a un host utilizando ssh, que es un sistema cliente-

servidor que permite logearse en modo consola en un servidor remoto. El servidor ejecuta

el demonio sshd (podemos ver si está ejecutándose con pgrep sshd ).

Al establecerse la conexión se crea un túnel seguro entre las dos máquinas (parece que

incluso antes de que nos autentiquemos). El proceso de autenticación al establecer la

conexión es doble. Por una parte el servidor debe poner de maniesto su identidad (para

evitar suplantaciones) y por otra parte el usuario que accede al sistema también debe

autenticarse. El servidor usa un sistema de clave pública para identicarse. Esa clave

pública se genera en el momento de la instalación del servidor y se suele almacenar en

/etc/ssh/ssh_host_rsa_hey.pub (habrá otro archivo con el mismo nombre pero sin la

extensión .pub y que contiene la clave privada).

1
 La primera vez que un cliente se conecta a un servidor le sale un mensaje advirtiendo

que la autenticidad del servidor no puede ser establecida y mostrándonos su clave pública.

Si la aceptamos, este mensaje ya no vuelve a aparecer, el servidor se convierte en un

host conocido, y su clave pública (y parece que también su ip) queda almacenada en

~/.ssh/known_hosts.
Si queremos cambiar la clave pública del server, por ejemplo porque ha sido compro-

metida, tenemos que eliminarla de /etc/ssh/ y luego regenerarla:

# rm /etc/ssh/ssh_host_*
# dpkg-reconfigure openssh-server

Lógicamente, luego habrá que cambiar adecuadamente los known hosts de los clientes. Es-

to se puede hacer de varias formas. La más bestia es cargarse el archivo ~/.ssh/known_hosts,

pero si hay muchos hosts allí guardados esto sería un disparate. Lo más razonable es con

el comando:

ssh-keygen -R host_ip_address

que elimina la clave pública del host referenciado, de manera que la próxima vez que

nos conectemos a él será como si fuese la primera y nos pedirá aceptar su nueva clave

pública.

El usuario que accede como cliente se identica, en principio, por su password en el

equipo servidor, pero hay otras posibilidades, como por ejemplo usar clave pública. Para

hacer esto tenemos que generar la clave pública y luego activarla en el servidor. Para

generar la clave pública el usuario puede hacer en su cuenta en el cliente:

ssh-keygen -t dsa

Con esto se genera un par de claves, pública y privada, que se almacenan en ~/.ssh/id_dsa.pub
y ~/.ssh/id_dsa, respectivamente. Estas son las claves que sirven para identicar al clien-
te. Al generarlas nos pedirá una passphrase (que en el fondo es simplemente una password

pero que permite más caracteres) y que no hay que olvidar porque es imposible recupe-

rarla (yo he puesto antiguas tonterías h8a3z2g4). Ahora será necesario poner la clave

pública en la cuenta del usuario en el servidor. Para esto hay que añadirla al nal del ar-

chivo ~/.ssh/authorized_keys en su home del servidor. Una forma cómoda de hacerlo es

copiar la clave por ejemplo en ~/clave.tmp y luego (lo siguiente no es como administrador,

sino como el usuario que se loguea en el server via ssh):

2
 cat ~/clave.tmp >> ~/.ssh/authorized_keys
rm clave.tmp

Una vez hecho esto, cada vez que intentamos conectarnos desde el cliente al servidor por

ssh nos pedirá la contraseña, que es la passphrase de la clave pública que hemos generado,
y ya no la password del usuario. Como teclear esto cada vez que nos conectamos puede

ser un lío conviene usar ssh-agent, que es un programa que mantiene las claves privadas

usadas para la autenticación de clave pública y que arranca con las X o al logearse en

el sistema. Para añadir claves a este programa se usa el comando ssh-add, que cuando
se ejecuta sin parámetros añade al ssh-agent los cheros ~/.ssh/id_rsa, ~/.ssh/id_dsa
y ~/.ssh/identity (esta última es para RSA v.1). Si estos cheros llevaban asociada una

passphrase, nos la pide y queda guardada en el agente. Tras esto ya no será necesario

meter la passphrase cada vez que nos conectamos al servidor, ya que el programa ssh-
agent se encarga de ello. Basta con identicarse la primera vez que nos conectamos en

cada sesión y luego se supone que ya estamos correctamente identicados para todo el

resto de la sesión. Eso sí, si salimos del sistema, al volver a entrar tendremos que volver

a identicarnos con la passphrase. Si queremos que esta identicación se mantenga de

una sesión a otra y mientras no se apague el ordenador será necesario usar el programa

keychain.
Para borrar del agente las identidades añadidas al ejecutar ssh-add sin argumentos

hacemos

ssh-add -d

Si queremos eliminar todas las identidades del agente, simplemente ponemos la D ma-

yúscula en el comando anterior.

Para poder acceder desde t a box como ususario pepe he tenido que copiar en la
carpeta /home/pepe/.ssh de t las claves de ese usuario que tengo en asus. En concreto he

copiado los archivos id_sda, id_sda.pub, id_rsa, e id_rsa.pub. Luego puedo acceder desde

konqueror en t, poniendo en la barra de direcciones cualquiera de las dos siguientes:

fish://pepe@box:1435
sftp://pepe@box:1435

Otra posibilidad es acceder desde dolphin, creando una carpeta de red con conexión vía

ssh.

3
2. Instalación.
Para usarlo en debian podemos instalar el metapaquete ssh, que instala el cliente

( openssh-client ) y el servidor ( openssh-server ). Los archivos básicos de conguración

son:

/etc/ssh/ssh_cong (en el cliente)

/etc/ssh/sshd_cong (en el servidor)

3. Conguración.
El archivo básico de conguración es el del servidor, /etc/ssh/sshd_cong. En él las

líneas que empiezan por # son comentarios. Como siempre, tras editarlo habrá que

hacer /etc/init.d/ssh restart. Algunas opciones interesantes que contiene este archivo de
conguración son:

Port para especicar el puerto en el escuchará ssh (por defecto es el 22, yo uso el 1435).

Protocol para especicar la versión de ssh que se usará; lo dejamos en 2, que es más

moderno.

AllowUsers es una lista de nombres de usuarios, separados por espacios, a los que se

les permite el acceso vía ssh (yo aquí no he puesto nada, es decir, la opción no

aparece).

PermitRootLogin por seguridad lo ponemos en no.

X11Forwarding para indicar si se permite o no X11 forwarding (yo lo tengo puesto a

yes ).

PasswordAuthentication especica si se permite la autenticación por medio de pass-

word; por defecto es yes, pero igual es una buena idea ponerlo a no (sobre todo

si voy a permitir el acceso desde internet).

LoginGraceTime el servidor se desconecta después de este tiempo (en segundos) si el

usuario no consigue conectarse; por defecto es 120 segundos.

MaxAuthTries especica el número máximo de intentos de autenticación por conexión;

por defecto es 6, yo lo he puesto a 2.

MaxStartups

4
PermitUserEnvironment
Los clientes por su parte obtienen la conguración de, por orden:

1. las opciones que se les pasa en línea de comandos.

2. el archivo de conguración del usuario, ~/.ssh/cong.

3. el archivo de conguración del sistema, /etc/ssh/ssh_cong.

Una opción interesante para meter en este último archivo (cuya sintaxis es similar a la

del archivo de conguración del servidor), para no tener que andar especicándolo en

línea de comandos, es el puerto en el que se opera si es distinto del estándar. Si queremos

cambiar el puerto conviene vericar que no está siendo usado por otra aplicación. Para

comprobar esto en el servidor podemos hacer, por ejemplo para ver si el puerto 435 está

libre:

netstat -an | grep 435

4. Conectarse a un host remoto.

Nos conectamos desde el cliente usando el comando ssh seguido del nombre o ip del

servidor al que queremos acceder:

ssh remotehost.com

Nos conectamos siempre con la identidad de un usuario que está validado en el servidor.

Por defecto será la del usuario activo en el cliente. Podemos especicar otro usuario con

la opción -l (letra ele) o prejándolo al nombre del servidor:

ssh -l pepe remotehost.com

ssh pepe@remotehost.com

Por defecto ssh trabaja en el puerto 22 salvo que se especique otra cosa al congurarlo.

Para conectarnos usando otro puerto se indica con la opción -p:

ssh -l pepe -p 435 remotehost.com

Si lo que queremos es simplemente pasarle un comando al servidor para que lo ejecute,

pero sin mantener una shell remota, sino simplemente ejecutar el comando y salir, pues

le pasamos el comando como argumento nal de ssh. Por ejemplo, si queremos que el

servidor ejecute ls -l / haríamos:

5
 ssh pepe@lam ls -l /

En este caso, la salida del comando la captura la shell del cliente, que puede usarla como

si fuese la salida de cualquier comando ejecutado localmente.

Para desconectarse podemos teclear en la consola exit, logout o Ctrl-d. Cualquiera de

estas alternativas hace que el servidor termine la sesión. Si no es posible contactar con

el servidor se pueden usar secuencias de escape del cliente para hacer que sea éste el que

termine la conexión. En este caso habría que teclear 'RC RC ~ .', es decir, dos retornos

de carro, la virgulilla y el punto.

5. Copia de cheros con ssh.

Al instalar ssh se instalan dos herramientas que nos permiten copiar cheros remota-

mente y que son scp (secure copy) y sftp (secure ftp). La primera se comporta como

el comando cp y la segunda como ftp, pero en ambos casos a través del túnel ssh. Para

usarlos no es necesario estar conectado por ssh, sino que desde nuestra consola de cliente

los ejecutamos y ellos ya se encargan de conectarse, pedir contraseñas, desconectarse,etc.

scp usa ssh para copiar cheros entre hosts y tiene una sintaxis similar a la de cp,

tomando como primer argumento el chero origen y como segundo el chero destino. Los

cheros se especican con la notación user@host:le, pero cuando no aparece user@host:

se entiende que se trata del host local. Lógicamente hay que especicar la ruta de los

cheros y, como es habitual, si no aparece precedida por un slash se interpreta que es

relativa al home del usuario. Para copiar directorios recursivamente se usa la opción -r.

sftp es un programa interactivo de transferencia remota de cheros, similar a ftp, y que

opera sobre ssh. Una diferencia sobre ftp es que sftp no soporta ftp anónimo. Para usarlo

interactivamente, disponiendo de comandos similares a los de ftp (get, put, exit, bye o

quit, etc), haríamos:

sftp host

En este caso disponemos de algunos comando en sus versiones remota y local (esta última

con nombres precedidos por l). Así, comandos remotos serán cd, ls, mkdir y pwd, y sus
versiones locales lcd, lls, lmkdir, lpwd. La sesión se termina con exit, quit o bye. Para subir

y bajar cheros se usan put y get :

put local-path [remote-path]

get remote-path [local-path]

6
Cuando no se especica la ruta opcional se considera idéntica a la que sí aparece. La

opción -P hace que se copien también los permisos y tiempos de acceso de los cheros.

Pero también se puede usar para descargar un archivo directamente, sin abrir una

sesión interactiva, usando el siguiente formato:

sftp user@host:file1 [file2]

En este caso parece que conviene especicar claramente la ruta del chero. El chero de

destino, le2, es opcional, será el nombre y la ruta que le queremos dar a la copia.

6. Conguración del cortafuegos.

Habrá que abrir el puerto 22 para tcp (o el puerto que usemos si le hemos cambiado la

conguración por defecto, en mi caso el 1435). En /etc/shorewall/rules podemos poner:

ACCEPT net $FW tcp 22

o bien, de forma más compacta, algo como:

SSH/ACCEPT net:192.168.0.2 $FW

Parece que como puerto, en lugar de poner 22 podemos poner ssh y él ya lo entiende.