Instituto Profesional DUOC UC

Ingeniería de Ejecución en Informática.

SSH

Instalación – Configuración

Nicolás Briceño
Gonzalo Soto
Introducción

Conoceremos a grandes rasgos SSH, su funcionamiento, historia y seguridad.

Realizaremos paso a paso la instalación y configuración incluyendo medios visuales para una mejor
comprensión.

Finalmente concluiremos con pruebas de transferencia de archivos a través de este protocolo.

SSH

Secure Shell, lo que podríamos traducir como “Interprete seguro de comandos”. Es un protocolo de
red que permite que el intercambio de datos entre dos dispositivos sea fiable, esto se logra por
medio del uso de un canal seguro.

Es utilizado en Linux y sistemas Unix para tener acceso a las cuentas Shell.

Funcionamiento

SSH usa una llave criptográfica pública para autenticar la computadora remota y permitir que la
computadora alejada autentifique al usuario.

Se utiliza típicamente para registrarse en una máquina remota y para ejecutar comandos, pero
también apoya el tunneling (creación de túneles), remitiendo puertos del TCP y las conexiones X11;
puede transferir archivos usando los protocolos asociados de SFTP o de SCP.

Utiliza el modelo Servidor – Cliente.

Por defecto, escucha en el puerto estándar 22 de TCP.

Historia

Al principio sólo existían los r-commands, que eran los basados en el programa rlogin, el cual
funciona de una forma similar a telnet.

La primera versión del protocolo y el programa eran libres y los creó un finlandés llamado Tatu
Ylönen, pero su licencia fue cambiando y terminó apareciendo la compañía SSH Communications
Security, que lo ofrecía gratuitamente para uso doméstico y académico, pero exigía el pago a otras
empresas. En el año 1997 (dos años después de que se creara la primera versión) se propuso como
borrador en la IETF.

A principios de 1999 se empezó a escribir una versión que se convertiría en la implementación libre
por excelencia, la de OpenBSD, llamada OpenSSH.

Seguridad

SSH trabaja de forma similar a como se hace con telnet. La diferencia principal es que SSH usa
técnicas de cifrado que hacen que la información que viaja por el medio de comunicación vaya de
manera no legible y ninguna tercera persona pueda descubrir el usuario y contraseña de la conexión
ni lo que se escribe durante toda la sesión.

Es posible atacar este tipo de sistemas por medio de ataques de REPLAY y manipular así la
información entre destinos.

Manos a la obra

Instalando SSH

Llegando a este paso sólo tenemos 2 alternativas al momento de instalar SSH, usar su versión
normal llamada SSH en la cual su licencia se acaba en el momento de darle un uso comercial y
debemos comenzar a pagar para utilizarla -hay que recalcar que el uso tanto de usuario y como uso
universitarios están exentas y pueden usarse gratuitamente-, o utilizar la variante OpenSSH, la cual
tiene una licencia OpenBSD la cual es totalmente gratis y que se encuentra en constante desarrollo.

Una ventaja en la instalación de SSH es que durante la instalación de CentOS o cualquier

distribución de linux al momento de habilitar las reglas del Firewall puede activarse las del SSH e
instalar lo necesario para que este funcione, si no se puede instalar mediante el administrador de
paquetes para luego configurarlo manualmente. Lamentablemente esto no nos sirve para demostrar
el proceso de instalación ni configuración ya que se encuentra instalado pero faltaría configurarlo,
en vez de eso utilizaremos OpeSSH, lo que nos da una ventaja de poder utilizar la consola para
obtener e instalar las dependencias y paquetes necesario para levantar nuestro servidor.
1. Vamos al gestor de paquetes.

2. Coloquemos SSH y luego presionemos buscar.

3. Seleccionemos los paquetes que se muestran a continuación.

4. Instalamos y luego verificamos si estos tienen alguna actualización.

Configuración SSH

Una vez lista la instalación y actualizados lo paquetes del servicio procederemos abrir una terminal
para levantar el servicio e ingresar como root a la conexión del local host mediante los siguientes
comandos: service ssh start inicia el servidor y note que se crearan las llaves necesarias para que
nos podamos autenticar en este. Luego ingrese ssh localhost para conectarnos localmente al
servidor, note que la conexión dice que el servidor no puede ser establecida debido a que el servidor
no se puede autenticar, como estamos haciendo nuestra primera prueba y la conexión es segura
escriba yes y luego presione enter.
Note que luego de esto una llave (RSA) ha sido añadida a los host conocidos. Después de esto
deberá entrar su password de root.

Felicitaciones hemos logrado nuestra primera prueba exitosamente, si duda de esto observe
detenidamente el la ultima linea antes del ultimo prompt. Esta le indica su ultimo log hecho con la
hora especificada, a esto se le llama llavero.

Ahora salga utilizando el comando logout y note que la conexión se ha cerrado.

Bien ahora como habrá notado, o debe notar, que una conexión como root es potencialmente
peligrosa, tanto que tendrá el poder para cambiar cualquier cosa en nuestro servidor, es por eso que
debemos editar el archivo /etc/ssh/sshd_config para hacer que nuestra conexión sea segura y
contenga algunas restricciones importantes.

Primero que nada hagamos un respaldo y luego procederemos a configurarlo.

Luego procedamos a editar el archivo, nosotros utilizaremos el comando gedit. Una vez ahí hay
cosas importantes que debe saber de archivo, como por ejemplo que el signo # representa un
comentario, no importa donde se encuentre, luego de sacarlo esta función se volverá totalmente
funcional.
Puerto.
Ya sabemos que como default el puerto de SSH es el 22, aun así por mas poderoso que sea nuestro
cortafuegos dejarlo así representa una gran vulnerabilidad, ya que todos saben esto podrían escanear
este y realizar o intentar un ataque que comprometa a nuestro servidor, por lo que debemos
cambiarlo entre un rango de 1025 y 65535, recuerde que este protocolo trabaja por TCP.

Nota: debido a problemas en nuestra red utilizaremos el puerto 22 y listenaddrses como default
debido a que la configuración de las políticas del cortafuego de nuestro router no nos permiten
conectarnos desde otros equipos, por favor tenga en cuenta esto antes de iniciar un servidor de este
tipo.

Protocol.

Debido a que todos los nuevos servicios ocupan este protocolo lo dejaremos tal cual a menos que
trabaje con servicios antiguos. Considere que la versión 1 presenta serias vulnerabilidades para el
servidor, use la con precaución.
ListenAddress.
Por defecto, el servicio de SSH responderá peticiones a través de todas las interfaces del sistema. En
algunos casos es posible que no se desee esto y se prefiera limitar el acceso sólo a través de una
interfaz a la que sólo se pueda acceder desde la red local. Para tal fin puede establecerse lo
siguiente, considerando que el servidor a configurar posee la IP X.X.X.X

HostKey.

Estas son las llaves publicas para el servidor sshd, tanto para el protocolo 1 y 2 de ssh, y como
arriba ya pusimos que solo usaremos el protocolo versión 2, entonces unas lineas están de más, o
sea, las que son para el protocolo 1, y aquí aparte solo usaremos las llaves dsa de la versión 2,
entonces eliminaremos unas lineas y des comentaremos otra, de manera que solo quede así:

# HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_dsa_key
Logging.

Ahora sigue la parte en la que el servidor sshd guarda los registros de eventos (logs):

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

Como vemos están comentadas, las haremos explicitas des comentando algunas para que quede así:
# Logging
#obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
LogLevel INFO

Aquí se especifican los parámetros para el registro de eventos, SyslogFacility especifica el tipo de
registros que hará, en este caso es AUTH, osea de las autenticaciones que se hacen contra el
servidor, el parámetro AUTH es el predeterminado. En LogLevel INFO es el valor
predeterminado, otros parámetros están especificados en la pagina del manual de sshd_config (man
sshd_config), los parámetros DEBUG2 y DEBUG3 cada uno especifican el nivel mas alto de
logueo, guardar registros con el nivel DEBUG viola la privacidad de los usuarios y por lo tanto
no es recomendada.
Autenticación.

La primera opción es: LoginGraceTime 2m, esto le dice al servidor sshd el tiempo en el que
desconectara a el usuario después de que no ha podido iniciar sesión satisfactoriamente, si el valor
es 0, no hay limite de tiempo para que un usuario se autentique, lo cual no es recomendable ya que
de esta manera podrían hacer ataques de fuerza bruta, o usando métodos de diccionario y así
adivinar la contraseña (estos métodos son muy comunes últimamente, yo a diario recibo desde 300,
500 y el máximo 2000 intentos a diario) por lo tanto no es recomendable dejar este parámetro a 0, el
valor predeterminado es: 2m, o sea 120 segundos.

Se descomentará y se dejara por default:

LoginGraceTime 2m

PermitRootLogin.

Establece si se va a permitir el acceso directo del usuario root al servidor SSH. Si se va a permitir el
acceso hacia el servidor desde redes públicas, resultará prudente utilizar este parámetro con el valor
NO.

Luego sigue: StrictModes yes, esto significa que sshd revisara los modos y permisos de los
archivos de los usuarios y el directorio $HOME de el usuario antes de aceptar la sesión. Esto es
normalmente deseable porque algunos novatos algunas veces dejan sus directorios accidentalmente
con permiso de escritura para cualquiera, el valor predeterminado es 'yes'. Por lo tanto lo dejaremos
con su valor predeterminado:

StrictModes yes

Y el ultimo de estas opciones es MaxAuthTries 6, esta opción especifica el máximo numero de

intentos de autenticación permitidos por conexión. Una vez que la intentos alcanza la mita de este
valor, las conexiones fallidas siguientes serán registradas. El valor predeterminado es 6.

MaxAuthTries 6
Ej: PermitRootLogin no
Mas opciones.

La primera linea especifica que se use autenticación RSA, y como arriba desactivamos las llaves
RSA para solo usar las DSA, entonces cambiaremos esta opción por:

RSAAuthentication no

Después esta: PubkeyAuthentication yes, la cual especifica el uso de autenticación por medio de
la llave publica, por lo pronto lo activaremos así:
PubkeyAuthentication yes

Y esta otra se usa en conjunto cuando se usa autenticación por llave publica, que especifica donde
se guardaran las llaves en el host remoto, el valor por default es ~/.ssh/authorized_keys esta ruta es
por default para el protocolo 2 de ssh, entonces la des comentaremos para hacerla explicita, así:

AuthorizedKeysFile .ssh/authorized_keys
Ahora proceda a dejar estas opciones tal cuales están marcadas, sea cuidadoso:
X11Forwarding.

Establece si se permite o no la ejecución remota de aplicaciones gráficas. Si se va a acceder hacia el

servidor desde red local, este parámetro puede quedarse con el valor YES. Si se va a permitir el
acceso hacia el servidor desde redes públicas, resultará prudente utilizar este parámetro con el valor
NO.

Ej: X11Forwarding yes

AllowUsers.

Permite restringir el acceso por usuario y, opcionalmente, anfitrión desde el cual pueden hacerlo. El
siguiente ejemplo restringe el acceso hacia el servidor SSH para que solo puedan hacerlo los
usuarios fulano y mengano, desde cualquier anfitrión.

Ej: AllowUsers fulano mengano

Otra forma de restringir el acceso de estos es añadiendoles la dirección del anfitrión.

Ej: AllowUsers fulano@X.X.X.X

Una vez hecho estos cambios debemos reiniciar el servicio, aun que es importante que sepa todas
las funciones de los comandos para este.

Para ejecutar por primera vez el servicio, utilice:

# service sshd start

Para hacer que los cambios hechos a la configuración surtan efecto, utilice:
# service sshd restart

Para detener el servicio, utilice:

# service sshd stop

Ahora es importante que el cortafuegos o Firewall tenga las excepciones correspondientes para que
este no bloque el servicio con nuestro servidor, por lo que deberá agregar:

Si se utiliza un cortafuegos con políticas estrictas, como por ejemplo Shorewall, es necesario abrir
el puerto 22 por UDP (SSH).

Las reglas para el fichero /etc/shorewall/rules de Shorewall correspondería a algo similar a lo

siguiente:

ACCEPT net fw tcp 22

Si la red de área local (LAN) va a acceder hacia el servidor recién configurado, es necesario abrir el
puerto correspondiente.

ACCEPT net fw tcp 22

ACCEPT loc fw tcp 22
¿Y como nos conectamos al servicio?

Para acceder a través de intérprete de mandatos hacia el servidor, basta con ejecutar desde el
sistema cliente el mandato ssh definiendo el usuario a utilizar y el servidor al cual conectar:

ssh usuario@servidor

Para acceder hacia un puerto en particular, se utiliza el parámetro -p. En el siguiente ejemplo,
utilizando la cuanta del usuario juan, se intentará acceder hacia el servidor con dirección IP
192.168.0.99, el cual tiene un servicio de SSH que responde peticiones a través del puerto 52341.

ssh -p 52341 juan@192.168.0.99

Otra forma de restringir el acceso de estos es añadiéndoles la dirección del anfitrión.

Ej: AllowUsers fulano@X.X.X.X

Una ves hecho estos cambios debemos reiniciar el servicio, aun que es importante que sepa todas
las funciones de los comandos para este.

Para ejecutar por primera vez el servicio, utilice:

# service sshd start
Para hacer que los cambios hechos a la configuración surtan efecto, utilice:
# service sshd restart

Para detener el servicio, utilice:

# service sshd stop

Ahora es importante que el cortafuegos o Firewall tenga las excepciones correspondientes para que
este no bloque el servicio con nuestro servidor, por lo que deberá agregar:

Si se utiliza un cortafuegos con políticas estrictas, como por ejemplo Shorewall, es necesario abrir
el puerto 22 por UDP (SSH).

Las reglas para el fichero /etc/shorewall/rules de Shorewall correspondería a algo similar a lo

siguiente:

ACCEPT net fw tcp 22

Si la red de área local (LAN) va a acceder hacia el servidor recién configurado, es necesario abrir el
puerto correspondiente.

ACCEPT net fw tcp 22

ACCEPT loc fw tcp 22

Al igual que cuando nos logueamos la primera ves como root nos dirá que al autenticidad del server
no puede ser establecida, nuevamente escriba yes y presione enter. Nuevamente nos hemos
conectados, pero esta vez no hemos terminado nuestra configuración.

Se asume que actualmente se encuentran logueado como "cliente".

El directorio $HOME de el usuario no debe de ser apto para escritura ni lectura por al­
guien mas de el grupo al que pertenece el usuario u otros, solo ejecución.

chmod 711 /home/Dzier

El directorio .ssh no debe de ser escribible y leible por alguien más de el grupo al que pertenece el
usuario u otros, solo ejecutable.

chmod 700 /home/Dzier/.ssh

Los archivos dentro de el directorio .ssh de el usuario deben de ser solamente con permisos de
lectura y escritura para el usaurio (rw).

cd .ssh
chmod 600 *

Bien, cumpliendo los requerimientos anteriores podemos seguir.

Lo primero es crear un par de llaves (publica/privada) DSA.

Como usuario ejecutar:

$ cd .ssh
usuario@cliente:~/.ssh$ ssh-keygen -t dsa
La primer pregunta que se hace es que elijamos el archivo donde se guardara la llave privada, por
default es /home/usuario/.ssh/id_dsa, puedes dar enter para usar ese archivo. Después se nos
solicita una frase de entrada, esta no debe de ser una simple contraseña, se recomienda usar una
frase larga y que sea alfanumérica, es decir, combinando Letras mayúsculas, minúsculas, números,
y hasta otros símbolos, se recomienda que sea mas de 10 caracteres.

Esta passphrase se debe de teclear dos veces para confirmarla.

Ahí dice que la llave privada se guardo en el archivo /home/usuario/.ssh/id_dsa y la llave publica
se guardo en el archivo /home/usuario/.ssh/id_dsa.pub, y al final se muestra tu huella digital para
esa llave.

Ahora hay que copiar nuestra llave publica a el servidor remoto, para asi poder autenticarnos con
ella, esta autenticación trabaja mas o menos así, copiamos la llave publica al servidor, la
comunicación solo se puede establecer por quien pueda descifrar la llave publica, y claro solo podrá
ser por quien tenga la llave privada y aparte solo se podrá usar la llave privada si se conoce el
passphrase con la que se creo, es por eso recomendable siempre

Usar un passphrase largo y difícil no dejarlo vacío, dicha llave debe de tener permisos de "rw" solo
para el dueño de dicha llave.

Entonces copiamos la llave publica al servidor remoto así:

usuario@cliente:~/.ssh$ ssh-copy-id -i id_dsa.pub usuario@servidor

En este paso se copio la llave publica con el comando ssh-copy-id, que le pasamos el parámetro -i y
el nombre de el archivo de la llave publica, y aparte el usuario y nombre de host a donde la íbamos
a copiar. Como vemos nos advirtió sobre la autenticidad de el host, y nos dice igual que siempre si
deseamos agregar la llave DSA, por lo que decimos que "yes".Después nos dice que ahora
probemos logearnos a la maquina usando el comando: "ssh usuario@servidor" y revisar que el
archivo ~/.ssh.authorized_keys exista, en ese archivo es donde se copio la llave publica, aunque el
mismo ssh-copy-id configura los permisos de ~/.ssh y los archivos que contiene de el servidor
remoto se recomienda comprobar que dicho directorio y archivo tenga los permisos adecuados,
como se hizo en el host local (cliente).
Entonces lo comprobaremos:

$ ssh usuario@servidor
Enter passphrase for key '/home/usuario/.ssh/id_dsa':
Linux 2.4.31.
usuario@servidor:~$
Conclusión

Vimos un paso a paso de la instalación y configuración de SSH, descubrimos su seguridad y

sencilla utilización.

Sirve para conectarnos con un ordenador ante el cual no estamos físicamente, bien porque está en
una sala de servidores refrigerada, bien porque no tiene teclado ni pantalla, por ejemplo los que
están apilados en un rack.

Es parecido a Telnet, con la gran diferencia de que en el caso de ssh, la información viaja codificada
con lo cual es muchísimo más segura, en el caso de conectarnos a un ordenador que esté en nuestra
LAN no es tan importante, pero si nos conectamos a través de Internet es fundamental, casi diría
que imprescindible, usar un protocolo seguro como SSH.

Para más informacion sobre ssh se recomienda leer la pagina del manual de sshd_config:
$ man sshd_config