El principio, composición, método de autenticación y proceso del protocolo SSH
OpenSSH es una implementación gratuita y de código abierto del protocolo SSH (Secure Shell). La serie de protocolos SSH se puede utilizar para control remoto o transferencia de archivos entre computadoras. Las formas tradicionales de implementar esta función, como telnet (protocolo de emulación de terminal), rcp ftp, rlogin, rsh, etc., son extremadamente inseguras y la contraseña se transmitirá en texto claro. OpenSSH proporciona un demonio del lado del servidor y herramientas del lado del cliente para cifrar datos durante el control remoto y la transferencia de archivos, reemplazando así los servicios similares originales.
En el pasado, usábamos rsh y telnet, porque los datos, incluido el ID y la contraseña, no se cifraban ni se transmitían a la red durante el inicio de sesión, lo que causaba problemas de seguridad. Incluso dentro de una intranet, existen peligros como el robo y la manipulación de la red. SSH cifra todos los datos, incluidas las contraseñas, para operaciones remotas más seguras. En SSH, debido a los diferentes estándares de protocolo, existen dos versiones diferentes, SSH1 y SSH2. SSH2 se desarrolló para evitar problemas de licencia con el algoritmo de cifrado utilizado por SSH1 (que ya no existe). Como aplicación que instala el protocolo SSH, TLES 8 utiliza el código abierto OpenSSH. OpenSSH puede corresponder a cualquier protocolo de SSH1 y SSH2, pero SSH2 se usa de forma predeterminada.
SSH consta principalmente de tres partes:
Al mismo tiempo, el marco del protocolo SSH también proporciona soporte ampliado para muchos protocolos avanzados de aplicaciones de seguridad de red. La relación jerárquica entre ellos se puede representar mediante el siguiente diagrama:
Para un protocolo como SSH que tiene como objetivo proporcionar una comunicación segura, un mecanismo de claves completo es esencial. Dado que el protocolo SSH está orientado al acceso y al intercambio de información entre hosts en la red de Internet, la clave del host se convierte en el mecanismo de clave básico. En otras palabras, el protocolo SSH requiere que cada host que utilice el protocolo tenga al menos un par de claves de host propio, y el proveedor de servicios solo puede permitir la solicitud de conexión del cliente después de autenticar su clave de host. Un host puede usar varias claves y puede haber diferentes claves para diferentes algoritmos de claves, pero se requiere al menos una, es decir, la clave generada por el algoritmo DSS. Con respecto al algoritmo DSS, consulte el documento FIPS-186. Existen dos esquemas de administración para la autenticación de la clave de host en el protocolo SSH, como se muestra en la siguiente figura:
Cada host debe tener su propia clave de host y puede haber varios pares de claves. Cada par de claves de host incluye una clave pública y una clave privada. ¿Cómo se pueden utilizar estas claves en aplicaciones prácticas y confiar en ellas para implementar funciones de seguridad? Como se muestra en la figura anterior, se proponen dos soluciones en el marco del protocolo SSH.
En el primer esquema, el host distribuye su clave pública al cliente correspondiente. El cliente utiliza la clave pública del host para cifrar los datos al acceder al host, y el host utiliza su clave privada para descifrar los datos. , logrando así la Autenticación de la clave del host para determinar la identidad confiable del cliente. Como se puede ver en la Figura 2 (a), el usuario inicia una operación desde el host A y accede al host B y al host C. En este momento, A se convierte en el cliente y debe configurar las claves públicas del host B y del host C por adelantado. Al acceder, según el nombre del host para encontrar la clave pública correspondiente. Para acceder al host (es decir, el servidor), solo necesita garantizar el almacenamiento seguro de su propia clave privada.
En la segunda solución, existe un centro de certificación de claves. Todos los hosts que brindan servicios en el sistema envían sus claves públicas al centro de certificación, y cualquier host como cliente solo necesita conservar una copia de la misma. centro de certificación. En este modo, antes de acceder al host del servidor, el cliente también debe solicitar autenticación al centro de certificación de claves antes de poder conectarse correctamente al host de destino.
Obviamente, el primer método es fácil de implementar, pero mantener la clave en el cliente es algo problemático, porque cada cambio debe reflejarse en el cliente; el segundo método resuelve perfectamente los problemas de gestión y mantenimiento. Pero este modelo tiene altos requisitos para el centro de certificación. Para implementar dicha autenticación centralizada en Internet, simplemente determinar los permisos es una gran molestia. ¿Quién puede decidirlo todo? Pero a largo plazo, es necesario adoptar un esquema de certificación centralizado en aplicaciones empresariales y comerciales.
Además, el marco del protocolo SSH permite la fuga de claves de host, es decir, un primer acceso no autenticado. El primer acceso sin autenticación significa que cuando el cliente accede al host por primera vez, el host no verifica la clave del host, sino que emite una clave pública al cliente, por lo que debe usarse en visitas posteriores; será considerado ilegal y se le negará el acceso.
Durante todo el proceso de comunicación, para lograr una conexión SSH segura, el servidor y el cliente deben pasar por las siguientes cinco etapas:
* Etapa de negociación del número de versión, SSH actualmente incluye SSH1 y SSH2, ambas partes determinan la versión que se utilizará mediante la negociación de versiones.
*Durante la fase de negociación de claves y algoritmos, SSH admite múltiples algoritmos de cifrado y ambas partes negocian el algoritmo final en función de los algoritmos admitidos por el extremo local y el extremo par.
*Fase de autenticación: el cliente SSH inicia una solicitud de autenticación al servidor y el servidor autentica al cliente.
*En la fase de solicitud de sesión, después de pasar la autenticación, el cliente envía una solicitud de sesión al servidor.
*En la fase de sesión interactiva, una vez pasada la solicitud de sesión, el servidor y el cliente intercambian información.
Pregunta 1: Versiones SSH y diferencias.
SSH2 evita los problemas de patentes de RSA y soluciona los defectos de CRC. SSH2 utiliza el algoritmo de firma digital (DSA) y Diffie-Hellman (DH) en lugar de RSA para completar el intercambio de claves simétricas, y HMAC reemplaza a CRC. Al mismo tiempo, SSH2 añade algoritmos de cifrado simétrico como AES y Twofish.
R1: SSH (Secure Shell) tiene dos versiones incompatibles hasta ahora: SSH 1 y SSH2. SSH1 se divide en dos versiones: 1.3 y 1.5. SSH1 utiliza algoritmos de cifrado simétrico como DES, 3DES, Blowfish y RC4 para proteger la transmisión segura de datos, y las claves del algoritmo de cifrado simétrico se intercambian a través del algoritmo de cifrado asimétrico (RSA). SSH1 utiliza un código de verificación de redundancia cíclica (CRC) para garantizar la integridad de los datos, pero luego se descubrió que este método era defectuoso.
Para obtener más información, consulte el protocolo SSHv1 y el protocolo SSHv2
P2: ¿Qué es HMAC?
a2:HMAC (Código de autenticación de mensaje hash, código de autenticación de mensaje hash), un protocolo de autenticación basado en el algoritmo hash de clave. El principio del código de autenticación de mensajes es utilizar una función y una clave públicas para generar un valor de longitud fija como identificador de autenticación y utilizar este identificador para autenticar la integridad del mensaje. Se utiliza una clave para generar un pequeño bloque de datos de tamaño fijo, conocido como MAC, que se agrega al mensaje y luego se transmite. El destinatario se autentica utilizando una clave compartida con el remitente, y así sucesivamente.
P3: ¿Qué es el reenvío x 11?
R3: La función de reenvío X11 de sh permite que el cliente X y el servidor X se comuniquen de forma segura. Después de usar el reenvío X11, los datos del cliente X al servidor X se envían primero al servidor ssh. El servidor ssh usa el canal seguro con el cliente ssh para reenviarlos al cliente ssh, y luego el cliente ssh los reenvía. el servidor X. El flujo de datos del servidor X al cliente X es el mismo. Aquí, el servidor ssh y el cliente ssh actúan como retransmisiones de datos entre el cliente X y el servidor X. Dado que el servidor ssh y el cliente X, el cliente ssh y la comunicación entre servidores son seguros.
Pregunta 4: ¿Qué es TTY?
R4: Un terminal es un dispositivo basado en caracteres y viene en muchos tipos. tty se utiliza a menudo para referirse a varios tipos de dispositivos terminales. Tty es la abreviatura de Teletipo. El teletipo fue el primer dispositivo terminal, muy parecido al teletipo, y fue producido por Teletype Company. El nombre del dispositivo se coloca en el directorio de archivos especial /dev/.
P5: ¿Describe brevemente el proceso de operación SSH?