Ssh - cisco

L'administration d'un équipement Cisco se fait généralement via le protocole Secure SHell (SSH). Il est nécessaire d'appliquer quelques paramètre pour l'activer.

Session SSH

L'activation de SSH sous Cisco IOS passe par quelques commandes comprenant notamment, la création d'un utilisateur, d'une clé ainsi que des critères de sessions.

configure terminal
# Création de l'utilisateur
username <utilisateur> privilege 15 secret <motdepasse>
# Création des la clés
crypto key generate rsa modulus 4096 usage-keys label <FQDN>
# Activation de la version 2 du protocole SSH (normalement c'est automatique)
ip ssh version 2
# Paramétrage des sessions SSH sur les consoles virtuelles
line vty 0 4
# Activation des connexions en utilisant la base utilisateur locale
login local
# Modification de la durée de la session (définie à 3 minutes)
exec-timeout 0 3
# Activation des connexions entrantes
transport input ssh
# Activation des connexions sortantes
transport output ssh

# Il est également possible de journaliser les évènements en rapport avec SSH lorsque l'on est connecté via ce protocole (sinon cela se fait uniquement via le port série)
configure terminal
ip ssh logging events

Bien que ce protocole serve principalement à établir une sessions distante à un équipements, elle ne se limite pas à ça et certaines autres fonctions peuvent êtres utilisées avec les matériels réseau de cette marque.

Authentification par clé publique

Afin de limiter considérablement les intrusions, une bonne pratique est l'utilisation de clés SSH en lieu et place d'un mot de passe pour l'authentification (et donc la connexion) d'un utilisateur.

Création de la clé

Sur une machine Linux avec OpenSSH, générer une clé RSA 4096 bits (on ne peut malheureusement pas utiliser de clés à courbes elliptiques pour SSH sur IOS...) :

ssh-keygen -t rsa -b 4096

La clé doit être entrée tronquée à 72 caractères par ligne dans la configuration de l'équipement réseau :

fold -b -w 72 ~/.ssh/id_rsa.pub

Note : le retour de cette commande devra être utilisé comme paramètre de key-string dans la section suivante (un exemple y est exposé).

INFORMATION

Il est possible d'afficher l'empreinte de la clé via la commande ssh-keygen -l -f ~/.ssh/id_rsa.pub.

Injection de la clé

Sur IOS, la clé précédemment créée doit être injecté pour un utilisateur en particulier. Elle servira à la connexion sans mot de passe utilisateur (une phrase de passe peut être définie sur la clé elle-même).

ip ssh pubkey-chain
 username <utilisateur>
  key-string
  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCum86GEuj2OA23LWMUX+jExuLhbhGNDijv
TZG3wtfObh5PSoLHXAq7CeKAb+bpqr17IXXcaBeAKnX+IFEOlq4iTslfjcBaDuzi5fi+o62k
1kr0gM4/lK9FCsDFShtkUf29+wIe9JXolaEFXnq49ErsouSkll71l78Tc2DoWIZGKvRbNqDN
kfRA1a50dNga/10WxuANqvlIdOyuS2koO/FeopFgADWH69GRSOlsv7NvHRUXj+kzLpQfoJvL
sYk2yyhcAI0zWCSwy1cCMeUIsfxQGZW+jf3w6ronAorw9iz8A8IItXoQRrVOYddZXmOSBxBs
jP4aFn9HSsDv+SY43xnRl5oj/1iveVwPah1V2exzZgRmFfMSygDx4fPIelQdaq/o4kA2fqHD
bQhO2w2hUciYsbTx4zs4MoGfGFfhK0rBOX8FMf+1bNBORrQu2HbbwRdhEMrQ9yNMxpRKzeyP
QjBDIKEOSR0muRBDk9/avCUa0l6iiaFclTumbdHhPoZkvbjkE/FjEQ4a7X3dg9BgnPi2H/Ci
RzrwZm+C/WAqubsmVbig/oSiB/vI4qf0ckyhWa9ntq3pene82/2B4vj2sv4IfMp6+yMsfK4A
OHdRtQie94Fkrt9hXVQsWoTedKr03U6nwbjOtso8MxHbN9uEU3eOAg9PWKO0P/MtLZ5VEpDq
kw== root@debian
dxpSoWLwQPvRDqHjuADR
  exit
 exit
exit

Cette clé peut être visualisée avec la commande suivante :

show running-config | section pubkey

Source de la section

• https://networklessons.com/uncategorized/ssh-public-key-authentication-cisco-ios

Transferts de fichiers via SSH

Les transferts de fichiers au travers d'SSH permettent un échange chiffré de données. IOS gère Secure Copy (SCP), un protocole se basant sur UNIX BSD RCP et utilisant SSH pour le chiffrement. Il faut au préalable avoir activé ce dernier pour que SCP fonctionne.

Une petite précision qui a son importance. L'implémentation d'SCP dans IOS ne gère pas la récursivité (-r) contrairement à son homologue UNIX/Linux. Si vous avez un répertoire à transférer, baaah, bon courage...

En tant que client

L'utilitaire copy permet d'initier des transferts avec un serveur. En voici la syntaxe :

copy <fichier_source> scp://<utilisateur>@<adresse>:<destination>

ATTENTION

La <destination> doit être précédée de deux / dans le cas d'un chemin partant de la racine distante.

copy flash:/c3560cx-universalk9-mz.152-4.E5/c3560cx-universalk9-mz.152-4.E5.bin scp://toto@192.168.1.10://tmp/

En tant que serveur

Afin de réceptionner des transferts initiés par un hôte distant, Cisco IOS intègre un module serveur Secure Copy (SCP). Pour l'activer, rien de plus simple :

ip scp server enable

ASTUCE

Depuis un client OpenSSH, il faudra user de la syntaxe suivante : scp c3560cx-universalk9-mz.152-7.E2.bin toto@192.168.1.53:c3560cx-universalk9-mz.152-7.E2/c3560cx-universalk9-mz.152-7.E2.bin ou bien en précisant les paramètres cryptographiques ainsi que le périphérique de destination: scp -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc c3560cx-universalk9-mz.152-7.E2.bin toto@192.168.1.53:flash:/c3560cx-universalk9-mz.152-7.E2/c3560cx-universalk9-mz.152-7.E2.bin. Notez bien que le nom final du fichier doit être précisé en destination, sous peine d'avoir un avortement de la connexion avec le message ETAlost connection. Aucun / ne doit être précisé au début du chemin.

Connexion depuis OpenSSH

Pour des raisons de sécurité, avec les versions d'OpenSSH récentes, les suites cryptographiques utilisées par IOS ne correspondent pas à celles définies dans la configuration par défaut du célèbre client libre (depuis GNU/Linux Debian >= Jessie). En effet, comme à son habitude, Cisco est à la traîne dans le support des standards. Les algorithmes tant de chiffrement que de signature supportés sont complètements obsolètes (car dangereux) et sortis des recommandations internationales depuis plus de 10 ans (N'utilisez pas le SSH des équipements de cette marque depuis Internet) ! Il est possible de fixer manuellement ce paramètre sur l'équipement réseau (si supporté par votre modèle) et de préciser au client quel algorithme utiliser pour la connexion. Enfin, avec les modèles derniers cris, ces problèmes ne devraient pas se manifester (chez Cisco, la "sécurité", ça se paie).

Sur IOS

Afin de définir la suite cryptographique que l'on souhaite utiliser lors des sessions SSH, on peut utiliser la commande suivante en mode "configuration" :

ip ssh server algorithm encryption aes256-cbc aes192-cbc aes128-cbc

Note : les algorithmes sont visibles avec le traditionnel ?.

Sur OpenSSH

Client OpenSSH

Dans la commande

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c aes128-cbc <utilisateur>@<adresse>

Dans la configuration

Il est également possible de préciser au client d'utiliser cette configuration directement dans son fichier. Ainsi, la commande standard pourra être utilisée de façon transparente.

vim ~/.ssh/config

Host 10.0.0.1
	KexAlgorithms +diffie-hellman-group1-sha1

Serveur OpenSSH

Si c'est le matériel réseau qui doit se connecter au Linux, il faut éditer la configuration du service SSHd et ajouter les deux algorithmes supportés par IOS tout en conservant ceux par défaut (afin de continuer à pouvoir se connecter au serveur) :

echo -e "Ciphers +aes128-cbc\nKexAlgorithms +diffie-hellman-group1-sha1" >> /etc/ssh/sshd_config
systemctl restart ssh.service

Vous pouvez en afficher la liste exhaustive avec les commandes suivantes :

ssh -Q server
ssh -Q kex

Afin de vous éviter le supplice de faire des copier/coller dans tous les sens en supprimant les retours chariots et en joutant des virgules pour les ajouter dans la configuration, vous pouvez utiliser les scripts suivants dans l'ordre respectif :

for i in $(ssh -Q cipher); do suite=$suite$(echo "${i}," | tr -d "\n"); done; echo "${suite%?}"

for i in $(ssh -Q kex); do suite=$suite$(echo "${i}," | tr -d "\n"); done; echo "${suite%?}"

Enfin, il est possible de lister les valeurs actuellement appliquées au service SSHd :

sshd -T | grep ciphers
sshd -T | grep kex