De nombreux sites exigent désormais que vous cessiez de vous connecter au système via Telnet et que vous utilisiez SSH à la place. Cette mesure vise à renforcer la sécurité. Lorsque vous vous connectez via Telnet, votre mot de passe, ainsi que toutes les autres données, sont transmis en clair. Toute personne disposant d'un analyseur de réseau peut lire ce que vous avez envoyé. SSH, en revanche, crypte toutes les données, les rendant illisibles. On part souvent du principe que les démons Telnet et SSH offrent une expérience utilisateur interchangeable ; c'est faux.
Tout d'abord, il existe de nombreux clients SSH et Telnet différents. Ceux-ci présentent des interfaces utilisateur variées et peuvent utiliser différents types de terminaux. Même lorsqu'ils utilisent le même type de terminal, leur comportement peut varier, car ils émulent un terminal et ces émulations ne sont pas parfaites. Mais, même en faisant abstraction des différences entre les logiciels clients, il existe plusieurs différences subtiles et moins subtiles entre une session connectée à un démon Telnet (telnetd ou telnet_msd) et une session connectée au démon SSH. Il existe également un certain nombre de bogues, que j'aborderai. Gardez à l'esprit que j'utilise le démon SSH de l'Internet Security Pack (ISP) pour OpenVOS version 2.1.0k. Il s'agit de la dernière version disponible au moment où j'ai rédigé cet article.
Noms d'utilisateur :
Avant même de vous connecter, il existe une différence dans la manière dont Telnet et SSH gèrent votre nom d'utilisateur. Les démons Telnet vous permettent de vous connecter avec n'importe quelle variante unique de votre nom d'utilisateur, et celui-ci n'est pas sensible à la casse. Avec le nom d'utilisateur Noah_Davids, je peux me connecter en tant que Noah_D, noah_d, NoAh_D ou NoAh_DaViDs lorsque j'utilise Telnet, mais la seule combinaison qui fonctionne avec SSH est Noah_Davids. Mon alias nd fonctionne de la même manière. Avec Telnet, je peux utiliser nd, ND ou nD, mais avec SSH, seul nd fonctionne.
Noms des groupes :
L'invite de connexion qui s'affiche lors d'une connexion Telnet me permet de spécifier un nom de groupe
telnet 164.152.77.217\ Tentative...\ Connecté à 164.152.77.217.\ Le caractère d'échappement est « ^] ». OpenVOS version 17.1.0ax, module %phx_vos#m17 Veuillez vous connecter 15:24:14 login nd.SysAdmin Mot de passe ? [mot de passe saisi ici] Noah_Davids.SysAdmin connecté sur %phx_vos#m17 le 12-12-12 à 15:24:55 mst. |
| Figure 1 – Connexion Telnet avec un nom de groupe |
Mais le protocole SSH n'autorise qu'un nom d'utilisateur. Si j'ajoute le nom du groupe, celui-ci est considéré comme faisant partie du nom d'utilisateur et la connexion échoue.
>system>openssl>bin>ssh [email protected] nd.SysAdminMot de passe de @164.152.77.217 : [mot de passe saisi ici] Autorisation refusée, veuillez réessayer. Mot de passe de [email protected] : |
| Figure 2 – Connexion SSH avec le nom du groupe |
Une fois connecté, vous pouvez changer de groupe à l'aide d'une connexion secondaire (mais consultez la section sur ssl-403 ci-dessous pour connaître les restrictions actuelles)
Différences entre les mots de passe :
La principale différence entre les connexions Telnet et SSH en matière de gestion des mots de passe réside dans le fait que SSH ne nécessite pas de mot de passe pour l'authentification. Vous pouvez configurer une paire de clés publique/privée et ainsi éviter toute l'étape de saisie du mot de passe. Consultez la section « Configuration de Stratus SSH pour l'authentification par clé publique » pour savoir comment procéder.
Si vous utilisez des mots de passe, vous devrez tenir compte de certaines différences. Tout d'abord, la gestion de l'expiration des mots de passe est différente. Avec Telnet, l'invite de connexion vous avertit lorsque votre mot de passe est sur le point d'expirer et vous permet de le modifier.
telnet 164.152.77.217
Tentative...
Connecté à 164.152.77.217.
Le caractère d'échappement est « ^] ».
OpenVOS version 17.1.0ax, module %phx_vos#m17
Veuillez vous connecter 14:04:40
login nd
Mot de passe ? [saisissez ici votre mot de passe actuel]
Votre mot de passe expirera dans 5 jours.
Nouveau mot de passe (première saisie) ?
|
| Figure 3 – Avertissement/invite concernant l'expiration du mot de passe de connexion Telnet |
SSH vous avertira, mais vous n'avez pas la possibilité de modifier ce paramètre. Vous devez utiliser la commande `change_password` pour invalider votre mot de passe, ce qui vous obligera à le modifier lors de votre prochaine connexion.
ssh [email protected] Mot de passe de [email protected] : [saisir ici le mot de passe actuel] Votre mot de passe expirera dans 5 jours. Noah_Davids.CAC s'est connecté sur %phx_vos#m17 le 09/01/13 à 13:06:35 MDT. Bienvenue. Prêt 13:06:35 changer_mot_de_passe Votre mot de passe n'est plus valide. Vous devez le modifier lors de votre prochaine connexion. Prêt 13 h 06 min 49 s |
| Figure 4 – Avertissement concernant l'expiration du mot de passe de connexion SSH et la commande change_password |
Une fois que votre mot de passe aura expiré (ou que vous l'aurez invalidé à l'aide de la commande change_password), vous serez invité à le modifier. Contrairement à Telnet, cette opération n'est pas facultative : vous devez modifier votre mot de passe à ce stade. Une fois votre mot de passe modifié, vous serez automatiquement déconnecté et devrez vous reconnecter.
ssh [email protected]\ Mot de passe de [email protected] : AVERTISSEMENT : votre mot de passe a expiré. Vous devez changer votre mot de passe maintenant et vous reconnecter ! Mot de passe actuel ? [mot de passe actuel saisi ici] Nouveau mot de passe (première saisie) ? [nouveau mot de passe saisi ici] Nouveau mot de passe (deuxième saisie) ? [nouveau mot de passe saisi ici] Connexion à 164.152.77.217 fermée. |
| Figure 5 – Modification de votre mot de passe pendant une connexion SSH |
Une autre différence réside dans le fait que les connexions SSH ne prennent pas en charge les mots de passe de type « challenge-response », contrairement aux connexions Telnet.
Sous-systèmes :
Lorsque vous vous connectez pour la première fois à un module via Telnet, la commande de connexion vous permet de sélectionner un sous-système
OpenVOS version 17.1.0ax, module %phx_vos#m17
Veuillez vous connecter 11:23:40
login -form -usage
--------------------------------- connexion -------------------------------
nom_utilisateur :
-privilégié : tel qu'enregistré
-mot_de_passe :
-changer_mot_de_passe : non
-priorité :
home:
-module :
-sous-système :
|
| Figure 6 – La connexion Telnet vous permet de spécifier un nom de sous-système |
Le protocole SSH ne dispose d'aucun mécanisme permettant de spécifier un nom de sous-système. Si l'indicateur `must_use_subsystem` est activé dans votre entrée de base de données d'enregistrement, le premier sous-système spécifié dans cette entrée est automatiquement utilisé. Si cet indicateur n'est pas activé, aucun sous-système n'est utilisé. (Notez qu'avant la version ISP 2.1.0j, le premier sous-système était utilisé même si le bit must_use_subsystem n'était pas activé.) Alors que les arguments de la commande login disponibles avant votre connexion permettent de spécifier le sous-système (voir figure 6), cette option n'est plus disponible une fois que vous êtes connecté (voir figure 7).
connexion -formulaire -utilisation --------------------------------- connexion ------------------------------- nom_du_groupe : CAC -privilégié : oui -priorité : -mot_de_passe : -module : |
| Figure 7 – Arguments de ligne de commande de la sous-commande « login » |
Une fois connecté, la seule façon d'accéder à un sous-système est de se reconnecter au système via Telnet et de se reconnecter.
telnet 127.0.0.1 Essai... Connecté à 127.0.0.1. Le caractère d'échappement est « ^] ». OpenVOS version 17.1.0ax, module %phx_vos#m17 Veuillez vous connecter 11:37:34 login nd -subsystem test_ss Mot de passe ? Noah_Davids.CAC s'est connecté sur %phx_vos#m17 le 12/12/13 à 11:37:49 mst. il s'agit du sous-système de test prêt 11:37:49 |
| Figure 8 – Se connecter via Telnet à l'adresse de bouclage et se reconnecter pour accéder à un sous-système |
Contrôle d'accès :
Les connexions Telnet et SSH prennent toutes deux en charge les TCP Wrappers, ce qui vous permet de restreindre l'accès en fonction de l'adresse IP. Cependant, avec les démons Telnet, les TCP Wrappers ne sont pas activés par défaut et vous devez les activer explicitement à l'aide de l'argument de contrôle -tcpwrapper_check. En revanche, avec le démon SSH, les TCP Wrappers sont activés par défaut et il n'est pas possible de les désactiver. Vous pouvez toutefois le désactiver de manière efficace en autorisant toutes les connexions SSH dans le fichier de configuration hosts.allow de TCP Wrappers.
telnetd -form -usage
------------------------------- telnetd ------------------------------
-service_file: >system>stcp>telnetservice
-tcpwrapper_check : non
-numeric : oui
|
| Figure 9 – Activation des TCP Wrappers dans le démon telnetd |
telnet_msd -form -usage
------------------------------ telnet_msd ----------------------------
-network_port: 24
-max_sessions: 28
-error_severity: 2
-separate_log: oui
-log_dir: >system>stcp>logs
-vterm_starname: telnet*
-vterm_login: yes
-vterm_slave_id:
-extension: 133
-force_edit: yes
-EC_decimal_value: 8
-EL_decimal_value: 21
-tcpwrapper_check : non
-numeric : non
|
| Figure 10 – Activation des TCP Wrappers dans le démon telnet_msd |
Le démon sshd prend également en charge des options dans le fichier sshd_config qui vous permettent de spécifier les utilisateurs ou les groupes auxquels l'accès via SSH doit être autorisé (directives AllowUsers et AllowGroups) ou refusé (directives DenyUsers et DenyGroups). Ces directives vous permettent de spécifier des noms d'utilisateurs, des domaines d'origine ou des combinaisons de ces éléments. Il est possible d'autoriser noah_davids provenant de corp.stratus.com, mais de le refuser s'il provient de az.stratus.com.
Autoriser les utilisateurs *@*.stratus.com Refuser les utilisateurs *@*az.stratus.com |
| Figure 11 – Exemple de directives AllowUsers et DenyUsers dans le fichier sshd_config |
>system>openssl>bin>ssh [email protected] Mot de passe de [email protected] : Accès refusé, veuillez réessayer. Mot de passe de [email protected] : |
| Figure 12 – Connexion depuis phxtest-m15.az.stratus.com refusée en raison de la directive DenyUsers |
Environnement de commande :
Une fois connecté, une connexion Telnet vous donne accès à l'environnement de commande VOS standard. SSH permet à un administrateur de choisir entre l'environnement de commande standard et l'environnement du shell bash. Ce choix s'effectue en fonction des numéros de port.
d sshservices %phx_vos#m17_mas>opt>openssl>etc>sshservices 12-12-13 12:31:31 mst ssh "window_term" "" "login" 1 1 s$pt_log.m16 ssh2200 "window_term" "-shell" "bash" 1 1 s$pt_log.m16 |
| Figure 13 – Fichier sshservices : le port 22 correspond à la ligne de commande standard de VOS, le port 2200 correspond au shell bash |
>system>openssl>bin>ssh [email protected] -p 2200 Mot de passe de [email protected] : Bienvenue. sh-2.05$ |
| Figure 14 – Connexion SSH via le port 2200 et obtention d'un shell Bash |
Variables d'environnement :
Par défaut, les connexions Telnet ne définissent que 6 variables d'environnement, tandis que les connexions SSH en définissent 12
env HOME LOGNAME=root PATH=.:/system/command_library:/system/applications_library:/system/maint_librar +y:/system/nio/command_library:/system/tools_library:/opt/apache/bin:/opt/libxml +2/bin:/opt/php/bin:/opt/openssl/bin:/opt/mysql/bin:/system/stcp/command_library +:/system.17.1/gnu_library/bin VOS_INCLUDE_PATH=.:/opt/apache/include:/opt/openssl/include:/opt/mysql/include/m +ysql:/system/stcp/include_library/compat:/system/include_library VOS_OBJECT_PATH=.:/opt/apache/lib:/opt/openssl/lib:/opt/mysql/lib/mysql:/system/ +stcp/object_library/complib:/system/posix_object_library/pthread:/system/posix_ +object_library:/system/c_object_library:/system/object_library TERM=vt100 |
| Figure 15 – Variables d'environnement définies dans une connexion Telnet |
env\ HOME\ PATH=.:/system/command_library:/system/applications_library:/system/maint_library\ +y:/system/nio/command_library:/system/tools_library:/opt/apache/bin:/opt/libxml +2/bin:/opt/php/bin:/opt/openssl/bin:/opt/mysql/bin:/system/stcp/command_library\ +:/system.17.1/gnu_library/bin VOS_INCLUDE_PATH=.:/opt/apache/include:/opt/openssl/include:/opt/mysql/include/m +ysql:/system/stcp/include_library/compat:/system/include_library VOS_OBJECT_PATH=.:/opt/apache/lib:/opt/openssl/lib:/opt/mysql/lib/mysql:/system/ +stcp/object_library/complib:/system/posix_object_library/pthread:/system/posix_ +object_library:/system/c_object_library:/system/object_library\ TERM=vt100\ TZ=mst+07:00:00\ USER=Noah_Davids\ LOGNAME=Noah_Davids\ MAIL=/var/spool/mail/Noah_Davids\ SHELL=/bin/sh SSH_CONNECTION=164.152.77.34 49573 164.152.77.217 22 SSH_TTY=#s$pt_log.m16_3 |
| Figure 16 – Variables d'environnement définies dans une connexion SSH |
Types d'appareils :
Enfin, il ne s'agit pas vraiment d'une différence entre Telnet et SSH, mais plutôt entre les démons telnetd et sshd, d'une part, et le démon telnet_msd, d'autre part. Telnetd et sshd utilisent tous deux des périphériques window_term, tandis que telnet_msd utilise des périphériques vterm. Il existe certaines différences entre la manière dont les périphériques vterm et window_term gèrent certaines touches de fonction (comme CANCEL) en ligne de commande et la manière dont ils traitent la sortie brute à l'écran. Certaines applications qui créent leurs propres formulaires et n'ont pas été mises à jour pour utiliser les nouveaux OP_CODES s$control ne présentent pas correctement ces formulaires lorsqu'elles utilisent des périphériques window_term. La deuxième meilleure solution pour gérer ces applications consiste à utiliser un tunnel SSH pour se connecter au système ; le tunnel est alors configuré pour se connecter au démon telnet_msd. La meilleure solution pour gérer l'application est, bien sûr, de la mettre à jour pour qu'elle utilise les nouveaux OP_CODES.
Outre les différences susmentionnées, qui sont inhérentes à Telnet et à SSH, quelques bogues seront corrigés dans une prochaine version.
ssl-403 Groupes disponibles :
Lors d'une connexion via Telnet, tous les groupes spécifiés dans votre entrée d'enregistrement sont disponibles pour les connexions secondaires, mais avec SSH, seuls les 5 premiers groupes sont disponibles.
Étant donné que je suis inscrit aux groupes CAC, SysAdmin, Group_3, Group_4, Group_5 et Group_6, je peux effectuer une connexion en tant que membre d'un de ces groupes via une connexion Telnet
telnet 164.152.77.217 Tentative... Connecté à 164.152.77.217. Le caractère d'échappement est « ^] ». OpenVOS version 17.1.0ax, module %phx_vos#m17 Veuillez vous connecter 15:38:02 login nd Mot de passe ? [mot de passe actuel saisi ici] Noah_Davids.CAC s'est connecté sur %phx_vos#m17 le 12-12-12 à 15:38:08 mst. Connexion Group_5 Noah_Davids.Group_5 s'est connecté sur %phx_vos#m17 le 12-12-12 à 15:39:39 (heure normale des Rocheuses). Prêt 15:39:39 Déconnexion Connexion Group_6 Noah_Davids.Group_6 s'est connecté sur %phx_vos#m17 le 12/12/12 à 15 h 40 min 13 s (heure normale des Rocheuses). Prêt 15 h 40 min 13 s |
| Figure 17 – Connexions secondaires via Telnet |
Cependant, avec SSH, lorsque j'essaie d'utiliser Group_6, j'obtiens une erreur.
>system>openssl>bin>ssh [email protected] Mot de passe de [email protected] : Noah_Davids.CAC s'est connecté sur %phx_vos#m17 le 12/12/12 à 15:41:02 MST. Prêt 15:41:02 connexion Group_5 Noah_Davids.Group_5 s'est connecté sur %phx_vos#m17 le 12/12/12 à 15:41:24 MST. Prêt 15:41:24 Déconnexion Connexion Group_6 Connexion : format d'argument invalide. Group_6 n'est pas autorisé pour group_name. Prêt 15:41:59 |
| Figure 18 – Connexions secondaires via SSH |
ssl-418 – Le niveau sub_process_level :
Les connexions via Telnet ont un niveau de sous-processus égal à 0, tandis que celles via SSH ont un niveau de sous-processus égal à 3.
telnet 164.152.77.217\
Tentative...\
Connecté à 164.152.77.217.\
Le caractère d'échappement est « ^] ».\
\
OpenVOS version 17.1.0ax, module %phx_vos#m17\
Veuillez vous connecter 14:15:34
login nd
Mot de passe ? [mot de passe actuel saisi ici]
Noah_Davids.CAC connecté sur %phx_vos#m17 le 12-12-13 à 14:15:39 mst.
prêt 14:15:39
display_line (process_info sub_process_level)
0
Prêt 14:15:49
|
| Figure 19 – Niveau de sous-processus défini dans une connexion Telnet |
>system>openssl>bin>ssh [email protected]\nMot de passe de [email protected] : [entrer ici le mot de passe actuel] Noah_Davids.CAC s'est connecté sur %phx_vos#m17 le 12/12/13 à 14:12:23 MST. prêt 14:12:23 display_line (process_info sub_process_level) 3 prêt 14:12:37 |
| Figure 20 – Niveau de sous-processus défini dans une connexion SSH |
Mise à jour du 14 janvier 2013 : Il s'avère qu'il s'agit d'une fonctionnalité et non d'un bug. Le processus sshd est dupliqué une première fois lorsque start_process est exécuté pour lancer le processus d'écoute, une deuxième fois lorsque sshd accepte la connexion et une troisième fois lorsque le processus de connexion de l'utilisateur est créé. Telnet utilise un mécanisme différent pour lancer le processus utilisateur, ce qui n'entraîne aucune duplication de processus.
Problèmes liés au fuseau horaire :
Pour finir, je tiens simplement à signaler qu'il y a eu plusieurs problèmes liés au passage de l'heure d'été à l'heure d'hiver, ou plus généralement au changement de fuseau horaire. Les sessions connectées via SSH ne tenaient pas compte des nouveaux paramètres par défaut. Ces problèmes devraient tous être résolus dans cette dernière version (2.1.0k).