Seguridad y VPN : Secure Shell (SSH)

Configuración de Secure Shell en routers y switches que ejecutan Cisco IOS

23 Junio 2008 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (28 Junio 2007) | Comentarios

Contenidos

Introducción
Requisitos previos
     Requisitos
     Componentes utilizados
     Convenciones
SSH v1 frente a SSH v2
Diagrama de la red
Prueba de autenticación
     Prueba de autenticación sin SSH
     Prueba de autenticación con SSH
Ajustes de configuración optativa
     Rechazo de conexiones no SSH
     Configuración de un router o switch de IOS como cliente SSH
     Adición de acceso de línea de terminal SSH
     Configuración de la versión de SSH
     Variaciones en el resultado del comando banner
     Imposibilidad de mostrar el mensaje de registro
Comandos debug y show
Ejemplo del resultado de la depuración
     Depuración del router
     Depuración del servidor
Qué puede salir mal
     SSH desde un cliente SSH no compilado con el Estándar de cifrado de datos (DES)
     Contraseña incorrecta
     El cliente SSH envía cifrado (Blowfish) no admitido
Consejos para la resolución de problemas
Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

Secure Shell (SSH) es un protocolo que proporciona una conexión de acceso remoto segura para dispositivos de red. La comunicación entre el cliente y el servidor está cifrada en las versiones 1 y 2 de SSH. Implemente la versión 2 de SSH siempre que sea posible, ya que usa un algoritmo de cifrado con seguridad mejorada.

En este documento se analiza la configuración y depuración de SSH en routers o switches de Cisco que ejecutan una versión de Cisco IOS® que admita SSH. También se incluye información adicional acerca de versiones e imágenes de software concretas.

Requisitos previos

Requisitos

No hay requisitos previos específicos para este documento.

Componentes utilizados

La información incluida en este documento se basa en la versión 12.2(2)T1 del software Cisco IOS 3600 (C3640-IK9S-M).

SSH se ha incluido en las siguientes plataformas e imágenes de IOS:

  • La versión 1.0 del servidor SSH (SSH v1) se comenzó a incluir en algunas plataformas e imágenes de IOS desde la versión 12.0.5.S del software Cisco IOS.

  • El cliente SSH se comenzó a incluir en algunas plataformas e imágenes de IOS desde la versión 12.1.3.T del software Cisco IOS.

  • El acceso a línea de terminal SSH (también denominado Telnet inverso) se comenzó a incluir en algunas plataformas e imágenes de IOS desde la versión 12.2.2.T del software Cisco IOS.

  • La compatibilidad con la versión 2.0 de SSH (SSH v2) se comenzó a incluir en algunas plataformas e imágenes de IOS desde la versión 12.1(19)E del software Cisco IOS.

  • Consulte How to Configure SSH on Catalyst Switches Running CatOS (Cómo configurar SSH en switches Catalyst que ejecutan CatOS) para obtener información acerca de la compatibilidad de SSH con los switches.

Consulte el asesor de software ( sólo para clientes registrados) para obtener una lista completa de conjuntos de funciones admitidas en las distintas versiones del software Cisco IOS y en diferentes plataformas.

La información presentada en este documento se ha creado a partir de dispositivos en un entorno específico de laboratorio. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración despejada (predeterminada). Si se encuentra en una red activa, debe conocer perfectamente las funciones de un comando antes de ejecutarlo.

Convenciones

Consulte Cisco Technical Tips Conventions (Convenciones sobre consejos técnicos de Cisco) para obtener más información sobre las convenciones del documento.

SSH v1 frente a SSH v2

Utilice el asesor de software ( sólo para clientes registrados) de Cisco para buscar la versión del código con la compatibilidad apropiada para SSH v1 o SSH v2.

Diagrama de la red

ssh-1.gif

Prueba de autenticación

Prueba de autenticación sin SSH

Primero, pruebe la autenticación sin SSH para asegurarse de que funciona en el router Carter antes de agregar SSH. La autenticación se puede realizar con un nombre de usuario y una contraseña locales, o con un servidor de autenticación, autorización y contabilidad (AAA) que ejecute TACACS+ o RADIUS. (Con SSH no se puede realizar la autenticación mediante contraseña de línea.) Este ejemplo muestra la autenticación local, que permite realizar una conexión Telnet al router con el nombre de usuario "cisco" y la contraseña "cisco".

            
               !--- El comando aaa new-model permite usar el nombre de usuario y la contraseña locales en el router
!--- cuando faltan otras sentencias AAA.
            

            aaa new-model
username cisco password 0 cisco
line vty 0 4
transport input telnet

               !--- En lugar de aaa new-model, puede usar este otro comando, login local.
            
         

Prueba de autenticación con SSH

Para poder probar la autenticación con SSH, debe agregar elementos a las sentencias anteriores para poder habilitar SSH en Carter y probar SSH desde el equipo y las estaciones UNIX.

ip domain-name rtp.cisco.com

               !--- Genere una clave SSH para usarla con SSH.
            

            cry key generate rsa
ip ssh time-out 60
ip ssh authentication-retries 2

En este punto, el comando show cry key mypubkey rsa debe mostrar la clave generada. Después de agregar la configuración de SSH, pruebe la capacidad para acceder al router desde el equipo y la estación UNIX. Si no funciona, consulte la sección de depuración de este documento.

Ajustes de configuración optativa

Rechazo de conexiones no SSH

Si desea evitar las conexiones no SSH, agregue el comando transport input ssh bajo las líneas para limitar el router a conexiones SSH exclusivamente. Las conexiones Telnet directas (no SSH) son rechazadas.

line vty 0 4

               !--- Evite conexiones Telnet no SSH.
            

            transport input ssh
         

Realice una prueba para asegurarse de que los usuarios sin SSH no pueden realizar conexiones Telnet al router Carter.

Configuración de un router o switch de IOS como cliente SSH

Debe seguir cuatro pasos para habilitar la compatibilidad con SSH en un router de IOS:

  1. Configure el comando hostname.

  2. Configure el dominio DNS.

  3. Genere la clave SSH que se va a utilizar.

  4. Habilite la compatibilidad con el transporte SSH para el terminal de tipo virtual (vtys).

Si desea que un dispositivo actúe como cliente SSH del otro, puede agregar SSH al segundo dispositivo, denominado Reed. Los dispositivos presentan una configuración de cliente y servidor, en la que Carter actúa como servidor y Reed como cliente. La configuración de clientes SSH de IOS en Reed es la misma que la requerida para la configuración de servidor SSH en Carter.

            
               !--- Paso 1: configure el nombre del host, si aún no lo ha hecho.
            
hostname carter

               !--- El comando aaa new-model permite usar el nombre de usuario y la contraseña locales en el router
!--- cuando faltan otras sentencias AAA.
            

            aaa new-model
username cisco password 0 cisco

               !--- Paso 2: configure el dominio DNS del router.
            
ip domain-name rtp.cisco.com

               !--- Paso 3: genere una clave SSH para usarla con SSH.
            

            cry key generate rsa
ip ssh time-out 60
ip ssh authentication-retries 2

               !--- Paso 4: de forma predeterminada, el transporte de vtys es Telnet. En este caso,
!--- Telnet está inhabilitado y sólo se admite SSH.
            
line vty 0 4
transport input SSH

               !--- En lugar de aaa new-model, puede usar este otro comando, login local.
            
         

Ejecute este comando para SSH desde el cliente SSH de IOS (Reed) hasta el servidor SSH de IOS (Carter) para probarlo:

  • SSH v1:

                      ssh -l cisco -c 3des 10.13.1.99
                   
  • SSH v2:

                      ssh -v 2 -c aes256-cbc -m hmac-sha1-160 -l cisco 10.31.1.99
                   

Adición de acceso de línea de terminal SSH

Si necesita autenticación de línea de terminal SSH saliente, puede configurar y probar SSH para Telnet inverso saliente en Carter, que actúa como servidor de comunicaciones de Philly.

ip ssh port 2001 rotary 1
line 1 16
   no exec
   rotary 1
   transport input ssh
   exec-timeout 0 0
   modem In Out
   Stopbits 1

Si Philly está conectado al puerto 2 de Carter, puede configurar SSH para Philly a través de Carter desde Reed con la ayuda de este comando:

  • SSH v1:

                      ssh -c 3des -p 2002 10.13.1.99
                   
  • SSH v2:

                      ssh -v 2 -c aes256-cbc -m hmac-sha1-160 -p 2002 10.31.1.99
                   

Puede usar este comando desde Solaris:

            ssh -c 3des -p 2002 -x -v 10.13.1.99
         

Configuración de la versión de SSH

Configure SSH v1:

carter (config)#ip ssh version 1
         

Configure SSH v2:

carter (config)#ip ssh version 2
         

Configure SSH v1 y v2:

carter (config)#no ip ssh version
         

Variaciones en el resultado del comando banner

El resultado del comando banner cambia entre Telnet y las distintas versiones de conexiones SSH. En esta tabla se muestra el funcionamiento de las diferentes opciones del comando banner con diferentes tipos de conexión.

Opción del comando banner

Telnet

Sólo SSH v1

SSH v1 y v2

Sólo SSH v2

banner login

Se muestra antes del registro del dispositivo.

No se muestra.

Se muestra antes del registro del dispositivo.

Se muestra antes del registro del dispositivo.

banner motd

Se muestra antes del registro del dispositivo.

Se muestra después del registro del dispositivo.

Se muestra después del registro del dispositivo.

Se muestra después del registro del dispositivo.

banner exec

Se muestra después del registro del dispositivo.

Se muestra después del registro del dispositivo.

Se muestra después del registro del dispositivo.

Se muestra después del registro del dispositivo.

Imposibilidad de mostrar el mensaje de registro

La versión 2 de SSH admite mensajes de registro. El mensaje de registro se muestra en pantalla si el cliente SSH envía el nombre de usuario cuando inicia la sesión SSH con el router de Cisco. Por ejemplo, el mensaje de registro aparece cuando se usa el cliente SSH Secure Shell, pero no cuando se emplea el cliente SSH PuTTY. Esto se debe a que, a diferencia de PuTTY, Secure Shell envía el nombre de usuario de forma predeterminada.

El cliente Secure Shell necesita el nombre de usuario para iniciar la conexión al dispositivo habilitado para SSH. El botón Connect aparece inhabilitado si no se escriben los nombres de host y de usuario. La siguiente captura de pantalla muestra el mensaje de registro que aparece cuando Secure Shell se conecta al router. A continuación, aparece el mensaje de solicitud de contraseña del mensaje de registro.

ssh-2.gif

El cliente PuTTY no precisa del nombre de usuario para iniciar la conexión SSH al router. Esta captura de pantalla muestra cómo se conecta el cliente PuTTY al router y cómo solicita el nombre de usuario y la contraseña. No muestra el mensaje de registro.

ssh-3.gif

En esta captura de pantalla se ofrece el mensaje de registro que aparece cuando PuTTY está configurado para enviar el nombre de usuario al router.

ssh-5.gif

Comandos debug y show

Antes de ejecutar los comandos debug que se describen e ilustran aquí, consulte Important Information on Debug Commands (Información importante sobre los comandos de depuración). Algunos comandos show son compatibles con la herramienta intérprete de resultados ( sólo para clientes registrados) , que permite ver un análisis del resultado del comando show.

  • debug ip ssh: muestra los mensajes de depuración para SSH.

  • show ssh: muestra el estado de las conexiones del servidor SSH.

    carter#show ssh
      Connection    Version Encryption    State              Username
       0            1.5     DES           Session started    cisco
  • show ip ssh: muestra los datos de versión y configuración de SSH.

    • Version 1 Connection and no Version 2

      carter#show ip ssh
        SSH Enabled - version 1.5
        Authentication timeout: 60 secs; Authentication retries: 2
    • Version 2 Connection and no Version 1

      carter#show ip ssh
        SSH Enabled - version 2.0
        Authentication timeout: 120 secs; Authentication retries: 3
    • Version 1 and Version 2 Connections

      carter#show ip ssh
        SSH Enabled - version 1.99
        Authentication timeout: 120 secs; Authentication retries: 3

Ejemplo del resultado de la depuración

Depuración del router

Nota: parte de este útil ejemplo de resultado de depuración se ha unido en varias líneas por cuestiones de espacio.

00:23:20: SSH0: starting SSH control process
00:23:20: SSH0: sent protocol version id SSH-1.5-Cisco-1.25
00:23:20: SSH0: protocol version id is - SSH-1.5-1.2.26
00:23:20: SSH0: SSH_SMSG_PUBLIC_KEY msg
00:23:21: SSH0: SSH_CMSG_SESSION_KEY msg - length 112, type 0x03
00:23:21: SSH: RSA decrypt started
00:23:21: SSH: RSA decrypt finished
00:23:21: SSH: RSA decrypt started
00:23:21: SSH: RSA decrypt finished
00:23:21: SSH0: sending encryption confirmation
00:23:21: SSH0: keys exchanged and encryption on
00:23:21: SSH0: SSH_CMSG_USER message received
00:23:21: SSH0: authentication request for userid cisco
00:23:21: SSH0: SSH_SMSG_FAILURE message sent
00:23:23: SSH0: SSH_CMSG_AUTH_PASSWORD message received
00:23:23: SSH0: authentication successful for cisco
00:23:23: SSH0: requesting TTY
00:23:23: SSH0: setting TTY - requested: length 24, width 80; set:
   length 24, width 80
00:23:23: SSH0: invalid request - 0x22
00:23:23: SSH0: SSH_CMSG_EXEC_SHELL message received
00:23:23: SSH0: starting shell for vty

Depuración del servidor

Nota: este resultado se ha obtenido de una máquina Solaris.

rtp-evergreen.rtp.cisco.com#ssh -c 3des -l cisco -v 10.31.1.99
rtp-evergreen#/opt/CISssh/bin/ssh -c 3des -l cisco -v 10.13.1.99
SSH Version 1.2.26 [sparc-sun-solaris2.5.1], protocol version 1.5.
Compiled with RSAREF.
rtp-evergreen: Reading configuration data /opt/CISssh/etc/ssh_config
rtp-evergreen: ssh_connect: getuid 0 geteuid 0 anon 0
rtp-evergreen: Allocated local port 1023.
rtp-evergreen: Connecting to 10.13.1.99 port 22.
rtp-evergreen: Connection established.
rtp-evergreen: Remote protocol version 1.5,
   remote software version Cisco-1.25
rtp-evergreen: Waiting for server public key.
rtp-evergreen: Received server public key (768 bits)
   and host key (512 bits).
rtp-evergreen: Host '10.13.1.99' is known and matches the host key.
rtp-evergreen: Initializing random; seed file //.ssh/random_seed
rtp-evergreen: Encryption type: 3des
rtp-evergreen: Sent encrypted session key.
rtp-evergreen: Installing crc compensation attack detector.
rtp-evergreen: Received encrypted confirmation.
rtp-evergreen: Doing password authentication.
cisco@10.13.1.99's password:
rtp-evergreen: Requesting pty.
rtp-evergreen: Failed to get local xauth data.
rtp-evergreen: Requesting X11 forwarding with authentication spoofing.
Warning: Remote host denied X11 forwarding, perhaps xauth program
   could not be run on the server side.
rtp-evergreen: Requesting shell.
rtp-evergreen: Entering interactive session.

Qué puede salir mal

En estas secciones se incluyen ejemplos de resultados de depuración de varias configuraciones incorrectas.

SSH desde un cliente SSH no compilado con el Estándar de cifrado de datos (DES)

Depuración de Solaris

rtp-evergreen#/opt/CISssh/bin/ssh -c des -l cisco -v 10.13.1.99
SSH Version 1.2.26 [sparc-sun-solaris2.5.1], protocol version 1.5.
Compiled with RSAREF.
rtp-evergreen: Reading configuration data /opt/CISssh/etc/ssh_config
rtp-evergreen: ssh_connect: getuid 0 geteuid 0 anon 0
rtp-evergreen: Allocated local port 1023.
rtp-evergreen: Connecting to 10.13.1.99 port 22.
rtp-evergreen: Connection established.
rtp-evergreen: Remote protocol version 1.5,
   remote software version Cisco-1.25
rtp-evergreen: Waiting for server public key.
rtp-evergreen: Received server public key (768 bits)
   and host key (512 bits).
rtp-evergreen: Host '10.13.1.99' is known and matches the host key.
rtp-evergreen: Initializing random; seed file //.ssh/random_seed
rtp-evergreen: Encryption type: des
rtp-evergreen: Sent encrypted session key.
cipher_set_key: unknown cipher: 2

Depuración del router

00:24:41: SSH0: Session terminated normally
00:24:55: SSH0: starting SSH control process
00:24:55: SSH0: sent protocol version id SSH-1.5-Cisco-1.25
00:24:55: SSH0: protocol version id is - SSH-1.5-1.2.26
00:24:55: SSH0: SSH_SMSG_PUBLIC_KEY msg
00:24:55: SSH0: SSH_CMSG_SESSION_KEY msg - length 112, type 0x03
00:24:55: SSH: RSA decrypt started
00:24:56: SSH: RSA decrypt finished
00:24:56: SSH: RSA decrypt started
00:24:56: SSH: RSA decrypt finished
00:24:56: SSH0: sending encryption confirmation
00:24:56: SSH0: Session disconnected - error 0x07

Contraseña incorrecta

Depuración del router

00:26:51: SSH0: starting SSH control process
00:26:51: SSH0: sent protocol version id SSH-1.5-Cisco-1.25
00:26:52: SSH0: protocol version id is - SSH-1.5-1.2.26
00:26:52: SSH0: SSH_SMSG_PUBLIC_KEY msg
00:26:52: SSH0: SSH_CMSG_SESSION_KEY msg - length 112, type 0x03
00:26:52: SSH: RSA decrypt started
00:26:52: SSH: RSA decrypt finished
00:26:52: SSH: RSA decrypt started
00:26:52: SSH: RSA decrypt finished
00:26:52: SSH0: sending encryption confirmation
00:26:52: SSH0: keys exchanged and encryption on
00:26:52: SSH0: SSH_CMSG_USER message received
00:26:52: SSH0: authentication request for userid cisco
00:26:52: SSH0: SSH_SMSG_FAILURE message sent
00:26:54: SSH0: SSH_CMSG_AUTH_PASSWORD message received
00:26:54: SSH0: password authentication failed for cisco
00:26:54: SSH0: SSH_SMSG_FAILURE message sent
00:26:54: SSH0: authentication failed for cisco (code=7)
00:26:54: SSH0: Session disconnected - error 0x07

El cliente SSH envía cifrado (Blowfish) no admitido

Depuración del router

00:39:26: SSH0: starting SSH control process
00:39:26: SSH0: sent protocol version id SSH-1.5-Cisco-1.25
00:39:26: SSH0: protocol version id is - SSH-1.5-W1.0
00:39:26: SSH0: SSH_SMSG_PUBLIC_KEY msg
00:39:26: SSH0: SSH_CMSG_SESSION_KEY msg - length 112, type 0x03
00:39:26: SSH0: Session disconnected - error 0x20

Consejos para la resolución de problemas

  • Si los comandos de configuración de SSH se rechazan como no válidos, no se ha generado correctamente un par de claves RSA para el router. Asegúrese de haber especificado un nombre de host y un dominio. A continuación, utilice el comando crypto key generate rsa para generar un par de claves RSA y habilitar el servidor SSH.

  • Cuando configure el par de claves RSA, podría encontrar los siguientes mensajes de error:

    1. No hostname specified

      Deberá configurar un nombre de host para el router con el comando de configuración global hostname.

    2. No domain specified

      Deberá configurar un dominio de host para el router con el comando de configuración global ip domain-name.

  • El número de conexiones SSH permitidas se limita al máximo de VTY configurados para el router. Cada conexión SSH usa un recurso de VTY.

  • SSH emplea seguridad local o el protocolo de seguridad que se ha configurado mediante AAA en el router para la autenticación de usuarios. Cuando configure AAA, deberá asegurarse de que la consola no está en ejecución en AAA mediante la aplicación de una palabra clave en el modo de configuración global para inhabilitar AAA en la consola.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 4145