Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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®.
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).
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 :
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.
Référez-vous à Conventions relatives aux conseils techniques Cisco pour plus d'informations.
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.
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.
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.
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
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
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
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 :
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.
carter(config)#ip ssh version 2
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é.
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
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
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
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.
Les sections suivantes présentent un exemple de sortie de débogage provenant de plusieurs configurations incorrectes.
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
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
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 :
Mettre à zéro toutes les clés RSA.
Rechargez le périphérique.
Créez de nouvelles clés étiquetées pour SSH.
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 :
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.
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.
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
Révision | Date de publication | Commentaires |
---|---|---|
3.0 |
09-Aug-2023 |
Mise à jour de la clause de non-responsabilité, texte et mise en forme |
1.0 |
10-Sep-2001 |
Première publication |