Router Teldat. Protocolo SSH

Transcripción

1 Router Teldat Protocolo SSH Doc. DM787 Rev Mayo, 2008

2 ÍNDICE Capítulo 1 Introducción Introducción al protocolo Fases de una conexión SSH Servidor SSH Autenticación del servidor Autenticación del cliente Cliente SSH... 7 Capítulo 2 Configuración Acceso al menú de configuración de SSH Menú principal del protocolo SSH ? (AYUDA) HOST-KEY a) HOST-KEY DSA GENERATE b) HOST-KEY DSA INSERT c) HOST-KEY RSA GENERATE [NUM_BITS] d) HOST-KEY RSA INSERT e) HOST-KEY RSA1 GENERATE [NUM_BITS] f) HOST-KEY RSA1 INSERT LIST a) LIST ALL b) LIST HOST-KEY LIST HOST-KEY ALL LIST HOST-KEY DSA LIST HOST-KEY RSA LIST HOST-KEY RSA c) LIST SERVER NO a) NO HOST-KEY NO HOST-KEY DSA NO HOST-KEY RSA NO HOST-KEY RSA SERVER EXIT Menú del servidor SSH AUTH-TIME AUTHENTICATION a) AUTHENTICATION PASSWORD b) AUTHENTICATION PUBLIC-KEY ENABLE KEY [NOMBRE] NO EXIT c) AUTHENTICATION RSA ENABLE KEY [NOMBRE] NO EXIT CIPHERS a) CIPHERS [NOMBRE] CLIENT-ALIVE a) CLIENT-ALIVE INTERVAL [TIEMPO] b) CLIENT-ALIVE MAX-COUNT [CONTADOR] COMPRESSION ii -

3 a) COMPRESSION YES b) COMPRESSION NO c) COMPRESSION DELAYED ENABLE EPHEMERAL-KEY a) EPHEMERAL-KEY BITS [NUM_BITS] b) EPHEMERAL-KEY REGENERATION-INTERVAL [TIEMPO] KEEP-ALIVE LIST a) LIST ALL b) LIST AUTH-TIME c) LIST AUTHENTICATION LIST AUTHENTICATION PASSWORD LIST AUTHENTICATION PUBLIC-KEY LIST AUTHENTICATION RSA d) LIST CIPHERS e) LIST CLIENT-ALIVE LIST CLIENT-ALIVE INTERVAL LIST CLIENT-ALIVE MAX-COUNT f) LIST COMPRESSION g) LIST ENABLE h) LIST EPHEMERAL-KEY LIST EPHEMERAL-KEY BITS LIST EPHEMERAL-KEY REGENERATION-INTERVAL i) LIST KEEP-ALIVE j) LIST MACS k) LIST MAX-AUTH-TRIES l) LIST MAX-CONNECTIONS m) LIST PORT n) LIST VERSION MACS a) MACS [NOMBRE] MAX-AUTH-TRIES MAX-CONNECTIONS NO a) NO AUTH-TIME b) NO AUTHENTICATION PASSWORD c) NO CIPHERS d) NO CLIENT-ALIVE NO CLIENT-ALIVE INTERVAL NO CLIENT-ALIVE MAX-COUNT e) NO COMPRESSION f) NO ENABLE g) NO EPHEMERAL-KEY NO EPHEMERAL-KEY BITS NO EPHEMERAL-KEY REGENERATION-INTERVAL h) NO KEEP-ALIVE i) NO MACS j) NO MAX-AUTH-TRIES k) NO MAX-CONNECTIONS l) NO PORT m) NO VERSION PORT VERSION EXIT Pasos para una buena configuración de SSH Configuración del servidor iii -

4 a) Creación de usuario y contraseña b) Compatibilidad de versiones c) Elección de las host-keys d) Activación del servidor e) Opciones avanzadas del servidor f) Sobre Telnet g) Guardado de la configuración h) Reiniciado de equipo Capítulo 3 Monitorización Monitorización de conexiones SSH iv -

5 Capítulo 1 Introducción

6 1. Introducción al protocolo SSH (Secure Shell) es un protocolo para acceso (login) remoto con seguridad, además de otros servicios de red seguros sobre una red no segura. La arquitectura de SSH está formada por tres componentes: Protocolo de nivel de transporte: Proporciona autenticación del servidor, por lo que el cliente puede verificar la autenticidad del servidor al que se conecta. Aporta también a la conexión confidencialidad e integridad con Perfect Forward Secrecy. Esta propiedad indica que las claves empleadas en cada sesión se generan a partir de un material único, y se consigue gracias a un intercambio de claves de Diffie-Hellman. Protocolo de autenticación de usuario: El cliente se autentica frente al servidor, de forma que únicamente se establece una conexión con usuarios permitidos por el servidor en su configuración. Protocolo de conexión: Multiplexa la conexión encriptada y autenticada en un conjunto de canales lógicos. Proporciona una serie de servicios, entre los que se encuentra el acceso a terminal remoto. El tráfico de SSH se intercambia típicamente sobre una conexión TCP/IP. El puerto de escucha del servidor SSH asignado por IANA (Internet Assigned Numbers Authority) es el 22. El protocolo SSH dispone de dos versiones en la actualidad: La primera versión, la originaria históricamente, no se encuentra estandarizada por el IETF (Internet Engineering Task Force). Inicialmente se distribuyó con licencia libre, pero los siguientes desarrollos, aún pertenecientes a la primera versión, dejaron de ser libres. Estaban además sujetos a patentes y restricciones gubernamentales, permitiendo su uso sólo para fines no comerciales. Por otra parte, se han descrito un conjunto de vulnerabilidades que hacen esta versión no recomendable. La segunda versión ha sido estandarizada por el IETF bajo el nombre de SSH, apoyada también por el proyecto OpenSSH, cuyo objetivo era desarrollar una implementación libre y portable del protocolo. La mayoría de las distribuciones de SSH presentes en el mercado, tanto de clientes como servidores, usan esta versión, que soluciona los riesgos encontrados en la primera, además de emplear mecanismos de cifrado más robustos. ROUTER TELDAT Introducción Protocolo SSH I - 2

7 1.1. Fases de una conexión SSH En primer lugar, una vez establecida la conexión TCP/IP, cliente y servidor se intercambian una cadena de caracteres en la que se notifican sus versiones de SSH. Cuando el servidor soporta tanto la versión 1 como la 2, indica que tiene implementada la versión SSH Si las versiones de ambos son compatibles, se inicia una negociación de parámetros. A continuación se describe el resto del proceso para SSHv2. Entre los parámetros negociados se encuentran los algoritmos de intercambio de claves KEX (Key EXchange), el tipo de clave del servidor, los algoritmos de cifrado posibles, los algoritmos disponibles de detección de errores MAC (Message Authentication Code), métodos de compresión, etc. Si ambas partes llegan a un acuerdo, se inicia el intercambio de claves, en el que se autentica el servidor y se genera una clave de cifrado a emplear en esta sesión únicamente. Esta clave es la que se emplea para el cifrado de toda la comunicación, hasta que se considere oportuno un nuevo intercambio de claves, bien por tiempo transcurrido o por tráfico enviado. A partir de este momento se considera que la conexión proporciona confidencialidad e integridad entre cliente y servidor. ROUTER TELDAT Introducción Protocolo SSH I - 3

8 Una vez que la conexión es segura, el cliente intenta autenticarse frente al servidor, empleando uno de los métodos permitidos por este último. Para dificultar la autenticación de clientes no deseados, el servidor limita tanto los intentos de autenticación como el tiempo disponible para realizarla. En último lugar, cuando se ha comprobado la identidad del cliente, éste intenta acceder al conjunto de servicios proporcionados por el servidor sobre la conexión segura. Corresponde al servidor la tarea de permitirle el acceso a dichos servicios según los privilegios de acceso del cliente, o según las funcionalidades que deseen ofertarse. ROUTER TELDAT Introducción Protocolo SSH I - 4

9 2. Servidor SSH Un servidor SSH proporciona una conexión de red segura a un cliente SSH. Como mínimo, pone a disposición del cliente el acceso por consola o terminal remoto al equipo servidor, que es la funcionalidad que da nombre al protocolo (Consola Segura). La especificación del protocolo ofrece actualmente un mayor abanico de servicios opcionales, entre los que se encuentran la transferencia de ficheros sobre SSH (SFTP), o el Port-Forwarding, que proporciona un túnel seguro para el intercambio de datos entre otras aplicaciones. En cuanto a las versiones del protocolo, el servidor puede ser compatible con SSHv1, con SSHv2 o con ambos. Aunque se aconseja emplear SSHv2 por el riesgo de seguridad detectado en la primera versión, existen todavía implementaciones de clientes que sólo soportan SSHv1, forzando la compatibilidad hacia atrás en muchos servidores SSH Autenticación del servidor Para la autenticación del servidor, es necesario que éste disponga de una clave que lo identifique unívocamente en la red, la host-key. Según la versión de SSH soportada, dicha clave ha de ser de un tipo específico. En la primera versión, el servidor debe contar con una clave RSA, habitualmente llamada RSA1 en este caso. Para la segunda versión, la clave puede ser RSA o DSA (Digital Signature Algorithm), teniendo la posibilidad de negociarse una u otra. Con el fin de posibilitar el acceso a clientes que exijan un tipo concreto, el servidor podría contar con una clave de cada tipo. Estas claves se descomponen en una parte pública y otra privada. La parte pública se debe distribuir a todos los clientes que deseen iniciar una conexión SSH, de forma que verifiquen que el servidor al que se intentan conectar es el esperado. Las diferentes distribuciones de clientes existentes en el mercado almacenan dicha información tras la primera vez que se inicia una conexión con un servidor, recordando su dirección IP y puerto. En ese momento avisan de que el servidor es desconocido, siendo obligación del cliente verificar que la clave pública recibida se asocia al servidor deseado. En las sucesivas conexiones SSH que se inicien desde el mismo cliente con dicho servidor, se comprueba que la clave pública obtenida es igual que la almacenada; en caso contrario, la aplicación alerta de una posible brecha en la seguridad, siendo de nuevo responsabilidad del cliente la decisión de confiar en la nueva clave recibida, reconocible por su huella (fingerprint). En cuanto a la parte privada, el servidor debe protegerla celosamente para que otro servidor malicioso no pueda usurpar su identidad. Aunque el método de almacenar la clave privada es dependiente de la implementación, es habitual guardar la información de la clave pública junto con la privada. Para añadir confidencialidad a la clave, se almacena cifrada Autenticación del cliente Una vez que se ha establecido una comunicación segura, el cliente debe autenticarse frente al servidor, por lo que este último debe registrar cuentas de acceso para los posibles clientes permitidos, junto con sus restricciones o privilegios. No resulta coherente con la filosofía de SSH permitir el acceso a ROUTER TELDAT Introducción Protocolo SSH I - 5

10 usuarios no registrados, o sin contraseña, ya que, aunque el canal esté cifrado, cualquier cliente tendría acceso al servidor, perdiendo el control sobre los usuarios permitidos. El servidor puede limitar el tiempo disponible para la autenticación, así como establecer un número máximo de intentos. Existen múltiples métodos de autenticación, todos ellos formados por un nombre de usuario y otro componente, que se explica más adelante. A menudo, la implementación del servidor no permite cambiar este nombre de usuario para cada nuevo intento, por lo que si se ha introducido un nombre de usuario erróneo, sería necesario reiniciar la conexión. Entre los mecanismos existentes, se encuentran: Contraseña (password). El servidor comprueba que los campos de usuario y contraseña proporcionados por el cliente, que ya se transmiten cifrados, se corresponden con los registrados; se asignan al usuario los permisos asociados. Autenticación por clave pública RSA para SSHv1. El servidor almacena en su configuración la parte pública de la clave RSA1 del cliente, de forma que podrá identificarle una vez que éste use su parte privada para crear una firma. Autenticación por clave pública (public key) para SSHv2. Dicha clave puede ser de nuevo RSA o DSA, y el mecanismo es similar al anterior, aunque varía la forma de guardar la clave. El cliente tiene la opción de elegir qué método de autenticación emplear entre los que el servidor ponga a su disposición, pudiendo requerir el uso de más de uno. ROUTER TELDAT Introducción Protocolo SSH I - 6

11 3. Cliente SSH La configuración del cliente SSH es, según la implementación, muy significativa. Mientras que el servidor restringe las opciones posibles para los parámetros de la negociación (cifrado, métodos de autenticación, etc.), el cliente es el que escoge de entre dichas opciones a partir de un sistema de prioridades. Por ejemplo, un servidor permite el uso de compresión, pero el cliente se configura para no emplearla, lo que prevalece sobre las preferencias del servidor. El parámetro principal a configurar es la versión de SSH con la que establecer la conexión. Para la autenticación del servidor, el cliente guarda un registro de las claves públicas de los servidores SSH a los que se ha conectado. La primera vez avisa al usuario de que la clave es desconocida, y si en una próxima ocasión no coincide con el valor almacenado, alerta de un posible riesgo de seguridad. En cuanto a la autenticación del cliente, éste tiene la opción de escoger entre los mecanismos permitidos por el servidor. En el apartado referente al servidor SSH se han comentado algunos de los métodos de autenticación estandarizados, que en primer lugar necesitan un nombre de usuario; habitualmente no se puede modificar dicho nombre en sucesivos intentos de autenticación. Para los métodos mencionados, la perspectiva del cliente es: Contraseña (password). La aplicación cliente almacena la contraseña con la que autenticarse frente al servidor o bien se la pide al usuario en cada intento de autenticación que se realice. Autenticación por clave pública RSA para SSHv1. El cliente guarda en su configuración la ruta al archivo con la clave privada RSA1, que tiene formato estándar. Para poder utilizar su clave para autenticarse, debe configurar previamente el servidor, registrando en él su clave pública; durante el proceso, si la clave está protegida por contraseña, se le pide al usuario que la introduzca si quiere utilizarla. Por otra parte, los clientes SSH suelen tener asociada una aplicación para la generación de claves, e incluso agentes para tener las claves ya cargadas y que no sea necesario escribir su contraseña (passphrase). Autenticación por clave pública (public key) para SSHv2. Como con la clave RSA1, el cliente debe almacenar la ruta al archivo con la clave privada a usar, cuyo formato varía según el cliente; entre los formatos más destacados: OpenSSH (formato PEM de OpenSSL), ssh.com (marca comercial) y Putty. Sigue siendo necesario configurar en el servidor la parte pública de la clave, para que éste la acepte, así como introducir su contraseña en tiempo de ejecución si está protegida. Por último, si el objeto de la conexión es abrir una consola remota, el cliente debe crear un terminal con el que permitir la interacción entre el usuario y el equipo servidor. ROUTER TELDAT Introducción Protocolo SSH I - 7

12 Capítulo 2 Configuración

13 1. Acceso al menú de configuración de SSH En este capítulo se describen los pasos requeridos para configurar el protocolo SSH, comenzando por el acceso al menú del protocolo. Los siguientes apartados describen el proceso de configuración con más detalle. En primer lugar, se debe entrar en el menú de configuración del equipo. Para el caso de querer modificar la configuración estática: *config Config> Para acceder al entorno de configuración SSH, desde el prompt Config> (configuración estática), o desde Config$ (configuración dinámica), se debe introducir el siguiente comando: Config>feature ssh -- SSH protocol configuration -- SSH Config> II - 9

14 2. Menú principal del protocolo SSH En este apartado se listan y explican los comandos del menú de configuración de SSH. Actualmente, sólo se dispone del servidor SSH, que necesita a su vez de unas claves propias del equipo (host-keys). Dado que dichas claves identifican a todo el equipo, no sólo al servidor, se encuentran en un comando aparte. A continuación se muestran los comandos disponibles en el menú principal del protocolo: Comando Función? (AYUDA) Lista los comandos disponibles o las opciones asociadas con un comando específico. HOST-KEY Permite generar o insertar claves de equipo. LIST Muestra los valores de cada uno de los parámetros de configuración, incluyendo las claves privadas del equipo. NO Borra el valor configurado de un parámetro, dejándolo a su valor por defecto. En el caso de claves, las elimina completamente. SERVER Entra en el menú de configuración del servidor SSH. EXIT Vuelve al prompt Config>. 2.1.? (AYUDA) Use el comando? (AYUDA) para listar los comandos que están disponibles en el nivel donde se está programando el router. También puede utilizarse a continuación de un comando específico para listar sus opciones. Está disponible para todos los submenús y comandos. SSH config>? SSH Config>? host-key list no server exit SSH Config> Host key configuration Display protocol configuration Negate a command or set its defaults Server configuration 2.2. HOST-KEY Mediante el comando HOST-KEY, que es sólo estático, se posibilita la generación de nuevas claves o su inserción a partir de claves previamente generadas. Se encuentran los siguientes subcomandos: Comando Función DSA Host-key de tipo DSA (para versión 2). RSA Host-key de tipo RSA (para versión 2). RSA1 Host-key de tipo RSA1 (para versión 1). II - 10

15 El equipo sólo puede tener una host-key de cada tipo, aunque su existencia no es siempre obligatoria. Si el servidor sólo va a ser compatible con SSHv2, no es necesaria una clave RSA1; análogamente, si sólo va a ser compatible con SSHv1 (no se recomienda), no son necesarias las claves DSA ni RSA. Por otra parte, cuando la versión del servidor incluye SSHv2, no hacen falta las dos claves de la versión (RSA y DSA); así que, en la mayoría de los casos, es suficiente con disponer de una host-key RSA o DSA. El motivo de tener ambas es permitir la interoperabilidad con un cliente SSH que le exigiera al servidor emplear un tipo de clave concreto. Por defecto, el equipo no dispone de ninguna host-key, pero cuando se habilita el servidor SSH, se generan automáticamente las mínimas claves necesarias según la versión de SSH. Si está configurado para operar con SSHv1 y SSHv2, se generan las claves RSA1 y RSA con 1024 bits; si sólo una versión está habilitada, se genera la clave correspondiente. Por defecto, no se genera la clave DSA. En el caso de que el usuario borre las host-keys configuradas, estando el servidor habilitado, cuando éste arranca al reiniciar el equipo, intenta cargar las claves; si no encuentra alguna de las necesarias, las genera automáticamente, correspondiendo al usuario la tarea de salvar la configuración dinámica si quiere conservarlas. Una host-key está formada por una parte pública y otra privada. En la host-key se guarda toda la información, de forma que, junto con la parte privada, se encuentra también la pública. A pesar de que la parte pública se distribuye libremente, ya que cualquier cliente que inicie una conexión SSH con el servidor la obtiene, la parte privada debe protegerse. En consecuencia, el contenido de la host-key no debe divulgarse, y se protege mediante cifrado. En cuanto a la forma de almacenar las claves, las host-keys se guardan en el archivo de configuración, de forma que el equipo siempre conserve sus mismas host-keys. Si se modificase alguna de ellas, los clientes que hubieran registrado dicha clave pública antigua del servidor, informan de que no coincide con la almacenada. Aunque se guardan en la configuración, no se muestran al usuario al emplear el comando SHOW CONFIG, dado que no le aportan información relevante y no deben portarse entre equipos diferentes. Las claves deben ser únicas para cada equipo, con tal de que lo identifiquen unívocamente, pero aún así se proporcionan mecanismos para conservar dichas claves entre distintas configuraciones. Para mostrar el contenido de las host-keys, se debe usar el comando LIST HOST-KEY [TIPO], mientras que para introducir en el equipo una clave previa, se dispone de HOST-KEY [TIPO] INSERT. Por último, como se ha indicado anteriormente, las host-keys se guardan también en el archivo de configuración; por tanto, si éste se copia en distintos equipos, hay que prestar atención a generar unas claves únicas para cada uno de ellos. Dentro de cada subcomando, para cada uno de los tipos de claves, se encuentran las siguientes opciones: Comando GENERATE INSERT Función Genera una host-key del tipo indicado. Permite insertar una host-key previamente generada mediante pegado de texto. El proceso de generación de claves requiere un tiempo que varía en función del número de bits, del algoritmo empleado y del equipo, y puede llegar a durar varios minutos en el caso más desfavorable. Sin embargo, esta generación de claves no debe realizarse más de una vez por equipo. Una vez generada la host-key, se muestra por consola la clave pública y el fingerprint o huella. Al menos este fingerprint, resultante de realizar un MD5 de la clave pública, ha de suministrarse a los futuros clientes SSH, para que verifiquen visualmente la autenticidad del servidor. II - 11

16 a) HOST-KEY DSA GENERATE Genera la host-key del tipo DSA (también llamado DSS) con 1024 bits, para SSHv2. La longitud es fija, ha de tener 1024 bits. Si el equipo ya disponía de ella, se sobrescribe la antigua. SSH config>host-key dsa generate SSH Config>host-key dsa generate Generating public/private dsa key pair... Please wait for a few seconds. Key generation done. SSH Config> Public key: ssh-dss AAAAB3NzaC1kc3MAAACBAMBl0OdknSG228cLtQ+6z/BwizJo2ijElXRI JkoLAFO0q+ACbA6fe8wo+9Hy4RjAyoO6HWtUXbuuO7fDFoIqOWLYLM0t5jNfI1g+ yiezyrnyrfcffwslkezz6xjv6cqesgx2zj+sqxwkevx++fdsix2ng4zacrnmttdx MDfLIRrFAAAAFQDod41UuyTQ9tIvdOF+tXvf5ZyzoQAAAIEAvYPpolQj6lbrhIhp q7u+b1sjtbqiruxrco11bym2o91khm0evizm0zyhabvwkyeecno8wce6ki9x52xk ROow2Es45FqsvGR1sJleDyVxsjbLU4eRwHLLSgQ1ORdzTH1ic+oFpplaPZOmvZeu uchornune/jgjhaf4rsqubrn+ayaaacbaju1xpy74hvhi1fy9l6hp5v5bu3laxqk W2eH+zYONKhNHOrC2Xs8Mt7adhPDQRabXxtPA4PLwo0uVKuBcufvqaKLs/llzNaJ ghxws1wr9w3idax4fqkj6hz7plqx1lt+zwia7jpzcknchdwmpnm/idhcoro0+kga 9X12KiA5Bcew The key fingerprint is: 97:53:9d:25:21:8b:76:49:09:5d:e9:6c:4c:f6:8e:56 Para más información sobre la clave privada, consultar el comando LIST HOST-KEY DSA. b) HOST-KEY DSA INSERT Permite la inserción de una host-key conocida de tipo DSA en el equipo, que debe haber sido generada por un equipo Teldat. En caso contrario, no se muestra ningún error al usuario, pero cuando el servidor intenta cargarla al iniciarse, la clave no se considera válida; en ese momento, se genera una nueva clave, avisando de ello mediante un evento. SSH config>host-key dsa insert SSH Config>host-key dsa insert Enter the host key (PEM format) <cr> to escape -----BEGIN DSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,82AECC6A hu6tmixw/gdauugsnc++roi3ndzcgniljfaoxhrhyuwhinxsxwihfkt0ugbtg7f2 FutmdkEYAytkog5MLDK0+DCEmWs/9M/UkRmcYlYkJachv+UWvgDpMvfbVk50zRo/ X3Oq6TAuT4voArLcb71GOtqHQKEeGi1lhUy3UffkN0WJYbqoImFzMa8cQTVaDDvH 4DwnHSOlLWUIy/dCJOJiz0FuGNVqmp0Y5mZthcG7LdFWoHoQrlsa3+El0191/zAM Yq3yMkvUkp4KrxDkOA5jvHJGu/futCXq2dvGatQog1041DAqVZKiRT8RHVr8xK0m osglm3kpw13rxpwfcafbghjmxpx447zr/txoks9p0srl/yw0msbwrdw1urnhkbwh bo6xtfjld98z2qducxrmdc9dvxtdqaf9q84tjxqofrx+zb/q83iytcbr55ifh3eh NrBZgivEw5ZOJxIhZ0stBafsxn8hBloDdReVzxbyODfChLUKKtID8njuV1AH/O1j 3rWrer7nZnaquvRDGvYw+UBGrZL6X/0el0lbMjjJvHegqg1KLRT/Vj3lNqiPWnMz grbmiws4n1ikh138mm83yrkeoq3agaa END DSA PRIVATE KEY----- SSH Config> II - 12

17 Para más información sobre la clave privada, consultar el comando LIST HOST-KEY DSA. c) HOST-KEY RSA GENERATE [NUM_BITS] Genera la host-key del tipo RSA con el número de bits especificado, entre 768 y 2048, para SSHv2. Una longitud de 1024 bits debe ser suficiente en la mayoría de los casos. Si el equipo ya disponía de la clave, se sobrescribe la antigua. SSH config>host-key rsa generate <num_bits> SSH Config>host-key rsa generate 2048 Generating public/private rsa key pair... Please wait for a few seconds. Key generation done. SSH Config> Public key: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0ayDS70qND+k4ZtyFs8LifniAHFR InD/Ygii0CoSj8YCXdr2e8ahEFmt0fvc9N53+blBDPGdo7cVBrC1BmY4ocWH+ZRp dpstjd4mq33arjcvypyqq1ipfwxsp2e1qeqd6cinaozal2qalvbxbkbit6uzbfve Vo0LzbXCDzzLOvCXSwxxiLf2ktwFsY9XBak9jYJcDs8nEwwhwDNnfhn8tJ8ZnNjv mmsfjykdqbcsiuuimy4xjbssgizbupeblnjgqtcxhziz58asw+799fscbwcjvxjz Ae6iZlbQmycElpun0DEjEDsdcqJgfypq0XgDaUsOnBjF+axgTN5AlTouvQ== The key fingerprint is: 23:08:e1:2a:ad:fe:37:3e:8f:a0:67:ed:00:f2:3c:24 Para más información sobre la clave privada, consultar el comando LIST HOST-KEY RSA. d) HOST-KEY RSA INSERT Permite la inserción de una host-key conocida de tipo RSA en el equipo, que debe haber sido generada por un equipo Teldat. En caso contrario, no se muestra ningún error al usuario, pero cuando el servidor intenta cargarla al iniciarse, la clave no se considera válida; en ese momento, se genera una nueva clave, avisando de ello mediante un evento. SSH config>host-key rsa insert SSH Config>host-key rsa insert Enter the host key (PEM format) <cr> to escape -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,6A A4DA3FC ++QKlzwaKAL8u9G/eYkutMjQPpBIZoV5eQMxNfFzWRlE47T1myBRqFrCFvDXiI4G 1ZMrmvbua0S1GUBZCcGkNpJHk0jP7/AYNMIW1XCHnKPafZ2DkquAZ5BU/IhY4ztz /GZLyVB+AULhG1rQil9P82cqqGp5Cv4VkZdwRJHnLLslij5B5ToCO/ap6krtsCUH rexfrxf3kxkbvwsnnave7dmu3exwzq3ts//u4nrpevnevahp6zoopzhp8lzhppxh E2ki/h6yBW0+P8/Rzg1jWV8oreaDJfFzPvzhrOdWN4aNJSXZbSXL1hwYdWgouJ+u doacx1yzzrlldgcasy3kmsc3n9owalfnc4i2xyn+lgm/hbymoljjpjfmv0rck5s0 KljWhlk4oiRLcmEzIM4+1UjCPP1VWTanxCMmkCMfgmtjun+Dcfq3JGz34xN3GNap e2vowh3vwg196yxmolhlf0/wsjgqufkbu1/rrdx65ztnskumoaabceaz5fkhf1t1 2UlZu347I+A4FDUw7/VOluJu9Ey1ffBfQPvc+7Y0IDvxVTkiAHk5ChtUjoWMFCsz iu3i794ej/ygfoldkg1dt+07pmqtvztldv078hxkzkwa8jkc+gbe7u08bhvwyv/e 7P8wrwP4tXjH22zRyycS7uRvsX3859A29KwQxFU1fX264SjmLBwdFY6GaLURBIvV OLUxdjnFaDtcsTFjbvxT6/FgWk2dDVrxJJOl+bfxGLgNpFQk16SYJsQwM7LtFQsW II - 13

18 7LkXuuZIwOmTxI1mX7jdGW4VTp7sm8anmRCGCNpEz7n7yyNHKf9KR0rsWZw5sfiN I8opvHfl6ZFpBBweLLtByl5og0WWrbjPcNMNRYPCnKLCP1F9ph+271Mf3PBXMTaj RshZboZLKJqfOE/LYSJjjC3IgHngC4goSd0+4PT0nlCmAW89lrmMKmuUAG2utELy 40IMg8VYAWjZ+sdz+XDgLOKOqud2L7RnsMED67V7ZgrFTWF8AsLwMNmcouLzHNE3 d5dud7c9mvsisyqvm+xaxo2be9tzet7t4xvd03fiqxrv9ncrkwuhutweenbjomll 3fW8bZeNTBudy4j/cJKtLuqHtbrNJNasTcgEicR5G80+Vdjoy7qpd6+zYn5zlSZt fxdoic3afx+4bg+is782dx1moa6izjjnrn4bxpjpu+ip/db0xtvn5q41z8lrx6dq XtEFG6i3NTLy84VDKL4V+3wpazrV+tSrLd9KNypfDGJHcBF8gSeJnoq0qP9RaH9U b14qvhcfop/cmojebxmpvz6whzklpxpahhcudkhnbabrbygz1l1qapl4hdvtin0b T/l+nPV2HIeYm7nWaZJHp5wtQ8x6hwaW9++AQCpVsWoufbfamipAwfJpet3kkBUI x0ms5dg9jzflur/u2yoquk2knxsjmktmt3f2uuvwrznswoajlgn/h9n1a9unmjcy +P+ZYO/TirddJockBb/Yy0xDb9nk9zTn5Fyl98H7/UPRPwF2wXgjGHsCR06Y81UV 0Pu0n5lA8d31UXNW00hmC/o9I5xOkn9yz2RBIZ6tH1g0VaDUx2+ZdQ== -----END RSA PRIVATE KEY----- SSH Config> Para más información sobre la clave privada, consultar el comando LIST HOST-KEY RSA. e) HOST-KEY RSA1 GENERATE [NUM_BITS] Genera la host-key del tipo RSA1 con el número de bits especificado, entre 768 y 2048, para SSHv1. Una longitud de 1024 bits debe ser suficiente en la mayoría de los casos. Si el equipo ya disponía de la clave, se sobrescribe la antigua. Se denomina RSA1, aunque siga siendo una clave del tipo RSA, porque varía el formato de la host-key tanto al almacenarla como al extraer su parte pública. SSH config>host-key rsa1 generate <num_bits> SSH Config>host-key rsa1 generate 1024 Generating public/private rsa1 key pair... Please wait for a few seconds. Key generation done. SSH Config> Public key: The key fingerprint is: a2:94:6a:b9:39:d5:75:73:5a:f4:d8:cd:35:3c:3e:08 Se observa que el formato de la parte pública difiere del propio de la clave RSA (SSHv2). Se compone en este caso de la longitud del módulo, seguida de exponente y módulo, todos en base decimal. Para más información sobre la clave privada, consultar el comando LIST HOST-KEY RSA1. f) HOST-KEY RSA1 INSERT Permite la inserción de una host-key conocida de tipo RSA1 en el equipo, que debe haber sido generada por un equipo Teldat. En caso contrario, no se muestra ningún error al usuario, pero cuando el servidor intenta cargarla al iniciarse, la clave no se considera válida; en ese momento, se genera una nueva clave, avisando de ello mediante un evento. SSH config>host-key rsa1 insert II - 14

19 SSH Config>host-key rsa1 insert Enter the host key (base64) <cr> to escape U1NIIFBSSVZBVEUgS0VZIEZJTEUgRk9STUFUIDEuMQoAAwAAAAAAAAQABADkrAMA VHLs6btQpuo/JU3e0t4ZGqaxdeUmNk23hKFzfXGYVOMeA1qvSBvHlnvTHKg7oIah Of6zkTofLnUW3i+okfnAqK2XRJ98woh/enW8Fj6DKk9Pd4Ek1KnuKn8BWPEOU+dJ 7caGmgbfQj1t2crgcqiAYdjGN6LsToT9ytnsSwAGIwAAAA11bmtub3duX3VzZXJA h18uq51ttpqg+p9u7o/fu69f2egds5k28pw5wpexdpyihwgz+d1z/uhv51xbt+3k CMjnrWPRaiXvnDwAJ1B+isEtUuke1kykQZ6pSTppivQj6oynNPxGSQPcCJqaxLy4 0/9g+tRZW0Kfz+/ELXtuzXl7cc1VZi9uVgFdjCqi+qRbUxmcS/QpgpbJTph895MZ zxvngsoor6ia32tyncjlanpraun7xaipbrneqflvzu+h0k67eub3t1jq+jjmrzc+ nsb0ibogxo6s2km+tdyxu+nqwa7dh0ag6ujczavbj+khoftgioskztc8z+k4avuz 8YvMprTjkoJ+dcjAatCttyGZDMeM9xdYbNQyHAsyXLCvRojB7laS1yG6lZKyUgC1 E3rm52XicGkN5+Yl4pWUZcKdeEUO7GOVn/erkXAcnNaEYUGyKkxLc2Su8Hdhn7tT SSH Config> Para más información sobre la clave privada, consultar el comando LIST HOST-KEY RSA LIST Este comando muestra todo el contenido de la configuración de SSH. Dispone de varios subcomandos para focalizar la parte de la configuración que se desea observar. No se indican los cambios hechos en la configuración por defecto, dado que para ese objetivo existe el comando SHOW CONFIG. En vez de ello, se listan los valores de los parámetros de configuración del protocolo, ya sean valores por defecto o modificados por el usuario. Se dispone de los siguientes subcomandos: Comando ALL HOST-KEY SERVER Función Lista toda la configuración del protocolo. Muestra las host-keys completas presentes en el equipo. Presenta la configuración del servidor SSH. Debe observarse que, dependiendo de en qué menú de configuración se ejecute el comando, se muestra la configuración estática o dinámica. Al iniciarse el router, ambas configuraciones coinciden. La excepción se presenta en el caso de que el servidor esté habilitado, no haya host-keys guardadas en configuración, y al no encontrarlas, el servidor las genere, almacenándose en configuración dinámica. El servidor en ejecución hace uso de esas claves, y debe salvarse dicha configuración para conservarlas, además de evitar que el equipo deba generarlas de nuevo cada vez que se inicie. a) LIST ALL Muestra la información completa de la configuración del protocolo. Es similar a realizar un LIST SERVER ALL seguido de un LIST HOST-KEY ALL. SSH config>list all SSH Config>list all SSH Server configuration: Server status: enabled II - 15

20 Version compatibility: SSHv1 and SSHv2 Listening port: 22 Payload compression: enabled Ciphers: 3des-cbc : available aes128-cbc : available aes192-cbc : available aes256-cbc : available aes128-ctr : available aes192-ctr : available aes256-ctr : available arcfour128 : available arcfour256 : available arcfour : available blowfish-cbc : available cast128-cbc : available Message Authentication Codes: hmac-md5 : available hmac-sha1 : available hmac-ripemd160 : available hmac-sha1-96 : available hmac-md5-96 : available Authentication methods: Password : available Public-key : available Key : pubkey1 ssh-dss AAAAB3NzaC1kc3MAAACAdQpx45QBksY+YdceMCv1a7 OYFT/nKkFghAcEE3fGbz4vPJjXpSOIkgTARylPx+uEkmokN9nv RY0CT53r/+QlfxIBW1Z8Nu1TvI8qm0Ea0OYyDI6oEhMZhWFWKH HQmUQy1oCl3ndqgMT4rr3fEl2hbZeujJzrNVY4EQsfSF9KhV8A AAAVAI3hGhP6mxl/FEE7Xva+JfraCwHPAAAAgGMNblPcZeM5Dg bj1vj/vehpvayvcw5e30x8jml8yvsr7w/qajogaiekghb8efkt uubt9nzot+qhlaitwee3nf4gxeh9ifhlrryth/jpktpyuck66o cu4x/9jjzcyul+eqqdgdwhephviub3epqtup19noa65tbfj3zb xv+tsfttaaaaggtezeclqmdxsnm5pjelvtdnu7n/mhbtqtw8i+ Pm+BKEOjCiBMFKB/4l5+TL1T1ocP0QCIttx15A9QRCkab4VEJ8 pnipnrkknvyuk2blgnnijwbpdvnfwei7jszrzadijjlxgocuez tvggqf9cr0f9wvele2vmilq7jf2cp79yt9 dsa-key Key : pubkey2 ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAn+U+8tigcZ7FkW lrjejpw5nmqlh2lma9sjqjxe1+uvzcrb0vgymcqkn5fc6zorld B2kIPUNjNxss3KU2rRZLPx+k9Jlf9lyz2+LT8oMVKHzN0G7Nh+ ZKakJu8HFweb83VnngW08gf27hy5Cn/lO1dy9t9Ib4dAlWhvf2 n0ozmcach5xrkadrq8mj1tuge+oogevu8sziy4nxuw0buj3bfi MPMaWnCH7WbhuwtfyqYvY7X9yq5grOf9qTfKXjQ8iZJPdXSNw1 e9fdd1ueljlzx72a5pz7uchjmuwydmaxga6jzjyntiajobniv3 HLo+T2r3V5sR5L9qMTR3VN4RNSnw== RSA : available Key : rsa_k rsa-key Maximum number of authentication attempts: 6 II - 16