Configurer SSH sur les routeurs et les commutateurs

Introduction

Le présent document décrit comment configurer et déboguer le protocole Secure Shell (SSH) sur les routeurs ou les commutateurs Cisco qui exécutent le logiciel Cisco IOS®.

Conditions préalables

Exigences

L'image Cisco IOS utilisée doit être une image k9 (crypto) afin de prendre en charge SSH. Par exemple, c3750e-universalk9-tar.122-35.SE5.tar est une image k9 (crypto).

Composants utilisés

Les informations contenues dans ce document sont basées sur le logiciel Cisco IOS 3600 (C3640-IK9S-M), Version 12.2(2)T1.

SSH a été introduit dans les plates-formes et images Cisco IOS suivantes :

• L'accès à la ligne de terminal SSH (également connu sous le nom de reverse-Telnet) a été introduit dans les plates-formes et les images Cisco IOS à partir de la version 12.2.2.T du logiciel Cisco IOS.

• La prise en charge de SSH version 2.0 (SSH v2) a été introduite dans les plates-formes et images Cisco IOS à partir de la version 12.1(19)E du logiciel Cisco IOS.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Conventions

Référez-vous à Conventions relatives aux conseils techniques Cisco pour plus d'informations.

Schéma de réseau SSH v2

Test d'authentification

Test d'authentification sans SSH

Testez d'abord l'authentification sans SSH pour vous assurer que l'authentification fonctionne avec le routeur Carter avant d'ajouter SSH. L'authentification peut être effectuée à l'aide d'un nom d'utilisateur et d'un mot de passe locaux ou à l'aide d'un serveur AAA (Authentication, Authorization, and Accounting) qui exécute TACACS+ ou RADIUS. (L'authentification via le mot de passe de ligne n'est pas possible avec SSH.) Cet exemple montre l'authentification locale, qui vous permet d'accéder au routeur via Telnet avec le nom d'utilisateur cisco et le mot de passe cisco.

Remarque : dans ce document, vty est utilisé pour indiquer le type de terminal virtuel.

!--- The aaa new-model command causes the local username and password on the router to be used in the absence of other AAA statements.

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

!--- Instead of aaa new-model, you can use the login local command.

Test d'authentification avec SSH

Afin de tester l'authentification avec SSH, vous devez ajouter aux instructions précédentes afin d'activer SSH sur Carter, et tester SSH à partir du PC et des stations UNIX.

ip domain-name rtp.cisco.com

!--- Generate an SSH key to be used with SSH.

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

À ce stade, la commande show crypto key mypubkey rsa doit afficher la clé générée. Après avoir ajouté la configuration SSH, testez votre capacité à accéder au routeur à partir du PC et de la station UNIX. 

Jeux de configuration facultatifs

Empêcher les connexions non SSH

Si vous voulez empêcher les connexions non SSH, ajoutez la commande transport input ssh sous les lignes pour limiter le routeur aux connexions SSH seulement. Les Telnets directs (non SSH) sont refusés.

line vty 0 4

!--- Prevent non-SSH Telnets.

transport input ssh

Testez pour vous assurer que les utilisateurs non-SSH ne peuvent pas établir de connexion Telnet avec le routeur Carter.

Configurer un routeur ou un commutateur IOS comme client SSH

Il y a quatre étapes nécessaires pour activer la prise en charge de SSH sur un routeur Cisco IOS :

1. Configurez la commande hostname.

2. Configurer le domaine DNS.

3. Générez la clé SSH.

4. Activez la prise en charge du transport SSH pour le vty.

Si vous voulez avoir un périphérique qui joue le rôle de client SSH pour l'autre, vous pouvez ajouter SSH à un deuxième périphérique appelé Reed. Cela place ces périphériques dans un arrangement client-serveur, où Carter agit en tant que serveur et Reed agit en tant que client. La configuration du client Cisco IOS SSH sur Reed est la même que celle requise pour la configuration du serveur SSH sur Carter.

!--- Step 1: Configure the hostname if you have not previously done so.

hostname carter

!--- The aaa new-model command causes the local username and password on the router to be used in the absence of other AAA statements.

aaa new-model
username cisco password 0 cisco

!--- Step 2: Configure the DNS domain of the router.

ip domain-name rtp.cisco.com

!--- Step 3: Generate an SSH key to be used with SSH.

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

!--- Step 4: By default the vty transport is Telnet. In this case, Telnet is disabled and only SSH is supported.

line vty 0 4
transport input ssh

!--- Instead of aaa new-model, you can use the login local command.

Émettez cette commande vers SSH à partir du client SSH Cisco IOS (Reed) vers le serveur SSH Cisco IOS (Carter) pour tester ceci :

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

Configurer un routeur IOS en tant que serveur SSH qui effectue l'authentification utilisateur basée sur RSA

Complétez ces étapes pour configurer le serveur SSH pour effectuer l'authentification basée sur RSA.

1. Spécifiez le nom de l'hôte.

Router(config)#hostname 
    
    

2. Définissez un nom de domaine par défaut.

Router(config)#ip domain-name 
    
    

3. Générez des paires de clés RSA.

Router(config)#crypto key generate rsa

4. Configurez les clés SSH-RSA pour l'authentification des utilisateurs et des serveurs.

Router(config)#ip ssh pubkey-chain

5. Configurez le nom d'utilisateur SSH.

Router(conf-ssh-pubkey)#username 
    
    

6. Spécifiez la clé publique RSA de l'homologue distant.

Router(conf-ssh-pubkey-user)#key-string

7. Spécifiez le type et la version de la clé SSH. (Cette étape est facultative.)

Router(conf-ssh-pubkey-data)#key-hash ssh-rsa 
    
    

8. Quittez le mode actuel et revenez au mode d’exécution privilégié.

Router(conf-ssh-pubkey-data)#end

Ajouter un accès à la ligne de terminal SSH

Si vous avez besoin d'une authentification de ligne de terminal SSH sortante, vous pouvez configurer et tester SSH pour les Telnets inverses sortants via Carter, qui joue le rôle de serveur de communication vers Philly.

ip ssh port 2001 rotary 1
line 1 16
   no exec
   rotary 1
   transport input ssh
   exec-timeout 0 0
   modem InOut
   stopbits 1

Si Philly est connecté au port Carter 2, vous pouvez configurer SSH vers Philly via Carter à partir de Reed avec cette commande :

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

Vous pouvez utiliser la commande suivante de Solaris :

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

Restreindre l'accès SSH à un sous-réseau

Vous devez limiter la connectivité SSH à un sous-réseau spécifique où toutes les autres tentatives SSH provenant d'IP extérieures au sous-réseau sont abandonnées.

Vous pouvez utiliser ces étapes pour faire la même chose :

1. Définissez une liste d'accès qui autorise le trafic à partir de ce sous-réseau spécifique.
2. Limitez l'accès à l'interface de ligne VTY avec une commande access-class.

Voici un exemple de configuration. Dans cet exemple, seul l'accès SSH au sous-réseau 10.10.10.0 255.255.255.0 est autorisé, tout autre accès est refusé.

Router(config)#access-list 23 permit 10.10.10.0 0.0.0.255
Router(config)#line vty 5 15
Router(config-line)#transport input ssh
Router(config-line)#access-class 23 in
Router(config-line)#exit

Remarque : la même procédure de verrouillage de l'accès SSH est également utilisée pour les plates-formes de commutation.

Configuration de SSH version 2

carter(config)#ip ssh version 2

Variations sur la sortie de la commande banner

La sortie de la commande banner varie entre la connexion Telnet et les différentes versions de connexions SSH. Le tableau suivant montre comment les différentes options de la commande banner fonctionnent avec différents types de connexions.

Options de commande Banner	Telnet	SSH v2
journal d'une bannière	S'affiche avant la connexion au périphérique.	S'affiche avant la connexion au périphérique.
banner motd	S'affiche avant la connexion au périphérique.	S'affiche après la connexion au périphérique.
banner exec	S'affiche après la connexion au périphérique.	S'affiche après la connexion au périphérique.

Remarque : SSH version 1 n'est plus recommandé.

Impossible d'afficher la bannière de connexion

SSH version 2 prend en charge la bannière de connexion. Lorsqu'il lance la session SSH avec le routeur Cisco, la bannière de connexion s'affiche si le client SSH envoie le nom d'utilisateur. Par exemple, lorsque le client ssh Secure Shell est utilisé, la bannière de connexion s'affiche. Lorsque le client PuTTY ssh est utilisé, la bannière de connexion n'est pas affichée. En effet, SSH envoie le nom d'utilisateur par défaut et PuTTY n'envoie pas le nom d'utilisateur par défaut.

Le client SSH a besoin du nom d'utilisateur pour établir la connexion au périphérique SSH. Le bouton Connect n'est pas activé si vous n'entrez pas le nom d'hôte et le nom d'utilisateur. Cette image d'écran montre que la bannière de connexion s'affiche lorsque SSH se connecte au routeur. La bannière demande alors un mot de passe.

Bannière de demande de mot de passe

Le client PuTTY ne nécessite pas le nom d'utilisateur pour lancer la connexion SSH au routeur. Cette image d'écran montre que le client PuTTY se connecte au routeur et demande le nom d'utilisateur et le mot de passe. Elle n'affiche pas la bannière de connexion.

Connexion SSH au routeur

Cette capture d'écran montre que la bannière de connexion s'affiche lorsque PuTTY est configuré pour envoyer le nom d'utilisateur au routeur.

Envoyer le nom d'utilisateur au routeur

Commandes debug et show

Avant d'émettre les commandes debug décrites ici, référez-vous à Informations importantes sur les commandes de débogage. Certaines commandes show sont prises en charge par l'outil Output Interpreter Tool (enregistré pour les clients uniquement), qui vous permet d'afficher une analyse du résultat de la commande show.

• debug ip ssh Affiche les messages de débogage pour SSH.

• show ssh Affiche l'état des connexions du serveur SSH.

carter#show ssh
  Connection    Version Encryption    State              Username
   0            2.0     DES           Session started    cisco

• show ip ssh affiche les données de version et de configuration pour SSH.

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

Exemple de sortie de débogage

Débogage du routeur

00:23:20: SSH0: starting SSH control process
00:23:20: SSH0: sent protocol version id SSH-2.0-Cisco-1.25
00:23:20: SSH0: protocol version id is - SSH-2.0-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 

Débogage du serveur

Remarque : il s'agit du résultat de la machine 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 2.0, 
   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. 

Configurations incorrectes

Les sections suivantes présentent un exemple de sortie de débogage provenant de plusieurs configurations incorrectes.

SSH à partir d'un client SSH non compilé avec Data Encryption Standard (DES)

Mot de passe incorrect

Débogage du routeur

00:26:51: SSH0: starting SSH control process
00:26:51: SSH0: sent protocol version id SSH-2.0-Cisco-1.25
00:26:52: SSH0: protocol version id is - SSH-2.0-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 

Envoi, par un client SSH, d'un chiffrement (Blowfish) non pris en charge

Débogage du routeur

00:39:26: SSH0: starting SSH control process
00:39:26: SSH0: sent protocol version id SSH-2.0-Cisco-1.25
00:39:26: SSH0: protocol version id is - SSH-2.0-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 

Erreur d'obtention de « %SSH-3-PRIVATEKEY : Impossible de récupérer la clé privée RSA pour »

Une modification du nom de domaine ou du nom d'hôte peut déclencher ce message d'erreur. Utilisez ces solutions de contournement :

• Mettez à zéro les clés RSA et régénérez-les.

crypto key zeroize rsa label key_name
crypto key generate rsa label key_name modulus key_size

• Si la solution précédente ne fonctionne pas, procédez comme suit :

  1. Mettre à zéro toutes les clés RSA.

  2. Rechargez le périphérique.

  3. Créez de nouvelles clés étiquetées pour SSH.

Conseils 

• Si vos commandes de configuration SSH sont rejetées comme étant des commandes illégales, vous n'avez pas correctement généré une paire de clés RSA pour votre routeur. Vérifiez que vous avez spécifié un nom d'hôte et un domaine. Utilisez ensuite la commande crypto key generate rsa pour générer une paire de clés RSA et activer le serveur SSH.

• Lorsque vous configurez des paires de clés RSA, vous pouvez obtenir les messages d'erreur suivants :

  1. Aucun nom d'hôte spécifié.

     Vous devez utiliser la commande de configuration globale hostname pour configurer un nom d'hôte pour le routeur.

  2. Aucun domaine spécifié.

     Vous devez utiliser la commande de configuration globale ip domain-name pour configurer un domaine hôte pour le routeur.

• Le nombre de connexions SSH autorisées est limité au nombre maximal de vty configuré pour le routeur. Chaque connexion SSH utilise un vty ressource.

• SSH utilise la sécurité locale ou le protocole de sécurité configuré via AAA sur votre routeur pour l'authentification des utilisateurs. Lorsque vous configurez AAA, vous devez vous assurer que la console n'est pas exécutée sous AAA. Appliquez un mot clé en mode de configuration globale pour désactiver AAA sur la console.

• No SSH server connections running:

carter#show ssh

%No SSHv2 server connections running.

Cette sortie suggère que le serveur SSH est désactivé ou pas correctement activé. Si vous avez déjà configuré SSH, il est recommandé de reconfigurer le serveur SSH sur le périphérique. Complétez ces étapes afin de reconfigurer le serveur SSH sur le périphérique.

1. Supprimez les paires de clés RSA. Une fois les paires de clés RSA supprimées, le serveur SSH est automatiquement désactivé.

carter(config)#crypto key zeroize rsa

Remarque : il est important de générer des paires de clés avec au moins 768 bits lorsque vous activez SSH v2.

Attention : cette commande ne peut pas être annulée après l'enregistrement de votre configuration. En outre, une fois les clés RSA supprimées, vous ne pouvez pas utiliser de certificats pour l'autorité de certification ni participer à des échanges de certificats avec d'autres homologues IPSec (IP Security), sauf si vous régénérez les clés RSA pour reconfigurer l'interopérabilité de l'autorité de certification, obtenir le certificat de l'autorité de certification et demander à nouveau votre propre certificat.

2. Reconfigurez le nom d’hôte et le nom de domaine du périphérique.

carter(config)#hostname hostname

carter(config)#ip domain-name domainname

3. Générez des paires de clés RSA pour votre routeur. Cela active automatiquement SSH.

carter(config)#crypto key generate rsa

Remarque : référez-vous à crypto key generate rsa - Cisco IOS Security Command Reference, Release 12.3 pour plus d'informations sur l'utilisation de cette commande.

Remarque : vous pouvez recevoir le message d'erreur SSH2.0 : type de message inattendu reçu en raison d'un paquet reçu qui n'est pas compréhensible par le routeur. Augmentez la longueur de clé tandis que vous générez des clés RSA pour SSH afin de résoudre ce problème.

4. Configurez le serveur SSH.

5. Pour activer et configurer un routeur/commutateur Cisco pour le serveur SSH, vous devez configurer les paramètres SSH. Si vous ne configurez pas de paramètres SSH, les valeurs par défaut sont utilisées.

ip ssh {[timeout seconds] | [authentication-retries integer]}

carter(config)# ip ssh

Informations connexes

• Pages d'assistance sur les produits SSH