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. Reali
zaremos paso a paso la instalación y configuración incluyendo medios visuales para u
na mejor comprensión. Finalmente concluiremos con pruebas de transferencia de arch
ivos a través de este protocolo.
SSH
Secure Shell, lo que podríamos traducir como “Interprete seguro de comandos”. Es un pr
otocolo de red que permite que el intercambio de datos entre dos dispositivos se
a fiable, esto se logra por medio del uso de un canal seguro. Es utilizado en Li
nux 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 perm
itir que la computadora alejada autentifique al usuario. Se utiliza típicamente pa
ra 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; p
uede transferir archivos usando los protocolos asociados de SFTP o de SCP. Utili
za el modelo Servidor – Cliente. Por defecto, escucha en el puerto estándar 22 de TC
P.
Historia
Al principio sólo existían los r-commands, que eran los basados en el programa rlogi
n, el cual funciona de una forma similar a telnet. La primera versión del protocol
o y el programa eran libres y los creó un finlandés llamado Tatu Ylönen, pero su licen
cia fue cambiando y terminó apareciendo la compañía SSH Communications Security, que l
o ofrecía gratuitamente para uso doméstico y académico, pero exigía el pago a otras empr
esas. En el año 1997 (dos años después de que se creara la primera versión) se propuso c
omo borrador en la IETF. A principios de 1999 se empezó a escribir una versión que s
e convertiría en la implementación libre por excelencia, la de OpenBSD, llamada Open
SSH.
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 med
io de comunicación vaya de manera no legible y ninguna tercera persona pueda descu
brir el usuario y contraseña de la conexión ni lo que se escribe durante toda la ses
ión. Es posible atacar este tipo de sistemas por medio de ataques de REPLAY y mani
pular 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 dar
le 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 usar
se gratuitamente-, o utilizar la variante OpenSSH, la cual tiene una licencia Op
enBSD la cual es totalmente gratis y que se encuentra en constante desarrollo. U
na ventaja en la instalación de SSH es que durante la instalación de CentOS o cualqu
ier distribución de linux al momento de habilitar las reglas del Firewall puede ac
tivarse las del SSH e instalar lo necesario para que este funcione, si no se pue
de instalar mediante el administrador de paquetes para luego configurarlo manual
mente. 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 nue
stro 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 de
l local host mediante los siguientes comandos: service ssh start inicia el servi
dor y note que se crearan las llaves necesarias para que nos podamos autenticar
en este. Luego ingrese ssh localhost para conectarnos localmente al servidor, no
te que la conexión dice que el servidor no puede ser establecida debido a que el s
ervidor no se puede autenticar, como estamos haciendo nuestra primera prueba y l
a conexión es segura escriba yes y luego presione enter. Note que luego de esto un
a llave (RSA) ha sido añadida a los host conocidos. Después de esto deberá entrar su p
assword de root.
Felicitaciones hemos logrado nuestra primera prueba exitosamente, si duda de est
o observe detenidamente el la ultima linea antes del ultimo prompt. Esta le indi
ca su ultimo log hecho con la hora especificada, a esto se le llama llavero. Aho
ra 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 potencialm
ente peligrosa, tanto que tendrá el poder para cambiar cualquier cosa en nuestro s
ervidor, es por eso que debemos editar el archivo /etc/ssh/sshd_config para hace
r que nuestra conexión sea segura y contenga algunas restricciones importantes. Pr
imero que nada hagamos un respaldo y luego procederemos a configurarlo.
Luego procedamos a editar el archivo, nosotros utilizaremos el comando gedit. Un
a 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 sacar
lo 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 qu
e sea nuestro cortafuegos dejarlo así representa una gran vulnerabilidad, ya que t
odos saben esto podrían escanear este y realizar o intentar un ataque que comprome
ta a nuestro servidor, por lo que debemos cambiarlo entre un rango de 1025 y 655
35, recuerde que este protocolo trabaja por TCP. Nota: debido a problemas en nue
stra 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 cone
ctarnos 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 c
ual a menos que trabaje con servicios antiguos. Considere que la versión 1 present
a 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 interfac
es del sistema. En algunos casos es posible que no se desee esto y se prefiera l
imitar 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 se
rvidor 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, ento
nces unas lineas están de más, o sea, las que son para el protocolo 1, y aquí aparte s
olo usaremos las llaves dsa de la versión 2, entonces eliminaremos unas lineas y d
es comentaremos otra, de manera que solo quede así: # HostKeys for protocol versio
n 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 qu
e quede así:
# Logging #obsoletes QuietMode and FascistLogging SyslogFacility AUTH LogLevel I
NFO Aquí se especifican los parámetros para el registro de eventos, SyslogFacility e
specifica el tipo de registros que hará, en este caso es AUTH, osea de las autenti
caciones 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 DE
BUG3 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 e
n el que desconectara a el usuario después de que no ha podido iniciar sesión satisf
actoriamente, si el valor es 0, no hay limite de tiempo para que un usuario se a
utentique, 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ét
odos 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 v
alor predeterminado es: 2m, o sea 120 segundos. Se descomentará y se dejara por de
fault:
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á pr
udente 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 usuario
s y el directorio $HOME de el usuario antes de aceptar la sesión. Esto es normalme
nte deseable porque algunos novatos algunas veces dejan sus directorios accident
almente con permiso de escritura para cualquiera, el valor predeterminado es 'ye
s'. 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 alcanz
a 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 desactivam
os 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 p
or 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, r
esultará 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 anfi
trión. Ej: AllowUsers fulano mengano Otra forma de restringir el acceso de estos e
s 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 prime
ra vez el servicio, utilice: # service sshd start Para hacer que los cambios hec
hos a la configuración surtan efecto, utilice: # service sshd restart Para detener
el servicio, utilice: # service sshd stop Ahora es importante que el cortafuego
s o Firewall tenga las excepciones correspondientes para que este no bloque el s
ervicio con nuestro servidor, por lo que deberá agregar: Si se utiliza un cortafue
gos con políticas estrictas, como por ejemplo Shorewall, es necesario abrir el pue
rto 22 por UDP (SSH). Las reglas para el fichero /etc/shorewall/rules de Shorewa
ll 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 ACCEPT net loc fw fw tcp tcp 2
2 22
¿Y como nos conectamos al servicio?
Para acceder a través de intérprete de mandatos hacia el servidor, basta con ejecuta
r 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 cua
nta del usuario juan, se intentará acceder hacia el servidor con dirección IP 192.16
8.0.99, el cual tiene un servicio de SSH que responde peticiones a través del puer
to 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 s
ervicio, 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 e
fecto, utilice: # service sshd restart Para detener el servicio, utilice: # serv
ice sshd stop
Ahora es importante que el cortafuegos o Firewall tenga las excepciones correspo
ndientes para que este no bloque el servicio con nuestro servidor, por lo que de
berá 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 fi
chero /etc/shorewall/rules de Shorewall correspondería a algo similar a lo siguien
te: 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 autenti
cidad del server no puede ser establecida, nuevamente escriba yes y presione ent
er. Nuevamente nos hemos conectados, pero esta vez no hemos terminado nuestra co
nfiguración. Se€asume€que€actualmente€se€encuentran€logueado€como€"cliente". El€directorio€
io€no€debe€de€ser€apto€para€escritura€ni€lectura€por€al guien€mas€de€el€grupo€al€que€perte
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. chmo
d 700 /home/Dzier/.ssh
Los archivos dentro de el directorio .ssh de el usuario deben de ser solamente c
on permisos de lectura y escritura para el usaurio (rw). cd .ssh chmod 600 * Bie
n, 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 l
lave privada, por default es /home/usuario/.ssh/id_dsa, puedes dar enter para us
ar 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 re
comienda que sea mas de 10 caracteres. Esta passphrase se debe de teclear dos ve
ces 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/.ss
h/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 autenticar
nos 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 s
olo 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. Ent
onces copiamos la llave publica al servidor remoto así: usuario@cliente:~/.ssh$ ss
h-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 archi
vo de la llave publica, y aparte el usuario y nombre de host a donde la íbamos a c
opiar. 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 usua
rio@servidor" y revisar que el archivo ~/.ssh.authorized_keys exista, en ese arc
hivo es donde se copio la llave publica, aunque el mismo ssh-copy-id configura l
os permisos de ~/.ssh y los archivos que contiene de el servidor remoto se recom
ienda comprobar que dicho directorio y archivo tenga los permisos adecuados, com
o se hizo en el host local (cliente).
Entonces lo comprobaremos: $ ssh usuario@servidor Enter passphrase for key '/hom
e/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 seguri
dad y sencilla utilización. Sirve para conectarnos con un ordenador ante el cual n
o 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 info
rmación viaja codificada con lo cual es muchísimo más segura, en el caso de conectarno
s a un ordenador que esté en nuestra LAN no es tan importante, pero si nos conecta
mos a través de Internet es fundamental, casi diría que imprescindible, usar un prot
ocolo seguro como SSH. Para más informacion sobre ssh se recomienda leer la pagina
del manual de sshd_config: $ man sshd_config