Instituto Profesional DUOC UC Ingeniera de Ejecucin en Informtica.

SSHInstalacin Configuracin

Nicols Briceo Gonzalo Soto

IntroduccinConoceremos a grandes rasgos SSH, su funcionamiento, historia y seguridad. Realizaremos paso a paso la instalacin y configuracin incluyendo medios visuales para una mejor comprensin. Finalmente concluiremos con pruebas de transferencia de archivos a travs de este protocolo.

SSHSecure Shell, lo que podramos 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.

FuncionamientoSSH usa una llave criptogrfica pblica para autenticar la computadora remota y permitir que la computadora alejada autentifique al usuario. Se utiliza tpicamente para registrarse en una mquina remota y para ejecutar comandos, pero tambin apoya el tunneling (creacin de tneles), 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 estndar 22 de TCP.

HistoriaAl principio slo existan los r-commands, que eran los basados en el programa rlogin, el cual funciona de una forma similar a telnet. La primera versin del protocolo y el programa eran libres y los cre un finlands llamado Tatu Ylnen, pero su licencia fue cambiando y termin apareciendo la compaa SSH Communications Security, que lo ofreca gratuitamente para uso domstico y acadmico, pero exiga el pago a otras empresas. En el ao 1997 (dos aos despus de que se creara la primera versin) se propuso como borrador en la IETF. A principios de 1999 se empez a escribir una versin que se convertira en la implementacin libre por excelencia, la de OpenBSD, llamada OpenSSH.

SeguridadSSH trabaja de forma similar a como se hace con telnet. La diferencia principal es que SSH usa tcnicas de cifrado que hacen que la informacin que viaja por el medio de comunicacin vaya de manera no legible y ninguna tercera persona pueda descubrir el usuario y contrasea de la conexin ni lo que se escribe durante toda la sesin. Es posible atacar este tipo de sistemas por medio de ataques de REPLAY y manipular as la informacin entre destinos.

Manos a la obraInstalando SSHLlegando a este paso slo tenemos 2 alternativas al momento de instalar SSH, usar su versin 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 estn 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 instalacin de SSH es que durante la instalacin de CentOS o cualquier distribucin 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 instalacin ni configuracin ya que se encuentra instalado pero faltara 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 continuacin.

4. Instalamos y luego verificamos si estos tienen alguna actualizacin.

Configuracin SSHUna vez lista la instalacin y actualizados lo paquetes del servicio procederemos abrir una terminal para levantar el servicio e ingresar como root a la conexin 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 conexin 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 conexin es segura escriba yes y luego presione enter. Note que luego de esto una llave (RSA) ha sido aadida a los host conocidos. Despus 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 conexin se ha cerrado.

Bien ahora como habr notado, o debe notar, que una conexin 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 conexin 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 funcin 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 podran 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 configuracin de las polticas 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 versin 1 presenta serias vulnerabilidades para el servidor, use la con precaucin.

ListenAddress.Por defecto, el servicio de SSH responder peticiones a travs de todas las interfaces del sistema. En algunos casos es posible que no se desee esto y se prefiera limitar el acceso slo a travs de una interfaz a la que slo 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 versin 2, entonces unas lineas estn de ms, o sea, las que son para el protocolo 1, y aqu aparte solo usaremos las llaves dsa de la versin 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 estn comentadas, las haremos explicitas des comentando algunas para que quede as:

# Logging #obsoletes QuietMode and FascistLogging SyslogFacility AUTH LogLevel INFO Aqu se especifican los parmetros 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 parmetro AUTH es el predeterminado. En LogLevel INFO es el valor predeterminado, otros parmetros estn especificados en la pagina del manual de sshd_config (man sshd_config), los parmetros 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.

Autenticacin.La primera opcin es: LoginGraceTime 2m, esto le dice al servidor sshd el tiempo en el que desconectara a el usuario despus de que no ha podido iniciar sesin 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 podran hacer ataques de fuerza bruta, o usando mtodos de diccionario y as adivinar la contrasea (estos mtodos son muy comunes ltimamente, yo a diario recibo desde 300, 500 y el mximo 2000 intentos a diario) por lo tanto no es recomendable dejar este parmetro 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 pblicas, resultar prudente utilizar este parmetro 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 sesin. 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 opcin especifica el mximo numero de intentos de autenticacin permitidos por conexin. Una vez que la intentos alcanza la mita de este valor, las conexiones fallidas siguientes sern registradas. El valor predeterminado es 6. MaxAuthTries 6 Ej: PermitRootLogin no

Mas opciones.La primera linea especifica que se use autenticacin RSA, y como arriba desactivamos las llaves RSA para solo usar las DSA, entonces cambiaremos esta opcin por:

RSAAuthentication noDespus esta: PubkeyAuthentication yes, la cual especifica el uso de autenticacin por medio de la llave publica, por lo pronto lo activaremos as:

PubkeyAuthentication yesY esta otra se usa en conjunto cuando se usa autenticacin 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 estn marcadas, sea cuidadoso:

X11Forwarding.Establece si se permite o no la ejecucin remota de aplicaciones grficas. Si se va a acceder hacia el servidor desde red local, este parmetro puede quedarse con el valor YES. Si se va a permitir el acceso hacia el servidor desde redes pblicas, resultar prudente utilizar este parmetro con el valor NO. Ej: X11Forwarding yes

AllowUsers.Permite restringir el acceso por usuario y, opcionalmente, anfitrin 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 anfitrin. Ej: AllowUsers fulano mengano Otra forma de restringir el acceso de estos es aadiendoles la direccin del anfitrin. 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 configuracin 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 polticas estrictas, como por ejemplo Shorewall, es necesario abrir el puerto 22 por UDP (SSH). Las reglas para el fichero /etc/shorewall/rules de Shorewall correspondera a algo similar a lo siguiente: ACCEPT net fw tcp 22

Si la red de rea local (LAN) va a acceder hacia el servidor recin configurado, es necesario abrir el puerto correspondiente. ACCEPT ACCEPT net loc fw fw tcp tcp 22 22

Y como nos conectamos al servicio?Para acceder a travs de intrprete 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 parmetro -p. En el siguiente ejemplo, utilizando la cuanta del usuario juan, se intentar acceder hacia el servidor con direccin IP 192.168.0.99, el cual tiene un servicio de SSH que responde peticiones a travs del puerto 52341. ssh -p 52341 juan@192.168.0.99

Otra forma de restringir el acceso de estos es aadindoles la direccin del anfitrin. 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 configuracin 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 polticas estrictas, como por ejemplo Shorewall, es necesario abrir el puerto 22 por UDP (SSH). Las reglas para el fichero /etc/shorewall/rules de Shorewall correspondera a algo similar a lo siguiente: ACCEPT net fw tcp 22

Si la red de rea local (LAN) va a acceder hacia el servidor recin 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 configuracin. Seasumequeactualmenteseencuentranlogueadocomo"cliente". Eldirectorio$HOMEdeelusuarionodebedeseraptoparaescrituranilecturaporal guienmasdeelgrupoalqueperteneceelusuariouotros,soloejecucin. chmod 711 /home/Dzier El directorio .ssh no debe de ser escribible y leible por alguien ms 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. Despus se nos solicita una frase de entrada, esta no debe de ser una simple contrasea, se recomienda usar una frase larga y que sea alfanumrica, es decir, combinando Letras maysculas, minsculas, nmeros, y hasta otros smbolos, 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 autenticacin trabaja mas o menos as, copiamos la llave publica al servidor, la comunicacin 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 difcil no dejarlo vaco, dicha llave debe de tener permisos de "rw" solo para el dueo 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 parmetro -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".Despus 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:~$

ConclusinVimos un paso a paso de la instalacin y configuracin de SSH, descubrimos su seguridad y sencilla utilizacin. Sirve para conectarnos con un ordenador ante el cual no estamos fsicamente, bien porque est en una sala de servidores refrigerada, bien porque no tiene teclado ni pantalla, por ejemplo los que estn apilados en un rack. Es parecido a Telnet, con la gran diferencia de que en el caso de ssh, la informacin viaja codificada con lo cual es muchsimo ms segura, en el caso de conectarnos a un ordenador que est en nuestra LAN no es tan importante, pero si nos conectamos a travs de Internet es fundamental, casi dira que imprescindible, usar un protocolo seguro como SSH. Para ms informacion sobre ssh se recomienda leer la pagina del manual de sshd_config: $ man sshd_config