PROTOCOLO SSH MARTA BENÍTEZ GONZÁLEZ JOSÉ GUTIÉRREZ BENÍTEZ

33 

Loading....

Loading....

Loading....

Loading....

Loading....

Texto completo

(1)

PROTOCOLO SSH

MARTA BENÍTEZ GONZÁLEZ

JOSÉ GUTIÉRREZ BENÍTEZ

(2)

CONTENIDO

Introducción

Características

Versiones del protocolo SSH

Secuencia de eventos de una conexión SSH

Archivos de configuración de OpenSSH

Más que un SHELL seguro

Requerir SSH para conexiones seguras

OpenSSH (servidor y cliente)

(3)

Introducción

SSH

permite a los usuarios registrarse en sistemas de host

remotamente.

Encripta la sesión de registro imposibilitando que alguien

pueda obtener contraseñas no encriptadas.

Está diseñado para reemplazar los métodos más viejos y

menos seguros para registrarse remotamente en otro

sistema a través de la shell de comando, tales como

telnet

(4)

Características (I)

SSH es un protocolo para crear conexiones seguras entre dos sistemas usando una arquitectura cliente/servidor. Proporciona los siguientes tipos de protección:

ƒ El cliente puede verificar que se está conectando al servidor al que se conectó inicialmente.

ƒ El cliente transmite su información de autenticación al servidor usando una encriptación robusta de 128 bits.

ƒ Todos los datos enviados y recibidos durante la conexión se transfieren por medio de encriptación de 128 bits, lo cual los hacen extremamente difícil de descifrar y leer.

ƒ El cliente tiene la posibilidad de enviar por X11 las aplicaciones lanzadas desde el intérprete de comandos del shell. Esta técnica

(5)

Características (II)

El servidor

SSH

puede convertirse en un conducto para

convertir en seguros los protocolos inseguros mediante el

uso de una técnica llamada reenvío por puerto, como por

ejemplo POP, incrementando la seguridad del sistema en

general y de los datos.

Muchas aplicaciones

SSH cliente

están disponibles para

casi todos los principales sistemas operativos en uso hoy

día.

(6)

¿Por qué usar SSH?

Las amenazas se pueden catalogar del siguiente modo:

‰ Intercepción de la comunicación entre dos sistemas

La parte interceptora puede interceptar y conservar la información, o puede modificar la información y luego enviarla al receptor al cual estaba destinada. Este ataque se puede montar a través del uso de un paquete sniffer una utilidad de red muy común.

‰ Personificación de un determinado host

Un sistema interceptor finge ser el receptor a quien está destinado un mensaje. Si funciona la estrategia, el cliente no se da cuenta del engaño y continúa la comunicación con el interceptor como si su mensaje hubiese llegado a su destino satisfactoriamente. Esto se produce con técnicas como el

(7)

Versiones del protocolo SSH

Existen dos variedades de SSH actualmente:

‰ La versión 1 de SSH

Hace uso de muchos algoritmos de encriptación patentados y es

vulnerable a un hueco de seguridad que potencialmente permite a un intruso insertar datos en la corriente de comunicación.

‰ La versión 2 de SSH

La suite OpenSSH bajo Red Hat Linux utiliza la versión 2 por defecto.

Importante

Se recomienda que sólo se utilicen servidores y clientes compatibles con la versión 2 de SSH siempre que sea posible.

(8)

Secuencia de eventos de una

conexión SSH

La siguiente serie de eventos ayudan a proteger la integridad de la comunicación:

Se lleva a cabo un 'handshake' encriptado para que el cliente pueda verificar que se está comunicando con el servidor correcto.

La capa de transporte entre el cliente y la máquina remota es encriptada mediante un código simétrico.

El cliente se autentica ante el servidor.

El cliente remoto puede interactuar con tranquilidad con la máquina remota.

(9)

Secuencia de eventos de una

conexión SSH

EJEMPL0 1

EJEMPL0 2

[root@localhost ksh]# ssh a2554@pracgsi.ulpgc.es a2554@pracgsi.ulpgc.es's password:

Last login: Fri May 7 20:39:08 2004 from 39.red-80-37-155.pooles.rima-tde.net [a2554@ftp0 a2554]$ ls

(10)

Capa de transporte (I)

El papel principal de la capa de transporte es facilitar una comunicación segura entre los dos hosts en el momento y después de la autenticación. Se lleva a cabo manejando la encriptación y decodificación de datos y proporcionando protección de los paquetes de datos.

Al contactar un cliente a un servidor, se negocian varios puntos importantes para que ambos sistemas puedan construir la capa de transporte correctamente. Se producen los siguientes pasos:

- Intercambio de claves

- Se determina el algoritmo de encriptación de la clave pública - Se determina el algoritmo de la encriptación simétrica

- Se determina el algoritmo autenticación de mensajes - Se determina el algoritmo de hash que hay que usar

(11)

Capa de transporte (II)

El servidor se identifica ante el cliente con una clave de host única durante el

intercambio de claves. OpenSSH permite que el cliente acepte la clave de host del servidor después que el usuario sea notificado y verifique la aceptación de la nueva clave del host. Para las conexiones posteriores, la clave de host del servidor se puede verificar con la versión guardada en el cliente, proporcionando la confianza que el cliente está realmente comunicando con el servidor deseado.

SSH fue ideado para funcionar con casi cualquier tipo de algoritmo de clave pública o formato de codificación. Después del intercambio de claves inicial se crea un valor hash usado para el intercambio y un valor compartido secreto.

Después que una cierta cantidad de datos haya sido transmitida con un determinado algoritmo y clave, ocurre otro intercambio de claves, el cual genera otro conjunto de valores de hash y un nuevo valor secreto compartido. De esta manera aunque un agresor lograse determinar los valores de hash y de secreto compartido, esta información sólo será válida por un período de tiempo limitado.

(12)

Autenticación

El servidor le dirá al cliente los diferentes métodos de autenticación soportados, tales como el uso de firmas privadas codificadas con claves o la inserción de una contraseña.

El cliente intentará autenticarse ante el servidor mediante el uso de cualquiera de los métodos soportados.

Luego, el servidor podrá decidir qué métodos de encriptación soportará basado en su pauta de seguridad, y el cliente puede elegir el orden en que intentará utilizar los métodos de autenticación entre las opciones a disposición.

(13)

Canales

Múltiples canales son abiertos a través de la técnica llamada multiplexar. Cada uno de estos canales manejan la conexión para diferentes sesiones de terminal y para sesiones X11.

Cada canal es asignado a un número diferente en cada punta de la conexión. Cuando el cliente intenta abrir un nuevo canal, los clientes envían el número del canal junto con la petición. Esto es hecho para que diferentes tipos de sesión no afecten una a la otra y así cuando una sesión termine, su canal pueda ser cerrado sin interrumpir la conexión SSH

primaria.

Los canales también soportan el control de flujo, el cual les permite enviar y recibir datos ordenadamente. De esta manera, los datos no se envían a través del canal sino hasta que el host haya recibido un mensaje avisando que el canal está abierto y puede recibirlos.

El cliente y el servidor negocian las características de cada canal automáticamente.

(14)

Archivos de configuración de

OpenSSH (I)

OpenSSH tiene dos conjuntos diferentes de archivos de configuración: uno para los programas cliente (ssh, scp, y sftp) y otro para el demonio del

servidor (sshd).

La información de configuración SSH para todo el sistema está almacenada en el directorio /etc/ssh/:

- Moduli. Contiene grupos Diffie-Hellman usados para el intercambio de la clave Diffie-Hellman. Cuando se intercambian las claves al inicio de una sesión SSH, se crea un valor secreto y compartido que no puede ser

determinado por ninguna de las partes individualmente. Este valor se usa para proporcionar la autentificación del host.

- ssh_config. Archivo de configuración del sistema cliente SSH por defecto que se sobreescribe si hay alguno ya presente en el directorio principal del usuario (~/.ssh/config).

(15)

Archivos de configuración de

OpenSSH (II)

- sshd_config. El archivo de configuración para el demonio sshd. - ssh_host_dsa_key. La clave privada DSA usada por el demonio sshd.

- ssh_host_dsa_key.pub. La clave pública DSA usada por el demonio sshd.

- ssh_host_key. La clave privada RSA usada por el demonio sshd para la versión 1 del protocolo SSH.

- ssh_host_key.pub. La clave pública RSA usada por el demonio sshd para la versión 1 del protocolo SSH.

- ssh_host_rsa_key. La clave privada RSA usada por el demonio sshd para la versión 2 del protocolo SSH.

- ssh_host_rsa_key.pub. La clave pública RSA usada por el demonio sshd para la versión 2 del protocolo SSH.

(16)

Archivos de configuración de

OpenSSH (III)

[a2554@ftp0 a2554]$ cd /etc/ssh [a2554@ftp0 ssh]$ ls

moduli ssh_host_dsa_key ssh_host_rsa_key.pub ssh_authorized_keys ssh_host_dsa_key.pub ssh_known_hosts ssh_authorized_keys2 ssh_host_key

ssh_known_hosts2 ssh_config ssh_host_key.pub sshd_config ssh_host_rsa_key

(17)

Archivos de configuración de

OpenSSH (IV)

La información específica para el usuario está almacenada en el directorio principal ~/.ssh/:

- authorized_keys. Este archivo que contiene una lista de claves públicas "autorizadas".

- id_dsa. Contiene la clave privada DSA del usuario.

- id_dsa.pub. Contiene la clave pública DSA del usuario.

- id_rsa. La clave RSA privada usada por ssh para la versión 2.

- id_rsa.pub. La clave pública RSA usada por ssh para la versión 2. - identity. La clave privada RSA usada por ssh para la versión 1. - identity.pub. La clave pública RSA usada por ssh para la versión 1. - known_hosts. Este archivo contiene las claves de host DSA de los

servidores SSH accesados por el usuario. Este archivo es muy importante para asegurarse de que el cliente SHH está conectado al servidor SSH correcto.

(18)

Archivos de configuración de

OpenSSH (V)

[a2554@ftp0 a2554]$ [root@localhost root]# cd .ssh [root@localhost .ssh]# ls known_hosts [root@localhost .ssh]# vi known_hosts 192.168.200.100 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAy3NfQ2Xy7aoTG/bZ0Jt5I5oqUf2ivaXMJpIKQGtmEp+XKc8FbhF BkrNK4dGY/WYoFsf8cjkXlVAy3xvLDVH0j0NQlSmNeEicP4e2ZHb2V0cGjztro4beSH5fJsahKYkb/aHW7n u84AMvgOCqlhLe5yOo8MC8JzYeM6nKSbdYEws=pracgsi.ulpgc.es,193.145.141.36 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA02iPpdqam5aSYKX37KrAOYT/RY+Ze1iRwI/8gYV+5obPgE7KV G3D+criLJcENU0Ywyg7WDuZrMjJLzekwDE37lR33IeaHQwvFwKOfzPXg0vOYJ/nXE9vX7aRIPXYus3pD WFeHr8Xg+gKvb689RtJIhXfOUZOL6BLCNRp0qwWtV0=~ ~ [root@localhost .ssh]#

(19)

Reenvío por X11

Abrir una sesión X11 a través de una conexión SSH establecida es tan fácil como ejecutar un programa X en una máquina local.

Cuando un programa X se ejecuta desde un intérprete de comandos de shell segura, el cliente y el servidor SSH crean un nuevo canal seguro dentro de la conexión SSH actual, y los datos del programa X se

envían a través de ese canal a la máquina cliente de forma transparente. El reenvío por X11 es muy útil. Por ejemplo, se puede usar para crear una sesión segura e interactiva con up2date. Para hacer esto, conéctese al servidor usando ssh y escriba:

up2date &

Se le pedirá proporcionar la contraseña de root para el servidor. Luego aparecerá el Agente de actualización de Red Hat y permitirá al usuario actualizar con seguridad el sistema remoto.

(20)

Reenvío del puerto

Con SSH se puede asegurar los protocolos TCP/IP a través del reenvío de puertos. Cuando se use esta técnica, el servidor SSH se convierte en un conducto encriptado para el cliente SSH.

El reenvío de puertos funciona mediante el mapeado de un puerto local en el cliente a un puerto remoto del servidor. Para crearlo, hay que utilizar el siguiente comando:

ssh -L local-port:remote-hostname:remote-port username@hostname

Ejemplo: Si desea comprobar su correo en el servidor llamado

mail.example.com usando POP a través de una conexión encriptada, use el comando siguiente:

(21)

Requerir SSH para conexiones

remotas

Para que SSH sea realmente eficaz, el uso de todos los protocolos de conexión inseguros como por ejemplo FTP y Telnet, deberían ser prohibidos. Algunos servicios a deshabilitar incluyen:

- telnet - rsh - ftp - rlogin - vsftpd

Para desactivar métodos de conexión inseguros al sistema, use el programa de línea de comandos chkconfig, el programa basado en

ncurses ntsysv, o la aplicación gráfica Herramienta de configuración de servicios (redhat-config-services). Todas estas herramientas

(22)

OpenSSH

OpenSSH

es una implementación gratuita y de código

libre de los protocolos

SSH

(

S

ecure

SH

ell).

Esto sustituye a

telnet

,

ftp

,

rlogin

,

rsh

, y

rcp

con

herramientas seguras y de conectividad de la red

encriptada.

OpenSSH soporta las versiones 1.3, 1.5, y 2 del protocolo

SSH.

(23)

¿Por qué usar OpenSSH?

Las utilidades

OpenSSH

, son más seguras, ya que en todas

las comunicaciones, incluyendo contraseñas, son

encriptadas

.

Telnet

y

ftp

utilizan contraseñas de texto plano y envían

toda la información sin encriptar.

Otra razón por la que se recomienda usar OpenSSH es que

automáticamente reenvía la variable

DISPLAY

a la

máquina cliente.

Es decir, si está ejecutando el sistema X Window en su

máquina local, e ingresa a una máquina remota usando el

comando

ssh

, cuando ejecute un programa en la máquina

remota que requiera X, será visualizado en su equipo local.

(24)

Configurar un servidor OpenSSH

El sistema debe tener los paquetes RPM instalados. Se requiere el paquete openssh-server que depende a su vez del paquete openssh. El demonio OpenSSH usa el archivo de configuración

/etc/ssh/sshd_config.

Por defecto, el archivo de configuración instalado es suficiente para numerosas configuraciones.

En la página del manual sshd existe una lista de palabras reservadas para configurar el servidor con nuestra propia configuración.

Para iniciar y parar un servicio OpenSSH, se usan los comandos:

„ /sbin/service sshd start.

(25)

Problemas de reinstalación

Si se reinstala un sistema Red Hat Linux, y clientes conectados a éste, antes de reinstalar con cualquiera de las herramientas OpenSSH, después de la

reinstalación, los usuarios del cliente verán el siguiente mensaje: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed.

El sistema reinstalado crea un nuevo conjunto de claves de identificación para el sistema; de ahí, el aviso de que la clave del host RSA ha cambiado.

Si se desea mantener las claves del host generadas para el sistema, se debe realizar una copia de seguridad de los archivos /etc/ssh/ssh_host*key* y restaurarlos después de reinstalar.

(26)

Configuración cliente OpenSSH

Uso del comando ssh (I)

Se deben tener los paquetes openssh-clients y openssh instalados en la máquina cliente.

El comando ssh permite iniciar sesiones y ejecutar comandos en máquinas remotas.

Para iniciar una sesión remota a una máquina llamada

penguin.example.net, se escribe el comando siguiente:

„ ssh penguin.example.net

La primera vez que ejecute ssh a una máquina remota, verá un mensaje similar al siguiente:

The authenticity of host 'penguin.example.net' can't be established.

(27)

Configuración cliente OpenSSH

Uso del comando ssh (II)

Si se acepta, permite agregar el servidor en su lista de host conocidos. Luego, se verá un indicador de comandos preguntando por la contraseña. Después de introducir la contraseña, nos encontraremos en el indicador de comandos de la máquina remota.

Si no se especifica un nombre de usuario, el nombre de usuario con el que se ha validado como la máquina local se validará en la máquina remota.

Si se quiere especificar un nombre de usuario se usa el comando siguiente:

„ ssh username@penguin.example.net

El comando ssh se puede utilizar para ejecutar un comando en una máquina remota sin acceder al indicador de comandos. La sintaxis es:

(28)

Configuración cliente OpenSSH

Uso del comando scp

El comando scp puede ser usado para transferir archivos entre máquinas sobre una conexión encriptada y segura.

La sintaxis general para transferir el archivo local a un sistema remoto es: „ scp localfile username@tohostname:/newfilename

localfile especifica la fuente, y username@tohostname:/newfilename

especifica el destino.

La sintaxis general para transferir un archivo remoto al sistema local es: „ scp username@tohostname:/remotefile /newlocalfile

remotefile especifica la fuente, y newlocalfile especifica el destino.

Se puede especificar múltiples archivos como las fuentes. Por ejemplo, para transferir el contenido del directorio /downloads a un directorio existente llamado uploads en la máquina remota penguin.example.net:

(29)

Configuración cliente OpenSSH

Uso del comando sftp

La utilidad

sftp

puede ser usada para abrir una sesión segura

interactiva de FTP.

Es similar a

ftp

excepto que ésta utiliza una conexión

encriptada segura.

La sintaxis general es:

„

Sftp username@hostname.com.

Una vez autentificado, podrá utilizar un conjunto de

comandos similar al conjunto utilizado por el comando

FTP

.

La utilidad

sftp

sólo está disponible en las versiones 2.5.0p1

(30)

Configuración cliente OpenSSH

Generar pares de claves RSA v2

Si no se quiere introducir la contraseña cada vez que se conecte a una máquina remota con ssh, scp, o sftp, se puede generar un par de claves de autorización. Para generar las claves de un usuario, se deben seguir los siguientes pasos para cada usuario:

1. Para generar un par de claves RSA para trabajar con la versión 2 del protocolo: „ ssh-keygen -t rsa

Aceptar la localización por defecto del archivo ~/.ssh/id_rsa.

Introducir una palabra de paso diferente de la contraseña de la cuenta y confirmarla introduciéndola nuevamente.

La clave pública se escribe en ~/.ssh/id_rsa.pub.

La clave privada está escrita en ~/.ssh/ id_rsa, y no debe ser facilitada a nadie.

2. Cambiar los permisos del directorio .ssh usando el comando chmod 755 ~/.ssh.

(31)

Configuración cliente OpenSSH

Generar pares de claves DSA v2

1. Para generar un par de claves DSA, se escribe el siguiente comando:

„ ssh-keygen -t dsa

Aceptar la localización por defecto del archivo ~/.ssh/id_dsa.

Introducir una palabra de paso diferente a la contraseña de la cuenta y confirmarla introduciéndola de nuevo.

La clave pública es escrita en ~/.ssh/id_dsa.pub.

La clave privada es escrita a ~/.ssh/ id_dsa.

2. Cambiar los permisos del directorio .ssh usando el comando chmod 755 ~/.ssh.

3. Copiar el contenido de ~/.ssh/id_dsa.pub a ~/.ssh/authorized_keys en la máquina en la cual quiere conectarse. Si el archivo

~/.ssh/authorized_keys no existe, puede copiar el archivo

(32)

Configuración cliente OpenSSH

Pares de claves RSA v1.3 y v1.5

1. Para generar un par de claves RSA se escribe el comando siguiente:

„ ssh-keygen -t rsa1

Aceptar la localización por defecto del archivo (~/.ssh/identity).

Introducir una palabra de paso diferente a la contraseña de la cuenta y confirmarla introduciéndola de nuevo.

La clave pública está escrita en ~/.ssh/identity.pub.

La clave privada está escrita en ~/. ssh/identity.

2. Cambiar los permisos del directorio .ssh y la clave con los comandos chmod 755 ~/.ssh y chmod 644 ~/.ssh/identity.pub.

3. Copiar los contenidos de ~/.ssh/identity.pub al archivo

~/.ssh/authorized_keys en la máquina a la cual se desea conectar. Si el archivo ~/.ssh/authorized_keys no existe, se puede copiarlo desde

(33)

Figure

Actualización...

Referencias

Actualización...

Related subjects :