Conexión cifrada usando SSH y OpenSSH (página 2)

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 (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:sshssh_host_dsa_key -N ""
Para crear un par de claves RSA, ejecute el mandato:

ssh-keygen -f c:sshssh_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 programaExceed.nt;C:Archivos de
programaArchivos comunesAutodesk 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 >> ..etcpasswd
mkgroup -l >> ..etcgroup

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:OpenSSHbin>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-INFOGRAFIA3Administrador,S-1-5-21-682003330-10600084298-49167539-500:/home/Administrador:/bin/switch

Ejemplo de creación de usuario/grupo:

C:OpenSSHbin>mkpasswd -d -u INFOGRAFIA3 >>
..etcpasswd
C:OpenSSHbin>mkgroup -d >> ..etcgroup

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 <user1> <user2> …
Está también permitido aceptar grupos de usuarios. Se
hace con AllowGroups.

Arrancar el
servicio

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.

Algunas reglas
importantes

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/computacion/gsal-19991128-htm/ssh.htm)

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

Bibliografía

–
http://www.forosdelweb.com/f20/servidor-openssh-windows-2k-vnc-164603/ 
(11/11/2003) Autor: Alfon.

– http://webs.ono.com/alfonn/openssh.htm

Xombra