Conexión cifrada usando SSH y OpenSSH


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.





Actualmente las Redes de Computadoras son los medios digitales más usados en todos los ámbitos de la sociedad para la transferencia de información. Normalmente estos medios se encuentran en redes públicas, por lo cual están expuestas a intervenciones de una u otra forma.

Cuando se realiza una conexión a un servidor remoto usando por ejemplo el comando telnet o ftp, el login(usuario) y password(contraseña) son transmitidos en la red de forma clara, lo cual representa un gran riesgo si llega a existir sobre la red un programa que capture la información, basándose en el modo promiscuo de las redes ethernet (comúnmente llamado sniffer), ocasionado obtener tanto el login como el password y pudiendo posteriormente irrumpir en el servidor con esta información.

Este tipo de problemáticas ha llevado al diseñode herramientas que permitan evitar estas situaciones siendo el caso de Secure Shell (ssh), desarrollado por Tatu Ylonen en la Universidad Tecnológica de Helsinki en Finlandia y OpenSSH, que nace del proyecto de un sistema operativo orientado con la filosofía de la seguridad en mente como lo es OpenBSD.

Secure Shell (SSH) es una solución basada en software que mantiene seguros los datos de la red. 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. SSH 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, SSH ofrece amplias posibilidades para la creación de túneles seguros, aparte de una variedad de métodos de autenticación. Parece cosa de locos, pero Secure Shell no es un shell. No es un interprete, historial de comandos, ni demás.

SSH provee fuerte autenticación y comunicación segura sobre un canal inseguro y nace como un reemplazo a los comandos telnet, ftp, rlogin, rsh, y rcp, los cuales proporcionan gran flexibilidad en la administración de una red, pero sin embargo, presenta grandes riesgos en la seguridad de un sistema. Adicionalmente, ssh provee seguridad para conexiones de servicios X Windows y envío seguro de conexiones arbitrarias TCP.

Secure Shell admite varios algoritmos de cifrado entre los cuales se incluyen:
Blowfish
3DES
IDEA
RSA

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

Fuentes Consultadas:
OpenSSH http://es.wikipedia.org/wiki/OpenSSH
WikiLearning http://www.wikilearning.com/servidor_openssh_en_windows_nt_2k_xp-wkc-4528.htm
OpenSSH http://www.openssh.com/es/index.html
Manual OpenSSH http://www.openssh.com/es/manual.html
Guía de OpenSSH http://www.lucianobello.com.ar/openssh/
Ficheros de configuración OpenSSH http://www.europe.redhat.com/documentation/rhl7.2/rhl-rg-es-7.2/s1-ssh-configfiles.php3
Departamento de Seguridad en cómputo. http://www.seguridad.unam.mx/doc/?ap=tutorial&id=112
Instalación y configuración OPENSSH en GNU/Linux http://www.fentlinux.com/web/?q=node/461
   
Fuentes de descargas:
GnuWin II http://gnuwin.epfl.ch/apps/openssh/es/index.html
   
Secure Shell cliente/servidor para sistemas Unix
Sitio FTP de Secure Shell http://ftp.ssh.com/pub/ssh
   

OpenSSH Cliente/Servidor para sistemas Unix

Sitio FTP de OpenSSH http://www.openssh.com/ftp.html
   
Secure Shell cliente para sistemas Windows
Sitio FTP de Secure Shell (Solo para clientes con protocolo SSH2) http://ftp.ssh.com/pub/ssh
   
Secure Shell cliente para sistemas Mac
Departamento de Seguridad en Cómputo ftp://ftp.seguridad.unam.mx/Herramientas/Mac/Comunicacion/Ssh1
   
Libros Impresos:
Sistemas operativos: Linux por Morril, Daniel L.

No a la PATENTE DE SOFTWARE

Recopilado y estructurado por:
Xombra




Otras noticias de interés:

No descuidemos la seguridad en los sistemas VoIP
Según un reciente debate en línea sobre temas de seguridad, los expertos coinciden en que falta muy poco para que los sistemas de Voice Over IP (VoIP), sean inundados de spam, se abran a los piratas informáticos, y sean derribados por los gusa...
Los «hackers», por una nueva ética de trabajo
Los «hackers», por una nueva ética de trabajo ...
Una web contra la censura en Internet
Amnistía Internacional celebró el domingo su 45 aniversario con el lanzamiento de una campaña global contra la censura estatal de Internet. ...
SMTPUtils - Herramienta para asegurar los servidores de correo electrónico
SMTPUtils es una herramienta de código abierto con proyección a ser una solución líder que sirva para asegurar los servidores de correo electrónico ante la amenaza del spam, virus y toda clase de programas malignos, empleando pruebas no dañinas...
Firefox, objetivo de un ataque scareware
Los usuarios de Firefox están siendo objetivo de los ciberdelincuentes ante el ataque scareware detectado y del que, por el momento, se desconoce su alcance. ...
Debilidad en certificación de proveedores cuestiona OpenID
Leo en kriptopolis.org una nota en la que cuestiona la seguridad en el OpenID. El administrador del sitio expone que desde los inicios del OpenID ha desconfiado y explica sus argumentos....
Cloud computing
El cloud computing, o la computación nube, es un nuevo concepto de la Web 2.0 que venimos sintiendo hace un tiempo y que está relacionado con el software de servicios alojados en la gran red de redes. Como ejemplo podemos nombrar a los muy conocido...
Actualización de seguridad de iTunes
Apple ha publicado la versión 9.0.1 que soluciona un grave problema de seguridad que sucedía si un usuario intentaba visualizar un archivo .pls especialmente manipulado. Esta nueva versión también soluciona otros problemas importantes y mejora la...
Se descubre una nueva vulnerabilidad en XP y Server 2003
Se ha encontrado un agujero de seguridad en el software de Microsoft que puede ser aprovechado para provocar ataques de denegación de servicio en determinadas aplicaciones. El problema ha sido descubierto por el suministrador de soluciones de seguri...
Informe sobre el EMAIL ANONIMO
Debido al ABUSO en el empleo de este servicio por parte de algunos usuarios, el servicio de envio de email anónimo que hasta el día de hoy se venia prestando sera SUSPENDIDO en forma indefinida....

Brindanos
un o una


Redes Sociales

Publicidad


Gana Bitcoins desde tu casa

Categorías


Planeta Vaslibre

Blog Roll




Nube de tags

  • anonimato
  • anonimo
  • antivirus
  • apache
  • blog
  • bsd
  • bug
  • centos
  • chrome
  • cifrada
  • cifrado
  • computer
  • conexion
  • debian
  • exploits
  • fedora
  • fice
  • firefox
  • forense
  • freebsd
  • gentoo
  • github
  • gnome
  • gnu
  • gpl
  • gtk
  • hack
  • hacking
  • hosting
  • informatica
  • internet
  • isos
  • libre
  • licencias
  • linux
  • linuxmint
  • lxde
  • micros
  • mint
  • mit
  • mozilla
  • mysql
  • noticia
  • opensource
  • openssh
  • pgp
  • php
  • sabayon
  • seguridad
  • ssh
  • system
  • tecnologia
  • thunar
  • thunderbird
  • tor
  • troyanos
  • tware
  • ubuntu
  • underground
  • usando
  • vaslibre
  • virus
  • viserproject
  • vivaldi
  • vulnerabilidades
  • web
  • website
  • windows
  • xanadu
  • xfce
  • xombra