Una sesión de Secure Shell típica

El daemon de Secure Shell (sshd) se inicia, normalmente, durante el inicio cuando los servicios de red se inician. El daemon escucha conexiones de clientes. Una sesión de Secure Shell empieza cuando el usuario ejecuta un comando ssh, scp o sftp. Un daemon sshd nuevo se bifurca para cada conexión entrante. Los daemons bifurcados manejan intercambio de claves, cifrado, autenticación, ejecución de comandos e intercambio de datos con el cliente. Estas características de la sesión son determinadas por archivos de configuración del lado del cliente y archivos de configuración del lado del servidor. Los argumentos de la línea de comandos pueden sustituir los valores de los archivos de configuración.

El cliente y el servidor deben autenticarse entre ellos. Tras una autenticación con éxito, el usuario puede ejecutar comandos de manera remota y copiar datos entre hosts.

Características de la sesión en Secure Shell

El comportamiento del lado del servidor del daemon sshd se controla mediante valores de palabra clave en el archivo /etc/ssh/sshd_config. Por ejemplo, el archivo sshd_config controla los tipos de autenticación que se permiten para acceder al servidor. El comportamiento del lado del servidor también se puede controlar mediante las opciones de línea de comandos cuando el daemon sshd se inicia.

El comportamiento en el lado del cliente está controlado por palabras clave de Secure Shell en este orden de prioridad:

• Opciones de línea de comandos

• Archivo de configuración del usuario, ~/.ssh/config

• Archivo de configuración de todo el sistema, /etc/ssh/ssh_config

Por ejemplo, un usuario puede sustituir el valor Ciphers de la configuración de todo el sistema, que prefiere aes128-ctr, especificando -c aes256–ctr,aes128-ctr,arcfour en la línea de comandos. Ahora se prefiere el primer cifrado, aes256–ctr.

Autenticación e intercambio de claves en Secure Shell

Los protocolos de Secure Shell, v1 y v2, admiten la autenticación de host y usuario de cliente, y la autenticación de host de servidor. Ambos protocolos implican el intercambio de claves criptográficas de sesión para la protección de sesiones de Secure Shell. Cada protocolo proporciona varios métodos de autenticación e intercambio de claves. Algunos métodos son opcionales. Secure Shell admite varios mecanismos de autenticación de clientes, como se muestra en la Tabla 19-1. Los servidores se autentican con claves públicas de host conocidas.

Para el protocolo v1, Secure Shell admite la autenticación de usuario con contraseñas. El protocolo también admite claves públicas y autenticación de usuario con claves públicas de host de confianza. La autenticación de servidor se realiza con una clave pública de host. Para el protocolo v1, todas las claves públicas son claves RSA. Los intercambios de claves de sesión implican el uso de una clave de servidor efímera que se regenera periódicamente.

Para el protocolo v2, Secure Shell admite la autenticación de usuario y la autenticación interactiva genérica, que, por lo general, involucra contraseñas. El protocolo también admite la autenticación con claves públicas de usuario y con claves públicas de host de confianza. Las claves pueden ser RSA o DSA. Los intercambios de claves de sesión constan de intercambios de claves efímeras Diffie-Hellman que se firman en el paso de autenticación de servidor. Además, Secure Shell puede usar credenciales GSS para la autenticación.

Adquisición de credenciales GSS en Secure Shell

A fin de utilizar la GSS-API para la autenticación en Secure Shell, el servidor debe tener credenciales de aceptador GSS-API y el cliente debe tener credenciales de iniciador GSS-API. Se admiten los mecanismos mech_dh y mech_krb5.

Para mech_dh, el servidor tiene credenciales de aceptador GSS-API si root ha ejecutado el comando keylogin.

Para mech_krb5, el servidor tiene credenciales de aceptador GSS-API cuando el principal host que corresponde al servidor tiene una entrada válida en /etc/krb5/krb5.keytab.

El cliente tiene credenciales de iniciador para mech_dh si se ha realizado una de las siguientes acciones:

• El comando keylogin se ha ejecutado.

• El módulo pam_dhkeys se utiliza en el archivo pam.conf.

El cliente tiene credenciales de iniciador para mech_krb5 si se ha realizado una de las siguientes acciones:

• El comando kinit se ha ejecutado.

• El módulo pam_krb5 se utiliza en el archivo pam.conf.

Para el uso de mech_dh en RPC seguro, consulte el Capítulo 16Uso de servicios de autenticación (tareas). Para el uso de mech_krb5, consulte el Capítulo 21Introducción al servicio Kerberos. Para obtener más información sobre los mecanismos, consulte las páginas del comando man mech(4) y mech_spnego(5).

Ejecución de comandos y reenvío de datos en Secure Shell

Una vez completada la autenticación, el usuario puede utilizar Secure Shell, generalmente, mediante la solicitud de un shell o la ejecución de un comando. Mediante las opciones del comando ssh, el usuario puede realizar solicitudes. Las solicitudes pueden incluir la asignación de un pseudo-tty, el reenvío de conexiones X11 o conexiones TCP/IP, o la habilitación de un programa de autenticación ssh-agent por medio de una conexión segura.

Los componentes básicos de una sesión de usuario son los siguientes:

1. El usuario solicita un shell o la ejecución de un comando, que inicia el modo de sesión.

   En este modo, los datos se envían o se reciben por medio del terminal en el lado del cliente. En el lado del servidor, los datos se envían por medio del shell o de un comando.

2. Cuando la transferencia de datos se completa, el programa de usuario finaliza.

3. Todos los reenvíos de X11 y de TCP/IP se detienen, excepto para las conexiones que ya existen. Las conexiones X11 y TCP/IP existentes permanecen abiertas.

4. El servidor envía un mensaje de estado de salida al cliente. Cuando todas las conexiones están cerradas, como los puertos reenviados que habían permanecido abiertos, el cliente cierra la conexión al servidor. A continuación, el cliente se cierra.