La ventaja más significativa de ssh es que no modifica mucho las rutinas. En todos los aspectos, iniciar una sesión de ssh es tan sencillo como( y similar a) iniciar una sesión de telnet. Tanto el intercambio de llaves, la autenticación, así como el posterior cifrado de sesiones son transparentes para los usuarios.
OpenSSH es una versión LIBRE del paquete de herramientas de comunicación segura del protocolo SSH/SecSH para redes, una solución de seguridad que está ganando la confianza de un número cada vez mayor de usuarios de Internet. Muchos usuarios de telnet, rlogin, ftp y otros programas parecidos, no se dan cuenta que sus contraseñas se están transmitiendo sin cifrar a través de la red. OpenSSH cifra todo el tráfico (incluidas las contraseñas) para eliminar de un modo efectivo las «escuchas», los secuestros de las conexiones y otros ataques a nivel de red. Además, OpenSSH ofrece amplias posiblidades para la creación de túneles seguros, aparte de una variedad de métodos de autenticación.
SSH es un protocolo que permite establecer conexiones seguras a través de redes que no lo son, además es capaz de servir de túnel seguro para otros protocolos que no lo son. Podemos entonces realizar tareas de mantenimientos de sistemas y conexiones remotas al estilo UNIX de forma segura.
SSH2, la segunda versión de SSH, resuelve algunas de las deficiencias de su antecesor SSH1, ofreciendo de esta manera un alto nivel de cifrado de datos y un método de autentificación bastante fiable. Es además una alternativa fiable a los no seguros: telnet o rlogin, rsh, rcp, rdist
Pero sí hace cosas muy útiles por la seguridad de un sistema en entornos poco confiables. Algunas "features":
Protocolo criptográfico en un modelo cliente/servidor
Autenticación de las más variadas formas:
por contraseña
por host
por sistema de llaves
Integración con sistemas de autenticación como:
Kerberos
SecurID
PGP
TIS Gauntlet
PAM
Seguriza los protocolos de aplicación de manera (casi) transparente
Implementación sobre la mayoría de los sistemas operativos y plataformas
Secure Shell previene, además, de una serie de ataques como los procedentes de Sniffers:
IP Spoofing
MACpoofing
DNS Spoofing
Telnet Hickjacking
ARP Spoofing
IP Routing Spoofing
ICMP Spoofing
Nos puede servir también para crear canales o túneles seguros para otras aplicaciones como correo, VNC, ftp, etc.
Pasos para su instalación y configuración
Instalando el paquete OpenSSH para MS-Windows
Descargar el paquete *.ZIP desde aquí (OpenSSH for Windows v3.4-3).
Creación de un par de llaves / claves
Para crear un par de claves DSA, acceder al directorio base de OpenSSH mediante la línea de mandatos y ejecutar:
ssh-keygen -d -f c:\ssh\ssh_host_dsa_key -N ""
Para crear un par de claves RSA, ejecute el mandato:
ssh-keygen -f c:\ssh\ssh_host_key -N ""
En estos ejemplos se ha utilizado el directorio C:\ssh como directorio base, por lo que si utiliza un directorio base distinto habrá que reemplazar este dato en el ejemplo. Serán generadas por defecto pares de claves de 1.024 bits, en principio, suficientemente seguras.
Variables de entorno
Mi PC -> Propiedades -> Avanzado -> Variables de Entorno ->
Añadir al path el valor del la ruta donde se encuentra OpenSSH por ejemplo:
C:\Archivos de programa\Exceed.nt;C:\Archivos de programa\Archivos comunes\Autodesk Shared\;C:\OpenSSH
Mi PC > Propiedades > Avanzado > Variables de Entorno >
Crear una nueva variable del sistema:
Variable: HOME
Valor : C:\OpenSSH (o la ruta donde se encuentre OpenSSH)
Creación de los archivos passwd y group
Dentro de la carpeta /bin se encuentran los programas mkpasswd y mkgroup para crear usuarios/grupos que servirán para la autentificación. Una vez realizada la autentificación en Cygenwin, este transfiere la solicitud de autentificación a Windows 2000 para la comprobación de contraseñas en el SAM (Administrador de cuentas de seguridad) local y después en la base de datos del dominio si este existe. Con lo cual ,los usuarios creados con passwd deben ser tambien usuarios creados en el sistema.
mkpasswd -l -u username >> ..\etc\passwd
mkgroup -l >> ..\etc\group
reemplazaremos username por el nombre de usuario que debe existir en Windows 2000 y -l por -d si estamos en un dominio.
Para ver los usuarios del sistema donde queremos configurar OpenSSH:
C:\OpenSSH\bin>mkpasswd -l
SYSTEM:*:18:544:,S-1-5-18::
Administradores:*:544:544:,S-1-x-32-544::
Administrador:unused_by_nt/2000/xp:500:513:U-INFOGRAFIA3\Administrador,S-
Ejemplo de creación de usuario/grupo:
C:\OpenSSH\bin>mkpasswd -d -u INFOGRAFIA3 >> ..\etc\passwd
C:\OpenSSH\bin>mkgroup -d >> ..\etc\group
Restricción de usuarios
Para que sólo algunos usuarios puedan conectarse via SSH al servidor, agregar la siguiente línea en /etc/sshd_config:
AllowUsers
Está también permitido aceptar grupos de usuarios. Se hace con AllowGroups.
C:\net start opensshd
Conexión con el servidor OpenSSH
Para conectarse al servidor OpenSSH desde un cliente Windows podemos usar PuTTY, un cliente de Telnet y de SSH «libre» para la interoperación con OpenSSH desde sistemas Windows: http://gnuwin.epfl.ch/apps/putty/es/
Para conectarse desde una shell en modo MSDOS:
ssh usuario@servidor
Seguridad
Es necesario asignar permisos a las carpetas par que sólo los usuarios que queramos puedan acceder a ellas.
Siempre que sea posible, conceder el acceso remoto sólo a los administradores.
Sólo la cuenta LocalSystem y el grupo local «Administradores» deben tener acceso a los directorios \ssh, \var y \etc.
Si aparece en pantalla un mensaje de advertencia del cliente SSH para comunicarle que la clave de host del servidor OpenSSH ha cambiado y no se trata de la primera vez que establece conexión con dicho servidor, averigüe cuál es la causa.
Utilice SSH1 exclusivamente cuando existan clientes más antiguos que utilicen dicha versión de SSH.
Anexos
I) Algunos parámetros de ssh_config
Ficheros de configuración OpenSSH
OpenSSH tiene dos conjuntos diferentes de ficheros de configuración, uno para los programas del cliente (ssh, scp, y sftp) y el otro para los servicios del servidor (sshd), ubicados en dos sitios diferentes.
La información de configuración SSH para todo el sistema está almacenada en el directorio /etc/ssh:
primes — contiene grupos Diffie-Hellman que sirven para el intercambio de claves Diffie-Hellman. Fundamentalmente, este intercambio de claves crea un valor de secreto compartido que ninguna de las partes puede determinar sola y se usa para proporcionar la autenticación del host. Este fichero es esencial para la construcción de una capa de transporte segura.
ssh_config — el fichero de configuración de cliente SSH para todo el sistema se usa para dirigir al cliente SSH. Si un usuario tiene su propio fichero de configuración a disposición en su directorio de inicio (~/.ssh/config), sus valores predominarán sobre los valores almacenados en /etc/ssh/ssh_config.
sshd_config — el fichero de configuración para sshd.
ssh_host_dsa_key — la clave privada DSA usada por sshd.
ssh_host_dsa_key.pub — la clave pública DSA usada por sshd.
ssh_host_key — la clave privada RSA usada por sshd para la versión 1 del protocolo SSH.
ssh_host_key.pub — la clave pública RSA usada por sshd para la versión 1 del protocolo SSH.
ssh_host_rsa_key — la clave privada RSA usada por sshd para la versión 2 del protocolo SSH.
ssh_host_rsa_key.pub — la clave pública RSA usada por sshd para la versión 2 del protocolo SSH.
La información para la configuración SSH específica para el usuario está almacenada en el directorio de inicio del usuario dentro del subdirectorio .ssh:
authorized_keys2 — el fichero que contiene una lista de claves públicas "autorizadas". Si un usuario que se conecta puede comprobar que conoce la clave privada que corresponde a cualquiera de las claves públicas, entonces será autenticada. Note que esto es sólo un método de autenticación opcional.
id_dsa — contiene la identidad de autenticación DSA del usuario.
id_dsa.pub — la clave pública DSA del usuario.
id_rsa — La clave pública RSA usada por sshd para la versión 2 del protocolo SSH.
identity — La clave privada RSA usada por sshd para la versión 1 del protocolo SSH.
known_hosts2 — almacena las claves de host DSA de los servidores a los cuales los usuarios dan inicio a una sesión por medio de SSH cuando el usuario decide guardarlas. Si a un servidor se le modifican las claves de host en modo legítimo, tal vez a la hora de reinstalar Red Hat Linux el usuario recibirá un aviso que la clave de host almacenada en el fichero known_hosts2 que debería corresponder con este host no corresponde. Entonces el usuario debe borrar esa clave de host en known_hosts para poder almacenar la clave de host nueva para ese sistema. El fichero known_hosts2 es muy importante para asegurar que el cliente se esté conectando con el servidor correcto. Si ha cambiado una clave de host, y usted no está perfectamente seguro el motivo por el que ha sido cambiada, entonces debería contactar el administrador de sistema del host para asegurarse que el host no haya sido expuesto a peligro.
(Algunos parámetros de ssh_config: sacado de http://www.tau.org.ar/base/
Port 22
# se ejecuta en el puerto 22,
ListenAddress 0.0.0.0
# escucha en todos los interfaces
HostKey /etc/ssh/ssh_host_key
# dónde se encuentra la llave del host
RandomSeed /etc/ssh/ssh_random_seed
# dónde se encuentra la simiente aleatoria
ServerKeyBits 768
# durante cuanto tiempo dura la llave del servidor
LoginGraceTime 300
# cuánto tiempo se tiene para introducir las credenciales
KeyRegenerationInterval 3600
# cada cuánto tiempo se regeneran las llaves del servidor
PermitRootLogin no
# permitir hacer login al root
IgnoreRhosts yes
# ignorar los ficheros .rhosts de los usuarios
StrictModes yes
# para asegurarse de que los usuarios no hacen tonterías
QuietMode no
# Si es sí no hace log de nada. Queremos hacer log de logins/etc.
X11Forwarding no
# ¿reenviar X11? no habría por qué en un servidor
FascistLogging no
# quizás no querramos hacer demasiado log
PrintMotd yes
# mostrar el mensaje del día? Siempre está bien
KeepAlive yes
# se asegura de que las sesiones se desconectan correctamente
SyslogFacility DAEMON
# ¿quién está haciendo el logging?
RhostsAuthentication no
# la autentificación está usando rhosts o /etc/hosts.equiv No está
# en mi mente. Por defecto es sí, de modo que se desactiva.
RSAAuthentication yes
# permitir autentificación RSA pura? Es bastante segura
PasswordAuthentication yes
# permitir a los usuarios que utilicen su login/contraseña habitual?
# Por qué no.
PermitEmptyPasswords no
# permitir cuentas con contraseñas vacias? no
Otras directivas sshd_conf útiles incluyen:
AllowGroups — permitir a grupos explícitamente (/etc/group) hacer login utilizando ssh
DenyGroups — deshabilitar explícitamente hacer login a grupos (/etc/groups)
DenyUsers — bloquear explícitamente a los usuarios el hacer login
AllowHosts — permitir ciertos hosts, al resto se les denegará
DenyHosts — bloquea ciertos hosts, al resto se les permitirá
IdleTimeout time — tiempo en minutos/horas/días/etc, que fuerza un logout haciendo un SIGHUP del proceso
II) Sobre las claves públicas
ssh_host_dsa_key — la clave privada DSA usada por sshd.
ssh_host_dsa_key.pub — la clave pública DSA usada por sshd.
ssh_host_key — la clave privada RSA usada por sshd para la versión 1 del protocolo SSH.
ssh_host_key.pub — la clave pública RSA usada por sshd para la versión 1 del protocolo SSH.
ssh_host_rsa_key — la clave privada RSA usada por sshd para la versión 2 del protocolo SSH.
ssh_host_rsa_key.pub — la clave pública RSA usada por sshd para la versión 2 del protocolo SSH.
Instalación y configuración OPENSSH en GNU/Linux
Algunas veces es necesario administrar de forma remota un servidor y para ello debemos establecer una comunicación segura entre dicho host y el sistema desde el cual establecemos la conexión. Las sesiones telnet no ofrecen mucha seguridad, ya que los datos viajan a traves de la red sin ningún tipo de encriptamiento y son potencialmente supceptibles de ser interceptadas por un atacante, asi que como mejor metodo posible a nuestro alcance tenemos OpenSSH.
Gracias a OpenSSHvamos a poder ejecutar un servidor de shell seguro y al mismo tiempo podernos conectar a él mediante un cliente también seguro, de forma que la comunicación quede blindada por ambos extremos.
Bien, para poder usar correctamente OpenSSH y que la comunicación quede totalmente cifrada, hemos de instalar primero OpenSSL, que proporciona las bibliotecas Secure Socket Layer o Capa de Conectores Segura ( SSL ). Podemos instalar OpenSSL desde los cds de la distribución o bien compilar su codigo fuente ( representaremos la linea de comandos con el simbolo # ):
# tar -zxvf openssl-númerodeversión.tar.gz
# cd openssl/
# ./configure
# make
# make install
Ya tenemos instalado OpenSSL, ahora le toca el turno a OpenSSH. Igualmente podemos instalar los paquetes precompilados que vienen con nuestra distribución o bien compilar las fuentes:
# tar -zxvf openssh-númerodeversión.tar.gz
# cd openssh/
# ./configure –with-ssl-dir=/usr/local/ssl
( nota: la ubicación de ssl puede variar en función de la distribución o de si se ha compilado o instalado mediante paquetes RPM )
# make
# make install
Ahora arrancamos el servidor SSH:
# /etc/init.d/ssh start
Starting SSH daemon done
E intentamos conectarnos al puerto 22 de nuestro sistema:
# ssh localhost
root@localhost's password:
Last login: Tue Nov 23 15:29:31 2004 from localhost
Have a lot of fun...
linux:~ #
Como podemos ver en el ejemplo nos hemos podido conectar como el usuario root, esto es perfectamente seguro ya que la comunicación va totalmente encriptada, pero si quisiéramos cambiar esto deberíamos editar /etc/ssh/sshd_config y añadir:
PermitRootLogin no
Puede ser que ya exista en dicho archivo una linea que diga PermitRootLogin yes , si existe y está comentada, añadiremos la nuestra y si no lo está cambiaremos el yes por el no.
Este tipo de autenticación como podemos ver se basa en en el intercambio de una pareja usuario-contraseña, pero podemos acrecentar todavía mas la seguridad si añadimos un par de claves publica y privada, ¿con que fin?, muy sencillo, dicho mecanismo ofrece la seguridad al cliente ssh que se está conectando de que el servidor es el autentico y no el de un posible intruso. Si ello ocurriera aparecería un mensaje en la pantalla advirtiéndonos de que no se puede comprobar la autenticidad del servidor y se nos pregunta si aceptamos continuar la sesión a pesar de dicha circunstancia.
# ssh localhost
The authenticity of host 'localhost (::1)' can't be established.
RSA key fingerprint is 74:4e:7c:2b:ee:18:ca:5a:e4:55:1c:bd:dc:72:dd:7e.
Are you sure you want to continue connecting (yes/no)?/i>
Para generar las claves actuaremos de la manera siguiente como root:
# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
fa:3a:7b:65:73:1b:20:ec:4e:3e:23:80:17:5c:52:60 root@linux
Los posibles valores de -t son rsa1 para la versión 1 del protocolo y rsa y dsa para la 2. Elegiremos la versión 2 por ser mas segura.
Cuando ya tenemos las claves solo hemos de proporcionar la clave pública al cliente y que este la añada a su fichero known_hosts, situado en el directorio .ssh de su /home.
# ssh localhost
usuario@localhost's password:
Last login: Thu Nov 25 15:01:06 2004 from localhost
Have a lot of fun...
Un último apunte, al intentar hacer login podemos indicar el usuario con el que queremos acceder al sistema:
# ssh -l root localhost
root@localhost's password:
Last login: Thu Nov 25 15:09:10 2004 from localhost
Have a lot of fun...
Y por supuesto, para salir de una sesión ssh y al igual que haríamos en la terminal de nuestro propio sistema, teclearíamos:
# exit
Cap comentari:
Publica un comentari a l'entrada