telnet- protocole de base OS UNIX, permettant à l'utilisateur du terminal d'accéder à un ordinateur distant.

Initialement, le terminal était un appareil de type machine à écrire sur lequel l'opérateur (utilisateur) tapait des commandes et observait les résultats. Le terminal a ensuite été divisé en un moniteur et un clavier.

Par défaut, Telnet utilise le port 23. La partie serveur doit être exécutée sur l'ordinateur distant et la partie client doit être exécutée sur l'ordinateur de l'utilisateur. Le programme client porte le même nom - telnet et vous permet de saisir des paramètres à partir de la ligne de commande. Ces options incluent :

Nom du serveur (adresse IP) et numéro de port

Type de terminal texte

Nom d'utilisateur

Nom du journal de connexion

Détermination des actions de certaines touches de fonction du clavier, etc.

Syntaxe ligne de commande dépend de l'implémentation logicielle de telnet et de ce point de vue, telnet peut être considéré comme un service ou un service.

Le fonctionnement du protocole telnet prévoit la transmission au serveur (ordinateur distant) via le protocole TCP de chaque caractère tapé par l'utilisateur dans un paquet distinct. Si l'écho est activé, le serveur renvoie le caractère sur le moniteur de l'utilisateur. Les résultats de l'exécution des programmes exécutés sur le serveur sont déjà transmis par blocs. Dans les limites des droits d'utilisateur et des capacités du terminal, telnet fournit un accès complet aux programmes et fichiers du serveur. Lorsqu'une connexion est établie pendant le processus d'authentification, les caractères du nom d'utilisateur et du mot de passe sont transmis à formulaire ouvert, ce qui rend l'utilisation de telnet extrêmement dangereuse.

La méthode la plus répandue pour accroître la sécurité des protocoles des terminaux d'application (par exemple telnet) est le protocole SSH (Secure SHell), qui utilise le port 22 par défaut. Tout comme dans telnet, la partie serveur de SSH est lancée sur l'ordinateur distant et la partie client est lancée sur l'ordinateur utilisateur. Une fois la connexion établie, toutes les données sont transmises sous forme cryptée et toutes les données du protocole d'application sont tunnelisées via cette connexion sécurisée, comme le montre la figure 3.5.3.1.

Avant d'utiliser telnet, l'ordinateur distant et l'ordinateur de l'utilisateur établissent une connexion sécurisée sur le port 22 (on suppose que des mots de passe cryptographiques ont déjà été définis dans les parties client et serveur avant d'utiliser SSH). Lorsque vous appelez telnet, le port 23 est ouvert, mais les paquets transmis sont interceptés par le client SSH, cryptés et envoyés sur un canal sécurisé. Le serveur SSH décrypte les données et les envoie au serveur telnet sur le port 23. La réponse du serveur est transmise dans l'ordre inverse. L'utilisateur ne ressent pas le fonctionnement du protocole SSH et fonctionne comme avec un client telnet classique sur le port 23.

Protocoles de messagerie

Le courrier électronique (E-mail) est l'un des services réseau les plus anciens et les plus courants, populaire à la fois dans les réseaux locaux et mondiaux.

Système E-mail est apparu en 1982 en tant que service pour l'ancêtre d'Internet, l'ARPANET. Ce système différait sensiblement de la série de recommandations X.400 adoptées par le CCITT. La complexité des recommandations X.400 et leur nature mal conçue ont conduit à un problème rare technologies de réseau l'occasion où le développement d'initiatives a remporté la norme internationale. Les services de messagerie conformes à X.400 ne sont pas largement utilisés et présentent un intérêt plus scientifique.

Un message électronique, comme un courrier ordinaire, contient une enveloppe contenant les informations nécessaires à la livraison, un en-tête contenant des données utiles au traitement automatisé par le destinataire et le message lui-même.

L'enveloppe et l'en-tête ont des champs formalisés. Les plus importants d'entre eux sont (les champs obligatoires que l'expéditeur doit remplir sont en gras) :

Puis : - adresse(s) du(des) destinataire(s) au format nom_boîte aux lettres@nom_serveur de messagerie

Сс : - (copie carbone) adresse(s) du ou des destinataires supplémentaires

Cci : - (copie carbone invisible) adresse(s) aveugle(s) du(des) destinataire(s) non communiquée(s) aux autres

Expéditeur : - adresse email de l'expéditeur

Reçu : - un champ où, au passage de chaque nœud, sont ajoutés le nom du nœud, la date et l'heure de réception

Return-Path : - noms des nœuds sur le chemin de la lettre

Date : - date et heure d'envoi de l'e-mail

Répondre à : - adresse à laquelle répondre

Message-id : - identifiant de message unique (pour les liens)

In-Reply-id : - identifiant du message auquel la réponse est donnée

Objet : - objet de l'e-mail

Le corps du message est un ensemble de chaînes de 1 000 maximum (jusqu'à 78 recommandés) caractères ASCII (American Standard Code for Information Interchange), c'est-à-dire des nombres de 7 bits représentant des lettres latines, des signes de ponctuation et des chiffres (populaire pour une telle représentation est le terme « codage »). Les symboles des codages nationaux (par exemple, des caractères cyrilliques), des fichiers binaires (par exemple, avec des informations audio ou vidéo), etc. sont affichés conformément à la convention MIME (MultiPurpose Internet Mail Extension), qui fournit un champ indiquant la méthode de codage ( par exemple Base64 - voir paragraphe 3.5.2).

La méthode de base pour garantir la confidentialité du courrier électronique est sa protection cryptographique. Le système le plus populaire s’appelle PGP (Pretty Good Privacy). Ce système a été proposé par Phil Zimmerman et utilise plusieurs algorithmes de chiffrement (RSA, IDEA, MD5).

Un autre système est appelé PEM (Privacy Enhanced Mail - courrier à secret accru) et diffère de PGP par la nécessité de communiquer avec les autorités de certification de clés, un degré de protection inférieur (pour le cryptage des données dans le système PGP, les clés ont une longueur de 128 bits et dans le système PEM - seulement 56 bits), mais en totale conformité avec les recommandations ITU-T (X.400 et X.509).

Les protocoles de messagerie se caractérisent par une variété importante, depuis les produits de marque adaptés aux produits logiciels de fabricants spécifiques jusqu'à ceux généralement reconnus. Nous parlons des protocoles des systèmes de messagerie, et non des systèmes courants d'émulation de services de messagerie basés sur le protocole HTTP (voir, par exemple, www. mail. ru).

Les protocoles de messagerie incluent :

SMTP (Simple Mail Transfer Protocol - un simple protocole de messagerie) est un protocole utilisé pour échanger du courrier entre des nœuds et envoyer des lettres d'un client à un serveur de messagerie. Par défaut, le protocole utilise le port 25.

POP3 (Post Office Protocol v.3 - protocole de messagerie version 3) - un protocole de réception de courrier par un client. Par défaut, le protocole utilise le port 110.

IMAP v4 (Internet Message Access Protocol v.4 - protocole d'accès interactif au courrier électronique version 4) est un protocole similaire à POP3, mais permet au client de stocker et de traiter le courrier sur le serveur de messagerie lui-même. Par défaut, le protocole utilise le port 585

Protocole SMNP

SNMP (Simple Network Management Protocol) a été initialement développé pour gérer les routeurs, mais a depuis été étendu à tous les périphériques réseau (ports 161/162 par défaut). Actuellement, la version 2 du protocole (1999) est pertinente.

Le protocole est construit sur le principe client-serveur (le programme client doit être exécuté sur le périphérique réseau géré) et comprend le protocole de gestion (interaction entre les nœuds gérés et de gestion), le langage ASN.1 (Abstract Syntax Notation v.1 - Abstract Syntax Notation v.1) descriptions du modèle de gestion et du modèle de gestion MIB (Management Information Base) lui-même. La diffusion du protocole est entravée par sa faible sécurité et sa concentration sur l'utilisation du protocole UDP, conduisant à une éventuelle perte de messages DNS.

La tâche de résolution des noms implique de déterminer l'adresse IP d'un nœud à partir de son nom symbolique et de déterminer le nom symbolique à partir d'une adresse IP donnée.

Historiquement, le premier mécanisme de résolution de noms, mais toujours valable, est associé à la définition directe de la table de correspondance entre les noms symboliques et les adresses IP dans le fichier hosts/lmhosts (le premier fichier est utilisé par UNIX/Linux et certains autres systèmes d'exploitation (OS), et le second est utilisé par le système d'exploitation Microsoft). Les deux fichiers sont des fichiers texte et leurs formats et clés peuvent être trouvés dans MS Windows dans des fichiers du même nom avec l'extension . Sam (échantillon) Évidemment, pour tout grand réseau, il n'est pas complètement possible de résoudre le problème de cette manière, même si l'écriture d'informations sur les principaux serveurs, routeurs, passerelles, etc. dans ces fichiers est très efficace pour accélérer le démarrage d'un ordinateur dans un environnement en réseau.

Une autre méthode de résolution de noms assez populaire consiste à utiliser NetBIOS (Network Basic Input/Output System) sur TCP/IP. Ce système a été développé conjointement par Microsoft et IBM dans les années 1980 en tant que service d'E/S réseau pour le système d'exploitation. Systèmes Windows. Plus tard, pour implémenter l'accès des utilisateurs aux ressources réseau, le protocole NetBEUI (NetBIOS Extended User Interface) a été développé comme protocole réseau principal dans Windows pour Workgroups et NT. Enfin, avec l'omniprésence de la pile TCP/IP, Microsoft a été contraint de publier une implémentation NetBIOS qui utilise IP pour transférer les données nécessaires (NetBIOS sur TCP/IP). NetBIOS est toujours pris en charge dans Windows 2000/NT/XP, mais pas comme mécanisme principal d'accès aux ressources réseau. NetBIOS est utile pour les petits réseaux peer-to-peer.

Initialement, chaque nœud d'un réseau NetBIOS possède un nom symbolique (jusqu'à 15 caractères) avec un identifiant de ressource (16ème caractère) qui indique le rôle du nœud (serveur de fichiers, serveur d'impression, poste de travail, etc.). NetBIOS "pur" n'est applicable qu'aux petits réseaux et est considéré comme "non routable" car -

le système de nommage ne permet pas d'identifier le réseau

les requêtes de diffusion sont largement utilisées pour obtenir et mettre à jour des informations sur les nœuds du réseau (la plupart des routeurs n'autorisent pas les requêtes de diffusion)

Pour pallier ces lacunes, Microsoft a proposé le service WINS (Windows Internet Name Service - service Windows Noms Internet) basés sur des serveurs de noms NetBIOS. Il convient de noter que malgré la mention d'Internet, WINS n'est pas utilisé dans ce domaine. réseau mondial.

Le premier inconvénient de NetBIOS est résolu dans WINS en introduisant un nom de communauté pour le réseau, et le second par le fait que les requêtes de résolution de nom sont adressées à des serveurs WINS spécifiques. L'instabilité du service, les difficultés administratives et la difficulté de l'utiliser sur l'Internet mondial ont désormais contraint Microsoft à passer au support DNS complet.

DNS (Domain Name System - système de noms de domaine) est implémenté à l'aide du protocole d'application du même nom, qui utilise le port 53 par défaut. Le système DNS a été développé au sein du système d'exploitation UNIX et le service correspondant utilisant DNS porte la même abréviation, mais signifie Domain Name Service.

Les noms dans DNS sont construits hiérarchiquement sous la forme d'un arbre inversé. Les domaines de premier niveau (racines) sont répartis selon le principe professionnel (. com - commercial, . gov - état, . net - réseau, etc. nœuds) ou national (. ru - russe, . fi - finlandais, . fr - Français, etc. d.). Le système d'exploitation UNIX a été développé aux États-Unis et, bien entendu, on supposait que tous les nœuds s'y trouvaient. Vous pouvez désormais voir des noms de domaine doubles, par exemple. com. tw - taïwanais commercial.

A son tour, chaque domaine contient un sous-domaine dont le nom est ajouté à gauche et séparé par un point, etc.. L'entrée se termine par l'ajout du nom d'hôte à gauche. Le nom de chaque domaine, sous-domaine ou hôte ne doit pas dépasser 63 caractères et le nom complet ne doit pas dépasser 255 caractères. Les noms sont traditionnellement utilisés en alphabet latin, chiffres et tirets (le signe _ n'est pas autorisé), mais, en principe, il est possible d'enregistrer un domaine avec un nom en cyrillique, mais la signification de celui-ci est problématique.

Les données sur les noms des sous-domaines/hôtes enregistrés dans n'importe quel domaine et leurs adresses IP sont stockées dans deux tables sur les serveurs DNS, qui contiennent également le nom et l'adresse du domaine sus-jacent. Selon le premier tableau, pour un nom symbolique donné, une adresse numérique est déterminée (conversion directe et, par conséquent, ce qu'on appelle la « zone directe »), et dans le deuxième tableau, un nom symbolique est situé à une adresse donnée ( conversion inverse et "zone inverse").

Pour augmenter la fiabilité, chaque domaine doit disposer d'au moins 2 serveurs (primaire - primaire et secondaire - sauvegarde), et physiquement ces serveurs doivent être situés dans des réseaux différents et ne peuvent pas être situés dans les domaines dont ils contiennent les noms d'hôte.

Le domaine racine est pris en charge par plus de 10 serveurs DNS, dont les adresses IP et les noms sont « câblés » dans les systèmes d'exploitation réseau. L'enregistrement des nouveaux noms et l'attribution des adresses IP correspondantes sont effectués par le propriétaire du domaine. Par exemple, l'enregistrement de domaine. ru est produit par RosNIIROS, où l'enregistrement d'un nom et l'obtention d'une adresse IP coûteront environ 50 $, et la prise en charge annuelle de l'adresse coûtera 10 $. Toutes les modifications dans la table des noms sont effectuées sur le serveur principal. Serveur dns, les serveurs de secours mettent uniquement à jour leurs enregistrements par rapport aux enregistrements du serveur principal. La réplication (mise à jour) de la zone est effectuée à l'aide d'un Protocole TCP, tandis que pour Requêtes DNS clients, le protocole UDP est utilisé. Pour accélérer le processus de résolution de noms et réduire le trafic sur le réseau, des serveurs de cache DNS sont parfois installés, qui enregistrent les noms et adresses fréquemment utilisés. Le mode de fonctionnement du serveur DNS peut être récursif et non récursif. Dans le cas du mode récursif, s'il est impossible de résoudre une requête DNS, cette requête est diffusée vers un autre serveur DNS spécialement spécifié (forwarder - forfarders), qui renvoie ensuite la réponse reçue. En mode non récursif - en l'absence d'informations sur le nœud demandé, les serveurs DNS racine sont contactés, et à partir d'eux en aval jusqu'à ce qu'une réponse soit reçue.

NAT (Network Address Translation - traduction d'adresses réseau) implémente la conversion (substitution) des adresses IP réseaux locaux aux adresses IP externes de l’Internet mondial. La nécessité d'une telle transformation découle de l'accord sur l'utilisation d'une partie des adresses IP uniquement dans les réseaux locaux (voir clause 3.2), selon lequel les routeurs WAN détruisent les paquets avec ces adresses.

NAT fonctionne au niveau du réseau et partiellement au niveau du transport, assurant la traduction dans les paquets IP des adresses des nœuds du réseau local en une adresse externe. La transformation s'effectue en remplaçant l'adresse du nœud interne par l'adresse externe. Les adresses à remplacer sont stockées dans une table, qui est utilisée pour annuler le remplacement lorsqu'un paquet de réponse est reçu. Il convient de noter que afin d'éliminer une éventuelle indiscernabilité, non seulement l'adresse IP est convertie, mais également à l'aide du numéro de port PAT (Port Address Translation).

En plus de la traduction d'adresses, NAT réduit le besoin d'adresses IP pour les réseaux mondiaux, puisque tous les utilisateurs du réseau local peuvent accéder aux ressources du réseau mondial via une adresse externe.

NAT n'est pas le seul moyen d'envoyer des paquets du réseau local vers le réseau mondial, une alternative à la traduction d'adresses consiste à utiliser un serveur intermédiaire.

SSH (Secure Shell) est un protocole réseau accès à distance A qui utilise le cryptage et la compression pour les données transmises. En termes simples, il s'agit d'un outil très utile et puissant qui vous permet de vous authentifier dans le système et de travailler pleinement au nom d'un utilisateur local, se trouvant à plusieurs kilomètres d'une machine en marche. De plus, contrairement à telnet et rsh, SSH crypte tout le trafic afin que toutes les informations transmises restent confidentielles.

Ainsi, ssh est déjà installé et ssh-daemon est ajouté au chargement automatique au démarrage du système. Vous pouvez le contrôler avec la commande :

service ssh arrêter | démarrer | redémarrer

Sur Ubuntu, ou :

/etc/init.d/ssh (démarrer|arrêter|recharger|force-reload|restart|status)

Sur Debian, ou :

systemctl démarrer | arrêter | redémarrer sshd.service

Sous ArchLinux (après chaque édition de la config, il faut redémarrer). Le package comprend un client et un serveur.

Essayons-le en action ! Tout d'abord, créez un dossier ~/.ssh

mkdir ~/.ssh

Générer des clés pour cet utilisateur serveur avec la commande :

ssh-keygen (en tant qu'utilisateur normal).

Lors de la génération, vous pouvez définir une phrase secrète pour la clé (de préférence définie, et longue - alors même après avoir obtenu la clé mais ne connaissant pas le mot de passe de la clé, l'attaquant ne pourra pas se connecter), ou vous pouvez ignorer en appuyant simplement sur "Entrée" - dans ce cas, le mot de passe ne sera jamais demandé. Les mêmes clés publiques et privées sont apparues dans le dossier ~/.ssh.

Trouvez une autre machine (même un smartphone fera l'affaire - il existe d'excellents clients SSH sur Android, comme ConnectBot ou JuiceSSH), installez ssh dessus et connectez-vous au serveur avec la commande :

ssh utilisateur@serveur

Si tout est fait correctement, le mot de passe de l'utilisateur sera demandé et après l'avoir entré, vous vous retrouverez dans votre système avec une vue depuis la ligne de commande.

Pour Windows, il existe également des serveurs et des clients SSH.

Après avoir apprécié le résultat de notre travail, passons à la partie encore plus ennuyeuse : la configuration du client/serveur.

La configuration côté client est en cours /etc/ssh/ssh_config, et le serveur - /etc/ssh/sshd_config. La plupart guide complet pour la configuration, il s'agit probablement de la page de manuel - man ssh et man sshd_config, nous vous recommandons donc de la lire. Et dans cet article, nous examinerons les choses les plus nécessaires.

Paramètre

Le port ssh standard est 22. Il peut être remplacé par n'importe quel port non standard (compliquant un éventuel piratage en raison de la sécurité par l'obscurité, ou pour attirer l'attention de pirates potentiels :) - pour ce faire, décommentez la ligne :

#Port 22

Et ajoutez ce que vous voulez jusqu'à 65535 (en vous assurant que le port n'entre pas en conflit avec d'autres services avec la commande #netstat -tupln | grep ECOUTER).

Désormais, lors de la connexion au serveur, le client devra écrire avec la clé :

ssh -p [port] :

Par défaut, l'accès root est autorisé. Il est hautement souhaitable de le restreindre (et de délimiter correctement les droits de l'utilisateur local avec sudo). Pour ce faire, recherchez la ligne "PermitRootLogin" et modifiez la valeur en "no". Vous pouvez également le remplacer par "sans mot de passe" - dans ce cas, la connexion en tant que root ne sera autorisée que sous les machines disposant d'une clé de confiance.

Vous pouvez désactiver l'authentification par mot de passe et travailler uniquement avec des clés - recherchez la ligne : "PasswordAuthentication" et remplacez la valeur par "non". Pour quoi? Si quelqu'un veut vraiment accéder à votre système, il peut soit forcer brutalement le mot de passe lorsqu'il tente d'autoriser, soit écouter et décrypter votre connexion. Si vous désactivez l'authentification par mot de passe et ajoutez la clé publique de votre ordinateur portable de travail, par exemple, à ~/.ssh/authorized_keys sur le serveur, alors, comme nous nous en souvenons, nous serons immédiatement autorisés à accéder au serveur. Mais que se passe-t-il si vous travaillez sur la machine de quelqu'un d'autre et que vous avez un besoin urgent d'accéder au serveur ssh, mais qu'il ne nous laisse pas entrer comme prévu ? Ensuite, vous ne pouvez pas désactiver l'authentification par mot de passe, mais utiliser l'utilitaire fail2ban. Installez-le simplement à partir de votre référentiel, après quoi il appliquera les paramètres par défaut et, au minimum, protégera votre canal ssh contre les attaques par force brute. En savoir plus sur fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.

Si votre serveur dispose des clés pour lancer des missiles nucléaires, vous pouvez faire quelque chose comme ceci :

PermitRootLogin no - la connexion sous root est interdite.

Mot de passeAuthentification non - connexion sans mot de passe

Générons une clé longue sur la machine distante (-t effectivement_type_de_cryptage, -b longueur en bits) :

ssh-keygen -t rsa -b 4096

Avec une phrase secrète tout aussi complexe (récupérer mot de passe oublié, d'ailleurs, c'est impossible. Vous pouvez le changer avec la commande "ssh-keygen -p", mais l'ancien vous sera quand même demandé). Déplacez la clé publique de la machine locale distante vers le serveur ~/.ssh/authorized_keys, et le tour est joué, vous pouvez désormais y accéder à partir d'une seule machine en utilisant la phrase secrète de la clé privée. SSH vous permet de configurer de nombreuses configurations de sécurité et propose de nombreux paramètres spécifiques pour cela - lisez-les dans man.

Deux options sshd_config ont le même objectif :

ConnexionGraceTime- définit le temps après lequel la connexion sera déconnectée si l'authentification n'a pas lieu.

MaxAuthTries- définit le nombre de tentatives de connexion invalides, après quoi la connexion sera interrompue.

Sessions maximales- le nombre de sessions simultanées (si le serveur est le vôtre) ordinateur de famille, auquel vous allez vous connecter depuis l'université ou depuis le travail, alors il serait raisonnable de limiter le nombre de sessions à une - une connexion refusée, dans ce cas, deviendra une raison pour augmenter la paranoïa, générer de nouvelles clés et changer le mot de passe). Cependant, si vous faites attention, vous remarquerez peut-être qu'à chaque connexion au serveur, la ligne « Dernière connexion » s'affiche. En plus de cela, vous pouvez ajouter votre propre message de bienvenue - recherchez la ligne "Bannière" et au lieu d'aucune, définissez le chemin d'accès au fichier avec le texte qui sera lu et affiché lors de la connexion.

Entre autres choses, vous pouvez autoriser uniquement certains utilisateurs à se connecter, ou autoriser tout le monde sauf certains utilisateurs :

Autoriser les utilisateurs utilisateur1- autoriser la connexion uniquement à l'utilisateur 1.

Refuser les utilisateurs utilisateur1- autoriser tout le monde sauf l'utilisateur 1.

Et des options similaires pour accéder à certains groupes - AllowGroups et DenyGroups.

Vous pouvez également transférer une session X11 via SSH. Pour ce faire, recherchez la ligne "ForwardX11" et modifiez la valeur en "oui".

Recherchez une ligne similaire dans la configuration du client - /etc/ssh/ssh_config, et remplacez-la également par "oui".

Vous devez maintenant vous connecter au serveur via ssh avec l'argument -X :

ssh -X utilisateur@serveur>

Vous pouvez immédiatement lancer l'application dès la connexion :

ssh -X utilisateur@serveur "application"

Voici à quoi ressemble un GIMP en cours d'exécution dans une session ssh :

Ou vous pouvez obtenir la sortie de la webcam de l'ordinateur portable d'un utilisateur sans méfiance :)

Les calculs sont effectués directement sur le serveur et le résultat est transféré à la machine client (c'est-à-dire même si le serveur lui-même ne dispose pas de X11, applications graphiques peut être rendu sur votre machine distante). Ce schéma fonctionne assez lentement (n'oubliez pas que tout le trafic est crypté dynamiquement) - mais cette fonction est très utile.

Vous pouvez également copier des fichiers via une session SSH - il existe un simple utilitaire "scp" pour cela. Vous pouvez transférer des fichiers directement dans la session du serveur vers le client :

scp user@server:/path/to/file/on/server/where/to/save/on/local/machine

Donc du client au serveur :

chemin scp/vers/client/fichier utilisateur@serveur :/chemin/vers/serveur

C'est très pratique si vous devez copier un texte ou une photo, mais que se passe-t-il si vous devez travailler avec de nombreux fichiers ? Pour ce faire, il existe la chose la plus pratique - sshfs (disponible pour l'installation dans les référentiels de la plupart des systèmes * nix).

Définissez simplement le chemin de la même manière que scp :

sshfs utilisateur@serveur :/home/user /mnt/

Et le dossier /home/user du serveur apparaîtra sur le point de montage /mnt de la machine locale !

Le démontage se fait via umount.

Et enfin, parlons d'une fonctionnalité peu connue. Si vous créez un fichier /.ssh/config et remplissez-le comme ceci :

hôte [nom]

nom d'hôte

Utilisateur [nom d'utilisateur du serveur]

options souhaitées

comme

ForwardX11 oui

Port 30000

Ensuite, nous pouvons nous connecter par :

chut [nom]

ssh -X -p 30000 utilisateur@serveur

Et toutes les options seront sélectionnées automatiquement. Ainsi, avec une authentification fréquente sur un serveur spécifique, vous simplifierez ce processus en quelques instants.

Eh bien, nous avons couvert tout (et bien plus) que vous devez savoir sur SSH pour une utilisation quotidienne : nous avons appris à utiliser l'authentification par clé, à protéger le serveur par force brute contre le piratage et, en général, à corriger la plupart des failles potentielles. En fait, SSH peut faire beaucoup d'autres choses - par exemple, le tunneling et la redirection de port via une session ssh, mais il est peu probable que vous, en tant qu'utilisateur le plus ordinaire, l'utilisiez un jour. Ressources additionnelles

Le livre traite en détail des paramètres des services réseau qui vous permettent de créer un serveur avec la configuration et les fonctionnalités requises basées sur le système d'exploitation Linux. Vous pouvez configurer tout type de serveur : d'un serveur LAN à un serveur Internet en passant par un serveur d'accès distant. L'administration Linux est décrite en détail.

La présentation du matériel est basée sur les distributions Red Hat et Mandrake. De nombreuses informations uniques : lancer des jeux Windows sous Linux et créer un serveur Linux pour la salle de jeux, configurer Dr. Web et AVP pour Linux, programme de comptabilité du trafic MRTG, système de protection et de détection d'intrusion LIDS, et bien plus encore. Attention particulière axé sur la sécurité des serveurs Linux. Le système d'exploitation Linux lui-même est décrit de manière suffisamment détaillée et un ouvrage de référence de ses commandes est fourni. Après avoir lu le livre, vous deviendrez propriétaire de connaissances sur la configuration et la compilation du noyau, la création de vos propres packages RPM, l'interpréteur de commandes bash, à l'aide de matrices RAID. Vous découvrirez le monde intérieur de Linux. Le livre convient aussi bien aux administrateurs professionnels qu'aux novices, puisque la présentation du matériel commence par l'installation du système d'exploitation Linux et que le premier chapitre décrit les principales technologies et protocoles réseau (Cours pour jeunes administrateurs).

Toutes les listes données dans le livre sont vérifiées dans la pratique et placées sur le CD ci-joint. De plus, il contient de nombreux Informations d'arrière-plan(HOWTO, RFC), ainsi que des articles sur Linux. Un riche ensemble d'utilitaires auxiliaires et logiciel pour le serveur (Apache, MySQL, MRTG, etc.).

Livre:

Sections sur cette page :

Le service Telnet fournit une émulation de terminal de base pour les systèmes distants prenant en charge le protocole Telnet sur le protocole TCP/IP. L'émulation des terminaux Digital Equipment Corporation VT 100, Digital Equipment Corporation VT 52, TTY est fournie. Le protocole Telnet est décrit dans la RFC 854, que vous trouverez sur le CD joint.

Toutes les commandes exécutées avec Telnet, sont gérés par le serveur telnet, et non ordinateur local. L'utilisateur ne voit que le résultat de ces commandes.

Pour utiliser Telnet, le démon telnet doit être installé sur l'ordinateur distant. Un programme client doit être installé sur l'ordinateur de l'utilisateur. Presque tous les systèmes d'exploitation ont utilitaire telnet, qui est un client pour le protocole telnet (voir Figure 8.2).

Le service Telnet a été et reste l'un des moyens les plus populaires pour se connecter à distance et travailler sur une machine distante. Son principal inconvénient est que toutes les informations, y compris les mots de passe, sont transmises en texte clair sans aucun cryptage.

SSH (Secure Shell) est un programme qui vous permet de vous connecter à des ordinateurs distants et d'établir une connexion cryptée. Il existe également une version « sécurisée » de telnet, stelnet.

SSH utilise la cryptographie à clé publique pour chiffrer la connexion entre deux machines et également pour authentifier les utilisateurs.

Riz. 8.2.Client Telnet pour Windows

Le shell ssh peut être utilisé pour se connecter en toute sécurité à un serveur distant ou copier des données entre deux machines tout en empêchant les attaques intermédiaires (piratage de session) et l'usurpation d'identité du serveur de noms (repérage DNS).

Secure Shell prend en charge les algorithmes de chiffrement suivants :

Poisson-globe est un système de cryptage 64 bits. Cet algorithme est souvent utilisé pour le cryptage à grande vitesse de gros volumes de données.

Triple DES(Data Encryption Standard) - une norme pour le cryptage des données. Cet algorithme est assez ancien, il n’est donc pas recommandé de l’utiliser. Généralement, DES est utilisé pour chiffrer des données non secrètes.

IDÉE(International Data Encryption Algorithm) - un algorithme international pour crypter les informations. Cet algorithme fonctionne avec une clé de 128 bits et est donc plus sécurisé que BlowFish et DES.

RSA(Algorithme de Rivest-Shamir-Adelman) - Algorithme de Rivest-Shamir-Adelman. Il s'agit d'un système de cryptage avec des clés publiques et privées.

Lors du choix d'un algorithme de cryptage, vous devez partir de la confidentialité des informations que vous devez transférer. Si les informations sont secrètes, il est préférable d'utiliser les algorithmes IDEA ou RSA. Si vous ne souhaitez tout simplement pas transférer de données en clair, utilisez l'algorithme BlowFish, car il est beaucoup plus rapide que DES.

Le shell ssh est très efficace contre les renifleurs de protocole car non seulement il chiffre mais compresse également le trafic avant de le transmettre à ordinateur distant. Le programme ssh peut être téléchargé depuis http://www.cs.hut.fi/ssh/. La version UNIX de ssh est gratuite, tandis que la version Windows (c'est-à-dire le client Windows) coûte de l'argent.

Le shell ssh est indispensable dans les cas où vous devez administrer le serveur à distance ou lorsque le serveur ne dispose pas de son propre moniteur. Lorsque vous utilisez telnet, toutes les données envoyées via une connexion telnet sont disponibles en texte clair. Cela signifie que les noms d'utilisateur et les mots de passe seront disponibles pour toute personne écoutant le trafic à l'aide de l'analyseur. ssh effectue le chiffrement à l'aide de plusieurs algorithmes différents, notamment DES et 3DES.

Le programme se compose d'un démon sshd qui s'exécute sur une machine Linux/UNIX et d'un client ssh distribué pour Linux et Windows. Pour installer ssh, prenez les sources et placez-les traditionnellement dans le répertoire /usr/src/. Décompressez ensuite l'archive et installez le programme en suivant les étapes ci-dessous :

cd /usr/src/
tar xzf ssh-2.4.0.tar.gz
cd ssh-2.4.0
./configurer
faire
faire installer

Pour que ssh fonctionne, vous devez démarrer le démon sshd sur la machine à laquelle vous souhaitez vous connecter. Il est conseillé d'ajouter une commande de démarrage au script de démarrage du système pour un démarrage automatique. Le démon sshd s'exécute sur le port 22 (voir le listing 8.6). Si je ne me trompe pas, ssh ne peut pas être utilisé avec xinetd/inetd - il doit être exécuté comme un serveur httpd en mode autonome.

Inscription 8.6. Fragment du fichier /etc/services

ssh 22/tcp # Protocole de connexion à distance SSH
ssh 22/udp # Protocole de connexion à distance SSH

La configuration de sshd ne présente généralement aucun inconvénient. La configuration du démon sera discutée en détail plus loin dans ce chapitre. Essayez maintenant de vous connecter à cette machine via ssh. Pour ce faire, vous devez installer le même package sur une autre machine exécutant Linux/UNIX (ou installer un client Windows ssh) et saisir la commande :

$ ssh nom d'hôte.domaine

ssh vous demandera le mot de passe de l'utilisateur. Le nom de l'utilisateur actuel, c'est-à-dire le nom sous lequel vous êtes actuellement connecté au système, sera utilisé comme nom d'utilisateur pour établir une connexion. Si l'authentification réussit, la session de communication démarrera. La session peut être terminée en appuyant sur Ctrl+D.

Si vous devez spécifier un nom d'utilisateur différent, utilisez l'option -l du programme ssh :

ssh –l utilisateur nom d'hôte.ru

De cette façon, vous pouvez indiquer au programme ssh à quel utilisateur se connecter sur la machine distante (voir Figure 8.3).

Lors de l'utilisation du client Windows, le nom de l'ordinateur, le nom d'utilisateur et le mot de passe doivent être saisis dans la boîte de dialogue du programme. Si la connexion échoue, essayez de sélectionner la méthode de codage Blowfish. Si cela ne vous aide pas, choisissez 3DES.

Travailler en ssh est similaire à travailler en telnet. Vous pouvez administrer une machine distante aussi facilement qu’une machine locale. Les options du programme ssh sont répertoriées dans le tableau 1. 8.5.

Fig.8.Z. Inscription sur une machine distante

Options du programme ssh Tableau 8.5

Option	Description
-UN	Désactive la redirection de l'authentification de l'agent de connexion
-UN	Active la redirection de l'authentification de l'agent de connexion
-c poisson-globe|3des	Permet de sélectionner l'algorithme de cryptage lors de l'utilisation de la première version du protocole SSH. Vous pouvez spécifier Blowfish ou 3des
-avec chiffre	Spécifie une liste de chiffrements séparés par des virgules, par ordre de préférence. Uniquement pour la deuxième version du protocole SSH. Les valeurs valides sont Blowfish, Twofish, Arcfour, Cast, Des et 3des
-F	Cette option change ssh en mode arrière-plan après authentification de l'utilisateur. Il est recommandé d'utiliser X11 pour exécuter le programme. Par exemple, ssh -f hostxterm
-je	file-ident Spécifie un fichier d'identification non standard (pour l'authentification RSA/DSA non standard)
-l nom d'utilisateur	Spécifie au nom de quel utilisateur l'enregistrement sur la machine distante sera effectué
-r port	Spécifie le port auquel le programme ssh se connectera (le port 22 est utilisé par défaut)
-q	Mode silencieux. Seuls les messages concernant erreurs fatales. Tous les autres messages d’avertissement ne seront pas imprimés sur la sortie standard.
-X	Désactiver la redirection X11
-X	Activer la redirection X11
-1	Utilisez uniquement la première version du protocole SSH
-2	Utilisez uniquement la deuxième version du protocole SSH
-4
-6

Le shell ssh utilise deux fichiers de configuration ssh_conf et sshd_conf. Je pense que cela n'a aucun sens de dire qu'ils se trouvent dans le répertoire /etc/ssh. Je recommande d'ajouter la ligne suivante au fichier sshd_conf :

adresse autorisée 10.1.1.1 10.1.2.1 10.1.3.1

Cela signifie que l'accès ssh ne peut être effectué qu'à partir de machines avec les adresses 10.1.1.1, 10.1.2.1, 10.1.3.1. Cela protégera votre ordinateur des intrusions indésirables venant de l’extérieur.

Le programme stelnet est complètement similaire au programme telnet en tout, mais il crypte le trafic transmis lors d'une connexion telnet.

Le démon sshd est un programme démon pour le shell ssh. Habituellement, sshd s'exécute sur la machine à laquelle les clients ssh se connectent. Dernières versions Le démon sshd prend en charge deux versions du protocole ssh : ssh version 1 et ssh version 2.

Protocole SSH version 1

Chaque nœud possède sa propre clé RSA (généralement 1 024 bits) qui est utilisée pour identifier le nœud. Cette clé est également appelée clé publique. De plus, lorsque le démon est démarré, une autre clé RSA est générée : la clé du serveur (généralement 768 bits). Cette clé est recréée toutes les heures et n'est jamais enregistrée sur le disque.

Chaque fois qu'une connexion est établie avec un client, le démon renvoie sa clé publique et la clé du serveur en réponse. Le client compare la clé publique reçue avec sa base de données pour voir si elle a changé. Le client génère ensuite aléatoirement un nombre de 256 bits et l'encode en utilisant deux clés en même temps : la clé publique et la clé du serveur. Les deux parties utilisent ce nombre aléatoire comme clé de session, qui est utilisée pour coder toutes les données transmises au cours de la session.

Le client tente ensuite de s'authentifier à l'aide de l'authentification .rhosts, de l'authentification RSA ou de l'authentification par mot de passe.

Normalement, l'authentification .rhosts n'est pas sécurisée et est donc désactivée.

Protocole SSH version 2

La version 2 fonctionne de la même manière : chaque nœud possède une clé DSA spécifique qui est utilisée pour identifier le nœud. Cependant, lorsque le démon est démarré, la clé du serveur n'est pas générée. La sécurité de la connexion est assurée par l'accord de clé Diffie-Hellman.

Une session peut être codée à l'aide des méthodes suivantes : AES 128 bits, Blowfish, 3DES, CAST128, Arcfour, AES 192 bits ou AES 256 bits.

Les options du démon sshd sont répertoriées dans le tableau 1. 8.6.

Options du démon sshd Tableau 8.6

Option	Description
-b bits	Spécifie le nombre de bits de la clé du serveur (768 par défaut). Cette option ne peut être utilisé que si vous utilisez le protocole SSH version 1
-d	Mode débogage (DEBUG). Dans ce mode, le serveur ne passe pas en arrière-plan et enregistre ses actions en détail dans le journal système. L'utilisation de cette option est particulièrement utile pour apprendre le fonctionnement du serveur.
-e	Si cette option est spécifiée, le démon sshd envoie des messages de débogage à journal système, et sur le flux d'erreur standard
-f fichier_config	Ensembles fichier alternatif configuration. La valeur par défaut est /etc/ssh/sshd_config
-g temps	Donne à un client non authentifié plus de temps pour s’authentifier. La durée par défaut est de 600 secondes. Si pendant ce temps le client n'a pas pu s'authentifier, la connexion sera interrompue. La valeur 0 est interprétée comme une attente infinie
-h	keyfile Spécifie un autre fichier de clé publique (clé hôte). Le fichier par défaut est /etc/ssh/ssh_host_key. Cette option peut être nécessaire pour permettre à sshd de s'exécuter en tant que root autre que root. De plus, une utilisation courante de cette option consiste à démarrer sshd à partir de scripts qui spécifient différents paramètres en fonction de l'heure de la journée. Par exemple, pendant la journée (de travail), certaines options sont définies, et le soir (de travail), d'autres
-je	Utilisé si vous souhaitez exécuter sshd via le superserveur xinetd (inetd). Habituellement, le démon sshd n'est pas démarré par le superserveur xinetd (inetd), mais est démarré au démarrage du système car le démon sshd a besoin d'un certain temps (10 secondes) pour générer la clé du serveur avant de pouvoir répondre aux demandes des clients.
-k temps	Spécifie l'heure après laquelle la clé du serveur sera recréée. La durée par défaut est de 3 600 secondes (1 heure). Cette option ne peut être utilisée que si vous utilisez le protocole SSH version 1
-r port	Spécifie un autre port sur lequel le démon sshd écoutera. Le port par défaut est 22
-q Mode silencieux.	Dans ce mode, la journalisation de session ne sera pas effectuée. Habituellement, le début de l'authentification, le résultat de l'authentification et l'heure de fin de la session sont enregistrés.
-t	Mode d'essai. Ce mode utilisé pour vérifier l'exactitude du fichier de configuration
-D	Avec cette option, le démon ne passera pas en arrière-plan
-4	Vous ne pouvez utiliser que des adresses IP au format IPv4
-6	Vous ne pouvez utiliser que des adresses IP au format IPv6

Le fichier de configuration du démon /etc/ssh/sshd_config ressemble à celui du listing 8.7.

Listing 8.7 Fichier de configuration /etc/ssh/sshd_config

# $OpenBSD: sshd_config,v 1.38 2001/04/15 21:41:29 deraadt Exp $
# Ce sshd a été compilé avec PATH=/usr/bin:/bin:/usr/sbin:/sbin
# Il s'agit du fichier de configuration du système du serveur sshd. Voir sshd(8)
# pour plus d'informations.
Port 22
#Protocole 2.1
# Adresse d'écoute 0.0.0.0
# ListenAddress : 
Clé hôte /etc/ssh/ssh_host_key
Clé hôte /etc/ssh/ssh_host_rsa_key
Clé hôte /etc/ssh/ssh_host_dsa_key
ServeurKeyBits 768
ConnexionGraceTime 600
KeyRegénérationInterval 3600
PermitRootLogin oui
#
# Ne lisez pas les fichiers ~/.rhosts et ~/.shosts
IgnorerRhosts oui
# Décommentez si vous ne faites pas confiance à ~/.ssh/known_hosts pour
RhostsRSAAthentification
# IgnoreUserKnownHosts oui
Modes stricts oui
X11Transfert oui
X11DisplayOffset10
PrintMotd oui
# PrintLastLog non
Rester en vie oui
# Journalisation
SyslogFacility AUTHPRIV
Informations sur le niveau de journalisation
# rend obsolète QuietMode et FascistLogging
RhostsAuthentification non
#
# Pour que cela fonctionne, vous aurez également besoin des clés d'hôte dans /etc/ssh/
ssh_known_hosts
RhostsRSAAthentification non
# similaire à la version 2 du protocole
Authentification basée sur l'hôte non
#
RSAAthentification oui
# Pour désactiver les mots de passe en texte clair tunnelisés, remplacez par non ici !
Authentification par mot de passe oui
PermitEmptyPasswords non
# Décommentez pour désactiver les mots de passe s/key
# ChallengeResponseAuthentication non
# Décommentez pour activer l'authentification interactive au clavier PAM
# Attention : activer cette option peut contourner le paramètre "PasswordAuthentication"
# PAMAuthenticationViaKbdInt oui
# Pour modifier les options Kerberos
# KerberosAuthentification non
# KerberosOrLocalPasswd oui
# AFSTokenPassing non
# KerberosTicketCleanup non
# Kerberos TGT Passing ne fonctionne qu'avec le kaserver AFS
# KerberosTgtPassing oui
# CheckMail oui
# UtiliserConnexion non
# MaxStartups 10:30:60
# Bannière /etc/issue.net
# ReverseMappingCheck oui
Sous-système sftp/usr/libexec/openssh/sftp-server

MINISTÈRE DES TRANSPORTS ET DES COMMUNICATIONS DE L'UKRAINE

ACADÉMIE NATIONALE DES COMMUNICATIONS D'ODESSA eux. A.S. POPOVA

Département des réseaux de communication

Essai

sur le thème de : "Protocoles SSH, CMIP, Telnet"

Odessa 2013

• • Normes et implémentations logicielles
  • Serveurs SSH
  • Clients et shells SSH
  • Conseils de sécurité SSH
  • Exemples d'utilisation de SSH
  • Tunnelisation SSH
  • Informations techniques sur le protocole

Principales caractéristiques du protocole CMIP

Protocole CMIP et services CMIS

Filtration

Synchronisation

• Appareil
• Possibilités
• Imprimante et clavier NVT
• Structure de commande Telnet
• Applications
• Sécurité
• Telnet et autres protocoles

Normes et implémentations logicielles

SSH (Eng. Secure SHell - "secure shell") - un protocole réseau au niveau de l'application qui vous permet de produire télécommande système opérateur et le tunneling des connexions TCP (par exemple pour les transferts de fichiers). Fonctionnalité similaire aux protocoles Telnet et rlogin, mais contrairement à eux, il crypte tout le trafic, y compris les mots de passe transmis. SSH permet un choix de différents algorithmes de chiffrement. Les clients SSH et les serveurs SSH sont disponibles pour la plupart des systèmes d'exploitation réseau.

SSH vous permet de transférer en toute sécurité presque n'importe quel autre protocole réseau dans un environnement non sécurisé. Ainsi, vous pouvez non seulement travailler à distance sur un ordinateur via un shell de commande, mais également transmettre un flux audio ou vidéo sur un canal crypté (par exemple, depuis une webcam). SSH peut également utiliser la compression des données transmises pour un chiffrement ultérieur, ce qui est pratique, par exemple, pour le lancement à distance des clients X WindowSystem.

La plupart des fournisseurs d'hébergement offrent aux clients un accès SSH à leur répertoire personnel moyennant des frais. Cela peut être pratique aussi bien pour travailler en ligne de commande que pour lancer des programmes à distance (y compris des applications graphiques).

La première version du protocole, SSH-1, a été développée en 1995 par le chercheur Tatu Ulyonen de l'Université de technologie d'Helsinki (Finlande). SSH-1 a été écrit pour être plus privé que les protocoles rlogin, telnet et rsh. En 1996, une version plus sécurisée du protocole, SSH-2, a été développée et incompatible avec SSH-1. Le protocole a gagné encore plus en popularité et, en 2000, il comptait environ deux millions d'utilisateurs. Actuellement, le terme « SSH » fait généralement référence à SSH-2, car. la première version du protocole, en raison de lacunes importantes, n'est désormais pratiquement plus utilisée.

En 2006, le protocole a été approuvé groupe de travail IETF comme norme Internet.

Cependant, dans certains pays (France, Russie, Irak et Pakistan), une autorisation spéciale est toujours requise de la part des autorités compétentes pour utiliser certaines méthodes de cryptage, dont SSH.

Deux implémentations de SSH sont courantes : une implémentation commerciale privée et une implémentation gratuite. L'implémentation gratuite s'appelle OpenSSH. En 2006, 80 % des ordinateurs sur Internet utilisaient OpenSSH. La mise en œuvre privée est développée par SSH Communications Security, une filiale en propriété exclusive de Tectia Corporation, et est gratuite pour une utilisation non commerciale. Ces implémentations contiennent presque le même ensemble de commandes.

Le protocole SSH-2, contrairement au protocole telnet, résiste aux attaques par détection de trafic, mais ne résiste pas aux attaques de l'homme du milieu. Le protocole SSH-2 résiste également aux attaques par join in the middle (en anglais sessionhijacking), puisqu'il est impossible de rejoindre une session déjà établie ou de l'intercepter.

Pour éviter les attaques de type man-in-the-middle, lors de la connexion à un hôte dont la clé n'est pas encore connue du client, le logiciel client montre à l'utilisateur une « key empreinte digitale » (anglais keyfingerprint). Il est recommandé de vérifier soigneusement le « moule de clé » affiché par le logiciel client avec l'instantané de clé du serveur, obtenu de préférence via des canaux de communication fiables ou personnellement.

La prise en charge de SSH est implémentée dans tous les systèmes de type UNIX, et la plupart d'entre eux disposent d'un client et d'un serveur ssh comme utilitaires standard. Il existe également de nombreuses implémentations de clients SSH pour les systèmes d'exploitation non UNIX. Le protocole a acquis une grande popularité après le développement généralisé d'analyseurs de trafic et de méthodes permettant de perturber le fonctionnement des réseaux locaux, comme alternative au protocole Telnet non sécurisé pour la gestion des nœuds importants.

SSH nécessite un serveur SSH et un client SSH. Le serveur écoute les connexions des machines clientes et, lorsqu'une connexion est établie, effectue une authentification, après quoi il commence à servir le client. Le client est utilisé pour se connecter à une machine distante et exécuter des commandes.

Pour se connecter, le serveur et le client doivent créer des paires de clés – publiques et privées – et échanger des clés publiques. Habituellement, un mot de passe est également utilisé.

Serveurs SSH

*BSD : OpenSSH

Linux : dropbear, serveur lsh, serveur openssh, ssh

Windows : freeSSHd, copssh, WinSSHD, serveur KpyM Telnet/SSH, MobaSSH, OpenSSH via Cygwin

Clients et shells SSH

GNU/Linux, *BSD : kdessh, lsh-client, openssh-client, putty, ssh, Vinagre

· MS Windows et Windows NT : PuTTY, SecureCRT, ShellGuard, Axessh, ZOC, SSHWindows, ProSSHD, XShell

MS Windows Mobile: PocketPuTTy, mToken, sshCE, PocketTTY, OpenSSH, PocketConsole

Mac OS : NiftyTelnet SSH

SymbianOS : PuTTY

Java : MindTerm, AppGateSecurityServer

J2ME : MidpSSH

iPhone : i-SSH, ssh (inclut le terminal)

Android : ConnectBot

Mûre : BBSSH

MAEMO 5 : OpenSSH

Conseils de sécurité SSH

3. Sélection d'un port non standard pour le serveur SSH.

4. Utilisation de clés SSp RSA longues (2048 bits ou plus). Les systèmes de chiffrement basés sur RSA sont considérés comme sécurisés si la longueur de la clé est d'au moins 1 024 bits.

5. Limiter la liste des adresses IP à partir desquelles l'accès est autorisé (par exemple, en configurant le pare-feu).

7. Refus d'utiliser des connexions système courantes ou bien connues pour l'accès SSH.

8. Consultez régulièrement les messages d'erreur d'authentification.

9. Installation de systèmes de détection d'intrusion.

10. Utiliser des pièges qui simulent un service SSH (pots de miel).

Exemples d'utilisation de SSH

La commande de connexion à un serveur SSH local depuis la ligne de commande GNU/Linux ou FreeBSD pour l'utilisateur pacify (le serveur écoute sur le port non standard 30000) : $ ssh -p 30000 [email protégé]

La génération de paires de clés (sur les systèmes d'exploitation de type UNIX) se fait avec la commande $ ssh-keygen

Génération d'une paire de clés RSA SSH-2 d'une longueur de 4096 bits à l'aide de puttygen sous un système d'exploitation de type UNIX :

$ puttygen -t rsa -b 4096 -o échantillon

Certains clients, comme PuTTY, ont Interface graphique utilisateur.

Pour utiliser SSH en Python, il existe des modules tels que python-paramiko et python-twisted-conch.

Tunnelisation SSH

Un tunnel SSH est un tunnel créé via une connexion SSH et utilisé pour chiffrer les données tunnelisées. Utilisé pour sécuriser la transmission de données sur Internet. Lorsqu'il est transmis via un tunnel SSH, le trafic non chiffré de n'importe quel protocole est chiffré à une extrémité de la connexion SSH et déchiffré à l'autre. La mise en œuvre pratique peut se faire de plusieurs manières :

Création d'un proxy Chaussettes pour les applications qui ne savent pas fonctionner via un tunnel SSH, mais peuvent fonctionner via un proxy Chaussettes

· Utiliser des applications pouvant fonctionner via un tunnel SSH.

· Création d'un tunnel VPN, adapté à presque toutes les applications.

· Si l'application fonctionne avec un serveur spécifique, vous pouvez configurer le client SSH pour qu'il passe par le tunnel SSH les connexions TCP qui arrivent à un port TCP spécifique de la machine sur laquelle le client SSH est exécuté. Par exemple, les clients Jabber se connectent par défaut sur le port 443. Ensuite, pour établir une connexion au serveur Jabber via un tunnel SSH, le client SSH est configuré pour transférer les connexions depuis n'importe quel port de la machine locale vers serveur distant: $ ssh -L 4430:jabber.example.com:443 somehost. Dans ce cas, le client Jabber est configuré pour se connecter au port 4430 du serveur localhost (si le client ssh s'exécute sur la même machine que le client Jabber). Pour créer un tunnel ssh, vous avez besoin d'une machine avec un serveur ssh en cours d'exécution et un accès à jabber.example.com. Cette configuration peut être utilisée si l'accès à jabber.example.com depuis la machine locale est bloqué par un pare-feu, mais qu'il existe un accès à un serveur ssh qui n'a aucune restriction d'accès à Internet.

Informations techniques sur le protocole

SSH est un protocole de couche application. Le serveur SSH écoute généralement les connexions sur le port TCP 22. La spécification du protocole SSH-2 est contenue dans la RFC 4251. SSH utilise un protocole d'authentification de partie basé sur des algorithmes de signature numérique RSA ou DSA pour authentifier le serveur. La signature numérique RSA ou DSA peut également être utilisée pour l'authentification du client, mais l'authentification par mot de passe (mode de compatibilité ascendante avec Telnet) et même l'adresse IP de l'hôte (mode de compatibilité ascendante avec rlogin) sont également autorisées. L'authentification par mot de passe est la plus courante ; il est sécurisé car le mot de passe est transmis sur un canal virtuel crypté. L'authentification par adresse IP n'est pas sécurisée, cette fonctionnalité est le plus souvent désactivée. L'algorithme Diffie-Hellman (DH) est utilisé pour créer un secret partagé (clé de session). Pour crypter les données transmises, un cryptage symétrique, des algorithmes AES, Blowfish ou 3DES sont utilisés. L'intégrité des données est vérifiée à l'aide de CRC32 dans SSp ou de HMAC-SHA1/HMAC-MD5 dans SSp. Pour compresser les données cryptées, l'algorithme LempelZiv (LZ77) peut être utilisé, qui fournit le même niveau de compression que Archiveur ZIP. La compression SSH n'est activée qu'à la demande du client et est rarement utilisée en pratique.

Principales caractéristiques du protocole CMIP

CMIP implémente l'ensemble des services CMIS. Avec ces services, CMIP prend en charge le service d'opérations à distance suivant :

Demander (invoquer);

Renvoie le résultat ;

Renvoie une erreur ;

Rejet de la demande par l'utilisateur du service ;

Rejet de la demande par le prestataire.

Les informations de contrôle du gestionnaire à l'agent transmises via le protocole CMIP sont codées conformément aux règles ASN.1 et BER.

Pour chaque opération, le format du bloc de données transféré sur le réseau du gestionnaire vers l'agent, et vice versa, est défini.

Le format des PDU CMIP est décrit par la notation ASN.1 et possède une structure beaucoup plus complexe que les blocs SNMP. Par exemple, le bloc de données d'une opération M-GET comporte des champs pour spécifier les noms des attributs dont les valeurs sont demandées par le gestionnaire, ainsi que des champs pour spécifier les paramètres de navigation et de filtrage. Il existe également des champs permettant de spécifier les paramètres des droits d'accès à un objet.

L'utilisation du protocole CMIP détermine un niveau initial de complexité assez élevé du système de contrôle, car pour son fonctionnement, il est nécessaire de mettre en œuvre un certain nombre de services auxiliaires, d'objets et de bases de données d'objets.

Les notifications de l'agent CMIP sont toujours transmises à l'aide d'un protocole de transport fiable et seront retransmises en cas de perte.

Le protocole CMIP est conçu pour les agents capables d'effectuer une séquence complexe d'actions sur une simple commande du gestionnaire.

Le protocole CMIP est bien mieux évolutif, car il peut affecter plusieurs objets à la fois, et les réponses des agents passent par des filtres qui limitent la transmission des informations de contrôle à certains agents et gestionnaires uniquement. Le protocole CMIP, qui est un protocole d'interaction entre agents et gestionnaires du système de gestion OSI, permet d'agir immédiatement sur un groupe d'agents avec une seule commande, en utilisant des options telles que la navigation et le filtrage.

Les MIB pour le protocole CMIP n'ont pas de norme unique et sont développées par chaque fabricant d'équipements de télécommunications uniquement pour leurs propres besoins. propre équipement. La seule exception est la norme MIB pour les systèmes de transmission G.722, G.774.

Protocole CMIP et services CMIS

L'accès aux informations de gestion stockées dans les objets gérés est fourni via un élément du système de gestion appelé CMSIE (Common Management Information Service Element). Le service CMSIE repose sur une architecture d'application distribuée, dans laquelle certaines fonctions sont exécutées par le gestionnaire et d'autres par l'agent. L'interaction entre le manager et l'agent s'effectue à l'aide du protocole CMIP. Les services fournis par le service CMSIE sont appelés CMIS (Common Management Information Services).

Le protocole CMIP et les services CMIS sont définis dans les normes X.710 et X.711 ITU-T. Les services CMIS sont divisés en deux groupes : les services lancés par le gestionnaire (demandes) et les services lancés par l'agent (notifications).

Les services initiés par le gestionnaire comprennent les activités suivantes :

· M-CREATE demande à l'agent de créer une nouvelle instance d'un objet d'une certaine classe ou un nouvel attribut dans une instance d'un objet ;

· M-DELETE demande à l'agent de supprimer une instance d'un objet d'une classe ou d'un attribut particulier dans une instance d'un objet ;

· M-GET demande à l'agent de renvoyer la valeur d'un attribut d'une instance d'objet particulière ;

· M-SET demande à l'agent de modifier la valeur de certains attributs d'une certaine instance d'objet ;

· M-ACTION demande à l'agent d'effectuer une action spécifique sur une ou plusieurs instances d'objet.

L'agent lance une seule opération :

M-EVENT_REPORT - envoyer une notification au responsable.

Pour implémenter ses services, le service CMISE doit utiliser les services de couche application de la pile OSI - ACSE, ROSE.

La différence entre les services CMIS et les services SNMP similaires réside dans une plus grande flexibilité. Alors que les requêtes SNMP GET et SET s'appliquent à un seul attribut d'un objet, les requêtes M-GET, M-SET, M-ACTION et M-DELETE peuvent s'appliquer à plusieurs objets. Pour ce faire, les normes CMIP/CMIS introduisent des concepts tels que le cadrage, le filtrage et la synchronisation.

Revoir

Une requête CMISE peut utiliser un parcours pour interroger plusieurs objets en même temps. Quatre niveaux de contrôle sont introduits :

· l'objet de base, défini par son nom distinctif FDN ;

objets situés sur nième niveau subordination par rapport à l'inclusion de base dans l'arbre ;

l'objet de base et tous les objets situés à ses niveaux subordonnés jusqu'au n-ième (inclus) dans l'arbre d'inclusion ;

sous-arbre - l'objet de base et tous ses subordonnés dans l'arbre d'inclusion.

Filtration

Le filtrage consiste à appliquer une expression booléenne à la requête du manager. La requête est appliquée uniquement aux objets et à leurs attributs pour lesquels l'expression booléenne donnée est vraie. Les expressions booléennes peuvent inclure des opérateurs relationnels =>,<=,<,>ou certains attributs. Il est possible de créer des filtres complexes basés sur la combinaison de plusieurs filtres en un seul filtre composite.

Synchronisation

Lors de l'interrogation de plusieurs objets, l'un des deux schémas de synchronisation est utilisé : atomique ou lorsque cela est possible. Avec un schéma atomique, une requête est exécutée uniquement si tous les objets compris dans la portée de l'exploration ou du filtre peuvent terminer la requête avec succès. La synchronisation « lorsque cela est possible » signifie la transmission de la demande à tous les objets auxquels la demande s'applique. L'opération est terminée lorsque la requête est exécutée par un nombre quelconque d'objets.

Le protocole CMIP est un ensemble d'opérations qui correspondent directement aux services CMIS. Ainsi, le protocole CMIP définit les opérations M-GET, M-SET, M-CREATE, etc. Pour chaque opération, le format du bloc de données transféré sur le réseau du gestionnaire vers l'agent, et vice versa, est défini. Le format des PDU CMIP est décrit par la notation ASN.1 et possède une structure beaucoup plus complexe que les blocs SNMP. Par exemple, le bloc de données d'une opération M-GET comporte des champs pour spécifier les noms des attributs demandés par le gestionnaire, ainsi que des champs pour spécifier les options de navigation et de filtrage qui définissent l'ensemble des instances d'objet qui seront affectées par cette requête. . Il existe également des champs permettant de spécifier les paramètres des droits d'accès à un objet.

Comparaison des protocoles SNMP et CMIP

L'utilisation du protocole SNMP permet de construire des systèmes de gestion à la fois simples et complexes, et l'utilisation du protocole CMIP détermine un certain niveau de complexité initial assez élevé du système de gestion, puisque pour son fonctionnement il est nécessaire de mettre en œuvre un certain nombre de services auxiliaires, d'objets et de bases de données d'objets.

· Les agents CMIP exécutent généralement des fonctions plus complexes que les agents SNMP. De ce fait, les opérations qu'un gestionnaire peut effectuer sur un agent SNMP sont de nature atomique, ce qui entraîne de multiples échanges entre le gestionnaire et l'agent.

· Les pièges de l'agent SNMP sont envoyés au gestionnaire sans attendre d'accusé de réception, ce qui peut faire passer inaperçus d'importants problèmes de réseau car les pièges correspondants sont perdus, tandis que les pièges de l'agent CMIP sont toujours transmis en utilisant un protocole de transport fiable et en cas de pertes, ils seront retransmis.

· Certains problèmes SNMP peuvent être résolus en utilisant des MIB plus intelligentes (qui incluent la MIB RMON), mais pour de nombreux appareils et situations, il n'existe pas de telles MIB (ou il n'y a pas de norme, ou il n'y a pas de MIB correspondante dans l'équipement géré).

· Le protocole CMIP est conçu pour les agents intelligents capables d'effectuer une séquence complexe d'actions sur une simple commande du gestionnaire.

· Le protocole CMIP est bien plus évolutif, car il peut affecter plusieurs objets à la fois, et les réponses des agents passent à travers des filtres qui limitent la transmission des informations de contrôle à certains agents et gestionnaires.

texte opérationnel du protocole réseau

TELNET(Eng. TERminaLNETwork) est un protocole réseau permettant d'implémenter une interface texte sur un réseau (sous sa forme moderne, utilisant le transport TCP). Le nom « telnet » est également utilisé par certains utilitaires qui implémentent le côté client du protocole. La norme de protocole actuelle est décrite dans la RFC 854.

Exécute les fonctions du protocole de couche application du modèle OSI.

Le but du protocole TELNET est de fournir un moyen de communication assez général, bidirectionnel, à huit bits et orienté octet. Son objectif principal est de permettre aux terminaux et aux processus terminaux de communiquer entre eux. Il est envisagé que ce protocole puisse être utilisé pour une communication de terminal à terminal (« liaison ») ou une communication de processus à processus (« informatique distribuée »).

Appareil

Bien qu'une session Telnet ait un côté client et un côté serveur distincts, le protocole est en réalité complètement symétrique. Après avoir établi une connexion de transport (généralement TCP), ses deux extrémités jouent le rôle de « terminaux virtuels réseau » (en anglais Network Virtual Terminal, NVT), échangeant deux types de données :

· Données d'application (c'est-à-dire les données qui vont de l'utilisateur à l'application de texte côté serveur et vice versa) ;

· Commandes du protocole Telnet, dont un cas particulier sont les options qui servent à clarifier les capacités et les préférences des parties.

Bien qu'une session Telnet sur TCP soit intrinsèquement duplex intégral, le NVT doit être traité comme un périphérique semi-duplex, fonctionnant par défaut en mode ligne tampon.

Les données de l'application transitent par le protocole sans modification, c'est-à-dire qu'à la sortie du deuxième terminal virtuel, nous voyons exactement ce qui a été saisi à l'entrée du premier. Du point de vue du protocole, les données sont simplement une séquence d'octets (octets), appartenant par défaut au jeu ASCII, mais avec l'option Binaire activée, elles peuvent être n'importe lesquelles. Bien que des extensions aient été proposées pour identifier le jeu de caractères, elles ne sont pas utilisées en pratique. Toutes les valeurs d'octet de données d'application, à l'exception de \377 (décimal 255), sont transmises telles quelles via le transport. L'octet \377 est transmis sous la forme d'une séquence \377\377 de deux octets. En effet, l'octet \377 est utilisé par la couche transport pour coder les options.

Possibilités

Le protocole fournit par défaut la fonctionnalité minimale et un ensemble d'options qui l'étendent. Le principe des options stipulées impose que les négociations soient menées lorsque chacune des options est incluse. Une partie initie la demande et l’autre peut accepter ou rejeter l’offre. Si la demande est acceptée, l'option prend effet immédiatement. Les options sont décrites séparément du protocole lui-même et leur prise en charge par le logiciel est arbitraire. Le client de protocole (terminal réseau) est invité à rejeter les demandes visant à inclure des options non prises en charge et inconnues.

Imprimante et clavier NVT

L'imprimante NVT a une largeur de chariot et une longueur de page non spécifiées et doit représenter les 95 caractères US-ASCII imprimables (codes 32 à 126). Les caractères de contrôle ont les significations suivantes :

Nom		Description
		Pas d'opération
		Fait avancer l'imprimante jusqu'à la ligne d'impression suivante tout en restant dans la même position horizontale.
Retour chariot (CR) *		Déplace l'imprimante vers la bordure gauche de la ligne actuelle.
		Produit un signal audio ou vidéo (mais ne déplace PAS la tête d'impression).
		Déplace la tête d’impression d’un caractère vers la marge gauche.
Onglet horizontal (HT)		Déplace l’imprimante jusqu’au taquet de tabulation horizontal suivant. Il n'est pas précisé comment le côté définit et règle ces taquets de tabulation.
Onglet vertical (VT)		Déplace l’imprimante jusqu’au taquet de tabulation vertical suivant. Il n'est pas précisé comment le côté définit et règle ces taquets de tabulation.
		Déplace l'imprimante en haut de la page suivante tout en restant dans la même position horizontale.

La prise en charge de l'action des caractères marqués d'un * est requise. D’autres peuvent accomplir une action donnée ou n’en accomplir aucune ; une partie n'est pas tenue d'assumer quoi que ce soit de spécifique concernant la prise en charge par l'autre partie de caractères de contrôle facultatifs particuliers.

La séquence « CR LF » doit être traitée comme un seul caractère de nouvelle ligne et utilisée chaque fois que leur action combinée est requise ; la séquence "CR NUL" doit être utilisée lorsque seul un retour chariot est requis ; et l'utilisation du caractère CR doit être évitée dans d'autres contextes.

Structure de commande Telnet

Chaque commande TELNET est une séquence multi-octets commençant par le code \377 (décimal : 255) « InterpretasCommand » (IAC) et le code de commande. Les commandes responsables de la négociation des options sont des séquences de trois octets, où le troisième octet est le code de l'option. Les codes et séquences de codes suivants n'ont leur signification respective que lorsqu'ils suivent immédiatement l'IAC.

Nom	Code (décimal/hexadécimal)	Description
		Termine la négociation démarrée par la commande SB
		Pas d'opération.
		Échange de données de synchronisation (Synch). Cette commande est toujours suivie d'une notification TCP Urgent.
		Le bouton "Pause" ou "Attention" est enfoncé.
Processus d'interruption		Suspend, interrompt, abandonne ou termine un processus.
		Supprime la sortie du processus en cours. Envoie également un signal de synchronisation à l'utilisateur.
		Renvoie une réponse de terminal composée de caractères imprimables.
		Le destinataire doit supprimer le caractère précédent, si possible.
		Effacez la dernière ligne saisie, c'est-à-dire toutes les données reçues après la dernière nouvelle ligne.
		Transfert de données en attente.
		Début de la négociation d’option nécessitant le passage de paramètres.
		Indique un désir d'exécution ou confirme que l'option spécifiée est en cours d'exécution.
PAS d'option		Indique un échec de démarrage ou de poursuite de l'exécution de l'option spécifiée.
		Une demande que l'autre partie exécute ou confirme l'exercice de l'option spécifiée.
À NE PAS FAIRE		Demande à l'autre partie d'arrêter l'exécution ou de confirmer que l'option spécifiée n'est plus exécutée.
		Octet de données 255.

Applications

Historiquement, Telnet servait à accéder à distance à l'interface de ligne de commande des systèmes d'exploitation. Par la suite, il a commencé à être utilisé pour d'autres interfaces textuelles, jusqu'aux jeux MUD et à l'art ASCII animé. Théoriquement, même les deux côtés du protocole peuvent être non seulement des personnes, mais aussi des programmes.

Parfois, les clients telnet sont utilisés pour accéder à d'autres protocoles basés sur le transport TCP, voir #Telnet et autres protocoles.

Le protocole telnet est utilisé dans la connexion de contrôle FTP, c'est-à-dire que l'accès au serveur avec la commande ftp telnet ftp.example.net pour effectuer le débogage et les expériences est non seulement possible, mais également correct (contrairement à l'utilisation de clients telnet pour accéder à HTTP, IRC et la plupart des autres protocoles).

Sécurité

Le protocole ne prévoit l'utilisation ni du cryptage ni de l'authentification des données. Il est donc vulnérable à tout type d’attaque à laquelle son transport, c’est-à-dire le protocole TCP, est vulnérable. Pour la fonctionnalité d'accès à distance au système, on utilise actuellement le protocole réseau SSH (notamment sa version 2), lors de la création duquel l'accent a été mis sur les questions de sécurité. Gardez donc à l'esprit qu'une session Telnet n'est pas du tout sécurisée, sauf si elle se trouve sur un réseau entièrement contrôlé ou avec une sécurité de couche réseau (diverses implémentations de VPN). En raison du manque de fiabilité de Telnet comme moyen de gestion des systèmes d'exploitation, ils ont été abandonnés depuis longtemps.

Telnet et autres protocoles

Il est largement admis dans la communauté technologique Internet que le client Telnet est adapté à l'accès manuel (par exemple, à des fins de débogage) aux protocoles de couche application tels que HTTP, IRC, SMTP, POP3 et à d'autres protocoles textuels basés sur TCP. transport. Cependant, l'utilisation d'un client telnet comme client TCP entraîne les effets indésirables suivants :

· Le client peut envoyer des données que vous n'avez pas saisies (options Telnet) ;

· Le client n'acceptera pas l'octet \377 ;

· Le client modifiera l'octet \377 lors de la transmission ;

Le client peut refuser de transmettre des octets avec le bit de poids fort 1.

Des programmes comme netcat fournissent un accès TCP pur, mais des astuces spéciales (telles que stty -icrnl sur un système UNIX) sont nécessaires pour transmettre un saut de ligne en tant que CR LF (ce qui est requis par de nombreux protocoles). En règle générale, un client Telnet enverra par défaut toute nouvelle ligne au format CR LF, quel que soit son encodage sur le système du client. Également pour le débogage, l'accès aux protocoles d'application (sauf FTP et, en fait, Telnet), consiste à utiliser le client PuTTY en mode "Raw" (accès TCP pur) - PuTTY convertit les nouvelles lignes séparément de la prise en charge du protocole Telnet.

Documents similaires

La couche physique du protocole CAN. Taux de transfert et longueur du réseau. La couche liaison du protocole CAN. Bits récessifs et dominants. Schéma fonctionnel du réseau standard CAN. Méthodes de détection d'erreurs. Les principales caractéristiques du réseau. Protocoles de haut niveau.

résumé, ajouté le 17/05/2013


Courrier électronique (E-Mail) et ses principaux composants : ressource d'information, serveur de messagerie, client et protocoles pour leur interaction. Caractéristiques comparatives des protocoles SMTP, POP3 et IMAP4. Téléconférences, archives de fichiers FTP, Telnet, World Wide Web.

test, ajouté le 19/01/2011


Concepts généraux, tâches et caractéristiques d'un réseau informatique RGT : technologie de contrôle, composition et finalité des principaux éléments, fonctionnalité, architecture. Implémentation du contrôle dans le modèle OSI. Caractéristiques comparatives des protocoles SNMP et CMIP.

dissertation, ajouté le 18/03/2011


Description des fonctions générales de la couche réseau du modèle OSI : journalisation, routage et adressage logique. Étudier les principes du protocole réseau TCP/IP et des utilitaires réseau en ligne de commande. Adresse du réseau local et définition de la classe Internet.

présentation, ajouté le 12/05/2013


Un protocole est un ensemble d'accords et de règles qui déterminent la manière dont les informations sont échangées dans un réseau informatique. Brève description et caractéristiques de certains protocoles utilisés sur Internet : TCP/IP, POP3, IMAP4, SMTP, FTP, HTTP, WAIS, TELNET, WAP.

présentation, ajouté le 27/04/2011


Analyse et comparaison de différentes méthodes de mise en œuvre d'un système de protection des connexions réseau. Types d'attaques de réseau et méthodes de leur impact négatif, conséquences possibles et mesures pour les prévenir. La structure du protocole de création de connexions réseau sécurisées ISAKMP.

thèse, ajoutée le 19/06/2010


Caractéristiques générales du protocole ICMP, son objectif et son format de message. Analyse de l'applicabilité du protocole ICMP lors du passage de la suite de protocoles IP v4 à la suite de protocoles IP v6. Propriétés et principe de fonctionnement, portée des protocoles d'échange d'informations de routage.

dissertation, ajouté le 24/08/2009


Travaux sur la création du réseau ARPANET, protocoles d'interaction réseau TCP/IP. Fonctionnalité du logiciel pour TCP/IP. Une brève description des protocoles de la famille TCP/IP avec une explication des abréviations. Architecture, couches réseau et protocoles TCP/IP.

résumé, ajouté le 03/05/2010


La fonction du protocole et la structure du package du protocole développé. La longueur des champs d'en-tête. Calcul de la longueur du buffer à la réception, en fonction de la longueur du paquet et du délai admissible. Algorithmes de traitement des données pour la réception et la transmission. Implémentation logicielle du protocole.

dissertation, ajouté le 18/05/2014


Services Internet : e-mail, transfert de fichiers. Recevez des services réseau via un ordinateur distant. Protocoles Internet : HTTP, FTP, Telnet, WAIS, Gopher, SMTP, IRC. Objectifs de l'introduction de la visioconférence. Organisation et tenue de téléconférences.

Il existe plusieurs façons d'accéder à l'environnement CLI. Les méthodes les plus courantes :

• Telnet ou SSH

Console

La CLI est accessible via une session de console, également appelée chaîne CTY. La console utilise une connexion série à faible vitesse, qui s'effectue via une connexion directe depuis un ordinateur ou un terminal vers le port de console d'un routeur ou d'un commutateur.

Le port console est un port de gestion qui fournit un accès hors bande au routeur. Le port console est disponible même si aucun service réseau n'a été configuré sur l'appareil. Le port console est souvent utilisé pour accéder à l'appareil lorsque les services réseau n'ont pas été démarrés ou ont cessé de fonctionner.

Exemples d'utilisation de la console :

Configuration initiale du périphérique réseau

Procédures de reprise après sinistre et dépannage lorsque l'accès à distance n'est pas possible

Procédures de récupération de mot de passe

Lors de la première utilisation du routeur, les paramètres réseau ne sont pas encore configurés. Le routeur ne peut donc pas communiquer via le réseau. Pour le préparer au démarrage et à la configuration initiales, exécutez un logiciel d'émulation de terminal sur l'ordinateur pour vous connecter au port console de l'appareil. Les commandes de configuration pour configurer le routeur peuvent être saisies via l'ordinateur connecté.

Pendant le fonctionnement, si le routeur n'est pas accessible à distance, la connexion à la console via un ordinateur peut déterminer l'état de l'appareil. Par défaut, la console affiche des informations sur le démarrage du périphérique, le débogage et les messages d'erreur.

Pour de nombreux appareils IOS, l'accès à la console ne nécessite aucune forme de sécurité par défaut. Cependant, la console doit être configurée avec des mots de passe pour empêcher tout accès non autorisé à l'appareil. En cas de perte du mot de passe, il existe un ensemble spécial de procédures permettant de contourner le mot de passe et d'accéder à l'appareil. L'appareil doit être situé dans une pièce ou un rack d'équipement verrouillé pour empêcher tout accès physique.

Telnet et SSH

Telnet est une méthode permettant d'accéder à distance à la session CLI d'un routeur. Contrairement à une connexion console, les sessions Telnet nécessitent des services réseau actifs sur l'appareil. Un périphérique réseau doit avoir au moins une interface active configurée avec une adresse de couche 3, telle qu'une adresse IPv4. Les appareils Cisco IOS incluent un processus de serveur Telnet qui démarre au démarrage de l'appareil. IOS contient également un client Telnet.

Un hôte doté d'un client Telnet peut accéder aux sessions vty exécutées sur un périphérique Cisco. Pour des raisons de sécurité, IOS exige que la session Telnet utilise un mot de passe comme méthode d'authentification minimale. Les méthodes de configuration des comptes et des mots de passe seront abordées dans les articles suivants de cette section.

Le protocole Secure Shell (SSH) est une méthode plus sécurisée pour accéder à un appareil à distance. Ce protocole fournit une connexion à distance similaire à Telnet, sauf qu'il utilise des services réseau plus sécurisés.

SSH fournit une authentification par mot de passe plus forte que Telnet et utilise le cryptage pour transporter les données de session. La session SSH crypte toutes les communications entre le client et le périphérique IOS. Cela protège l’ID utilisateur, le mot de passe et les détails de la session de contrôle. Il est recommandé d'utiliser toujours SSH au lieu de Telnet dans la mesure du possible.

La plupart des versions récentes d'IOS contiennent un serveur SSH. Certains appareils ont ce service activé par défaut. D'autres appareils nécessitent que le serveur SSH soit activé.

Les appareils IOS incluent également un client SSH qui peut être utilisé pour établir des sessions SSH avec d'autres appareils. De même, vous pouvez utiliser une machine distante avec un client SSH pour démarrer une session CLI sécurisée. Le logiciel client SSH n'est pas fourni par défaut sur tous les systèmes d'exploitation informatiques. Vous devrez peut-être obtenir, installer et configurer le logiciel client SSH pour votre ordinateur.

AUX

Une autre façon d'établir une session CLI à distance consiste à utiliser une connexion commutée à l'aide d'un modem connecté au port AUX du routeur. Comme une connexion console, cette méthode ne nécessite aucun service réseau configuré ou disponible sur l’appareil.

Le port AUX peut également être utilisé localement comme port de console lorsqu'il est connecté directement à un ordinateur exécutant un programme d'émulation de terminal. Le port console est requis pour la configuration du routeur, mais tous les routeurs ne disposent pas d'un port auxiliaire. Le port de console est également préféré au port auxiliaire pour les diagnostics car il affiche par défaut les détails de démarrage du routeur, les informations de débogage et les messages d'erreur.

Habituellement, le seul moment où le port AUX est utilisé localement au lieu du port de console est lorsqu'il y a un problème lors de l'utilisation du port de console, par exemple si certains paramètres de la console sont inconnus.