PROTOCOLO SSH

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 o rsh.

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 proporciona una
  interfaz gráfica segura (reenvío por X11).

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 envenenamiento del DNS o spoofing de IP.
• El cliente SSH y el servidor usan firmas
  digitales para verificar su identidad.
• Toda la comunicación entre los sistemas cliente y
  servidor es encriptada.

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_at_localhost ksh ssh a2554_at_pracgsi.ulpgc.es a
2554_at_pracgsi.ulpgc.es's password Last login Fri
May 7 203908 2004 from 39.red-80-37-155.pooles.
rima-tde.net a2554_at_ftp0 a2554 ls Acampada
mbox public_html
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_at_ftp0 a2554 cd /etc/ssh a2554_at_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_at_ftp0 a2554 root_at_localhost root cd
.ssh root_at_localhost .ssh ls known_hosts root_at_l
ocalhost .ssh vi known_hosts 192.168.200.100
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAy3NfQ2Xy7aoTG/
bZ0Jt5I5oqUf2ivaXMJpIKQGtmEpXKc8FbhFBkrNK4dGY/WYo
Fsf8cjkXlVAy3xvLDVH0j0NQlSmNeEicP4e2ZHb2V0cGjztro4
beSH5fJsahKYkb/aHW7nu84AMvgOCqlhLe5yOo8MC8JzYeM6nK
SbdYEwspracgsi.ulpgc.es,193.145.141.36 ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEA02iPpdqam5aSYKX37KrAOY
T/RYZe1iRwI/8gYV5obPgE7KVG3DcriLJcENU0Ywyg7WDuZ
rMjJLzekwDE37lR33IeaHQwvFwKOfzPXg0vOYJ/nXE9vX7aRIP
XYus3pDWFeHr8XggKvb689RtJIhXfOUZOL6BLCNRp0qwWtV0
root_at_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-portremote-hostnameremote-port
• username_at_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
• ssh -L 1100mail.example.com110
  mail.example.com

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 requieren acceso
  root.

22
OpenSSH

• OpenSSH es una implementación gratuita y de
  código libre de los protocolos SSH (Secure
  SHell).
• 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.
• Actualmente, OpenSSH, utiliza la versión 2, por
  defecto, el cual usa las claves RSA por defecto.

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.
• /sbin/service sshd stop.
• Es posible arrancar el demonio automáticamente en
  el momento de inicio.

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
• _at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at_
• _at_ WARNING REMOTE HOST IDENTIFICATION HAS
  CHANGED! _at_
• _at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at__at_
• 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_hostkey y restaurarlos después de
  reinstalar.
• Este proceso retiene la identidad del sistema, y
  cuando los clientes traten de conectarse al
  sistema después de la instalación, éstos no
  recibirán el mensaje de aviso.

26
Configuración cliente OpenSSHUso 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.
• DSA key fingerprint is 94683a3abcf39a9b01
  5db30738e2110c.
• Are you sure you want to continue connecting
  (yes/no)?

27
Configuración cliente OpenSSHUso 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_at_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
• ssh hostname command.
• Por ejemplo gt ssh penguin.example.net ls
  /usr/share/doc

28
Configuración cliente OpenSSHUso 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_at_tohostname/newfilename
• localfile especifica la fuente, y
  username_at_tohostname/newfilename especifica el
  destino.
• La sintaxis general para transferir un archivo
  remoto al sistema local es
• scp username_at_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
• scp /downloads/ username_at_penguin.example.net/upl
  oads/

29
Configuración cliente OpenSSHUso 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_at_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 de OpenSSH y superiores.

30
Configuración cliente OpenSSHGenerar 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.
• 3. Copiar el contenido de /.ssh/id_rsa.pub a
  /.ssh/authorized_keys en la máquina en la que se
  quiere conectar. Si el archivo /.ssh/authorized_k
  eys no existe, se puede copiar el archivo
  /.ssh/id_rsa.pub al archivo /.ssh/authorized_key
  s en la otra máquina.

31
Configuración cliente OpenSSHGenerar 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 /.ssh/id_dsa.pub al archivo
  /.ssh/authorized_keys en la otra máquina.

32
Configuración cliente OpenSSHPares 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 /.ssh/identity.pub al archivo
  /.ssh/authorized_keys en el equipo remoto.

33
FIN