SSH : Shell sécurisé

SSH signifie Secure Shell. Il est également connu sous le nom de Secure Socket Shell. Un protocole réseau cryptographique appelé Secure Shell (SSH) est utilisé pour exploiter en toute sécurité des services réseau sur des réseaux non sécurisés. L'architecture client-serveur constitue la base des applications SSH, qui relient une instance client SSH à un serveur SSH.

En tant que successeur de Telnet et des protocoles shell Unix distants dangereux tels que Berkeley Remote Shell (rsh) et ses protocoles rlogin et rexec associés, SSH a été créé pour les systèmes d'exploitation de type Unix qui utilisent une communication par jeton d'authentification en texte clair non sécurisée.

Définition

Nous pouvons appliquer SSH de plusieurs manières différentes. La mise en œuvre la plus simple chiffre les données à l'aide de paires de clés publique-privée générées automatiquement aux deux extrémités d'un canal de communication et d'une connexion réseau. Après cela, il authentifie l'utilisateur à l'aide d'un mot de passe. Lorsqu'un utilisateur génère manuellement une paire de clés publique-privée, l'authentification est pratiquement terminée lorsque la paire de clés est établie, permettant de lancer une session instantanément sans demande de mot de passe.

java en objet json

Dans ce cas, le propriétaire garde secrète la clé privée correspondante et la clé publique est installée sur toutes les machines qui doivent accorder l'accès au propriétaire. Bien que la clé privée serve de base à l'authentification, elle n'est jamais envoyée sur le réseau lors de l'authentification. SSH confirme que le fournisseur de la clé publique détient également la clé privée correspondante.

Il est crucial de connecter la clé publique inconnue avec une clé privée connue dans toutes les versions de SSH avant de les accepter comme clés publiques légitimes avec identifiants. Accepter une clé publique d'un attaquant sans la valider acceptera un attaquant non fiable comme utilisateur légitime.

Création

Tatu Ylönen, un informaticien finlandais, a créé SSH pour la première fois en 1995. Le développement ultérieur de la suite de protocoles a eu lieu dans de nombreux groupes de développeurs, conduisant à diverses itérations de mise en œuvre. Il existe des implémentations disponibles pour tous les systèmes d'exploitation courants, y compris les systèmes embarqués. OpenSSH, que les créateurs d'OpenBSD ont rendu disponible en tant que logiciel open source en 1999, est la pile logicielle la plus fréquemment utilisée.

Gestion des clés OpenSSH pour l'authentification

La liste des clés publiques approuvées est généralement conservée sur les systèmes de type Unix dans le fichier ~/.ssh/authorized key du répertoire personnel de l'utilisateur, qui dispose de privilèges de connexion à distance. SSH ne respecte ce fichier que s'il ne peut être modifié par personne autre que le propriétaire et le root. Le mot de passe n'est plus nécessaire lorsque la clé publique de l'extrémité distante et la clé privée correspondante de l'extrémité locale sont présentes. Mais nous pouvons utiliser une phrase secrète pour verrouiller la clé privée pour une protection bien plus grande. Nous pouvons également rechercher le code secret dans des emplacements courants et utiliser une option de ligne de commande pour fournir son chemin complet (option -i pour ssh).

SSH fournit en outre une authentification automatisée basée sur un mot de passe crypté par génération de clés. Dans ce scénario, l'attaquant peut usurper l'identité du serveur digne de confiance, demander le mot de passe et l'obtenir (attaque de l'homme du milieu). Côté serveur, nous pouvons désactiver l'authentification par mot de passe.

Utiliser

SSH utilise le paradigme client-serveur. Généralement, SSH est utilisé pour la journalisation. Il peut également tunneler les ports TCP, transférer les connexions X11 et exécuter des commandes sur un système distant. Généralement, les connexions à un démon SSH autorisant les connexions à distance sont établies à l'aide d'une application client SSH. Les deux se trouvent souvent sur la plupart des systèmes d'exploitation contemporains, tels que macOS, les distributions Linux, OpenBSD, FreeBSD, NetBSD, Solaris et OpenVMS. Certaines versions sont propriétaires, gratuites et open source avec différents degrés de complexité et d'exhaustivité (comme PuTTY et la version d'OpenSSH incluse avec Cygwin et OpenSSH). Notamment, SSH n'est pas inclus par défaut dans les versions de Windows jusqu'à la version 1709 de Windows 10.

Une fonctionnalité similaire de gestion de fichiers (synchronisation, copie et suppression à distance) est offerte par l'application Windows gratuite et open source WinSCP, qui utilise PuTTY comme back-end. Sans avoir besoin d'être installés sur l'ordinateur client, WinSCP et PuTTY sont disponibles emballés pour fonctionner directement à partir d'une clé USB. L'activation d'une fonctionnalité dans l'application des paramètres est souvent nécessaire pour configurer un serveur SSH sous Windows.

Pour gérer les problèmes de connexion et prévenir les risques de sécurité liés à l’exposition directe d’une machine virtuelle basée sur le cloud à Internet, SSH est crucial dans le cloud computing. Une connexion sécurisée sur Internet peut être rendue possible via un ordinateur virtuel de tunnel SSH via un pare-feu. Pour ce protocole, l'IANA a désigné le port TCP 22, le port UDP 22 et le port SCTP 22.

Dès 2001, l'IANA a classé le port TCP 22 par défaut pour les serveurs SSH parmi les ports les plus connus. Le protocole de couche transport orienté connexion SCTP peut être utilisé pour exécuter SSH au lieu de TCP.

Progression historique

Itération 1

Une attaque de détection de mots de passe sur le réseau de son institution a inspiré Tatu Ylönen, chercheur à l'Université de technologie d'Helsinki en Finlande, à créer la première itération du protocole (aujourd'hui connu sous le nom de SSH-1) en 1995.

SSH a été conçu pour prendre le rôle des protocoles antérieurs, notamment rlogin, TELNET, FTP et rsh, qui manquaient de garanties d'authentification et de confidentialité robustes. Ylönen a rendu son application disponible en freeware. En juillet 1995, l'appareil est rapidement devenu populaire. Fin 1995, on comptait 20 000 utilisateurs SSH répartis dans 50 pays différents.

Pour promouvoir et faire progresser SSH, Ylönen a créé SSH Communications Security en décembre 1995. Divers composants logiciels libres, dont GNU libgmp, ont été utilisés dans la première version du programme SSH, mais les itérations ultérieures fournies par SSH Communications Security sont devenues des logiciels de plus en plus propriétaires. Selon les estimations, il y avait 2 millions d'utilisateurs en 2000.

Itération 2

L'Internet Engineering Task Force (IETF) a désigné le groupe de travail chargé de créer la version 2 du protocole SSH comme « Secsh » dans sa documentation officielle.

taille du vecteur c++

SSH-2, une itération de protocole améliorée, est devenue une norme en 2006. SSH-1 n'est pas compatible avec cette version. SSH-2 offre des fonctionnalités et des mises à niveau de sécurité par rapport à SSH-1. Par exemple, l'échange de clés Diffie-Hellman et la vérification robuste de l'intégrité via des codes d'authentification de message offrent une sécurité accrue. La possibilité d'exploiter un nombre illimité de sessions shell sur une seule connexion SSH est l'une des nouvelles fonctionnalités de SSH-2. Étant donné que SSH-2 est plus avancé et largement utilisé que SSH-1, certaines implémentations, telles que libssh (v0.8.0+), Lsh et Dropbear, ne prennent en charge que SSH-2.

Itération 1.99

La RFC 4253 exigeait qu'un serveur SSH prenant en charge la version 2.0, ainsi que les versions antérieures, indique la version de son protocole comme 1.99 en janvier 2006, bien après le développement de la version 2.1. Ce numéro de version est utilisé pour indiquer la compatibilité ascendante plutôt que pour représenter une révision logicielle précédente.

OSSH et OpenSSH

Depuis que la dernière version du programme SSH original, la version 1.2.12, a été distribuée sous licence open source en 1999, les développeurs travaillent sur une version logicielle gratuite. Ceci a servi de base au programme OSSH de Björn Grönvall. Peu de temps après, l'équipe OpenBSD a cloné le travail de Grönvall pour produire OpenSSH, qui était inclus dans la version 2.6 d'OpenBSD. Ils ont créé une branche « portabilité » à partir de cette version pour transférer OpenSSH vers différents systèmes d'exploitation.

L'implémentation SSH la plus largement utilisée en 2005 était OpenSSH, la version par défaut dans de nombreuses distributions de systèmes d'exploitation. Après avoir supprimé la prise en charge de SSH-1 de la base de code dans la version OpenSSH 7.6, OpenSSH est toujours en cours de mise à jour et prend en charge le protocole SSH-2. Pendant ce temps, OSSH n’est plus d’actualité.

Les usages

L'utilisateur 'josh' 'SSH' depuis l'ordinateur local 'foofighter' vers la machine distante 'tengwar' pour exécuter xeyes comme exemple de tunneling d'un programme X11 via SSH. Les gens utilisent le client Windows SSH PuTTY pour accéder à OpenWrt.

SSH est un protocole qui fonctionne avec de nombreux systèmes, notamment Microsoft Windows et la plupart des variantes d'Unix (Linux, BSD, y compris macOS d'Apple et Solaris). Les applications suivantes peuvent nécessiter des fonctionnalités exclusives ou compatibles avec des clients ou des serveurs SSH particuliers. Par exemple, il n’est actuellement possible d’utiliser que l’implémentation client et serveur OpenSSH du protocole SSH pour construire un VPN.

• Pour accéder à un shell sur un hôte distant (en remplacement de Telnet et rlogin)
• Pour exécuter une commande solitaire sur un hôte distant (en remplacement de rsh)
• Pour configurer la connexion automatisée (sans mot de passe) d'un serveur distant (par exemple, en utilisant OpenSSH)
• En tant que VPN crypté entièrement fonctionnel, gardez à l’esprit que seuls le client et le serveur OpenSSH prennent en charge cette fonctionnalité.
• Pour transmettre X depuis un hôte distant (possible via plusieurs hôtes intermédiaires)
• Pour utiliser des clients SSH prenant en charge le protocole SOCKS pour naviguer sur Internet via une connexion proxy cryptée.
• Pour monter en toute sécurité le répertoire d'un serveur distant en tant que système de fichiers sur une machine locale utilisant SSHFS.
• Grâce à une ou plusieurs des technologies mentionnées ci-dessus pour la surveillance et l'administration automatiques des serveurs à distance.
• Pour le développement d’appareils mobiles ou embarqués compatibles SSH.
• Pour protéger les mécanismes de transfert de fichiers.

Méthodes de transfert de fichiers

Plusieurs systèmes de transfert de fichiers utilisent des protocoles Secure Shell tels que

• Sur SSH, Secure Copy (SCP) est développé à partir du protocole RCP.
• rsync, censé être plus efficace que SCP, est souvent exploité via une connexion SSH.
• Une alternative sûre au FTP est le protocole de transfert de fichiers SSH (SFTP) (à ne pas confondre avec FTP sur SSH ou FTPS).
• FISH, ou fichiers transférés via le protocole shell, a été introduit en 1998 et développé à partir de SSH sur des instructions shell Unix.
• Aspera, également connu sous le nom de Fast and Secure Protocol (FASP), utilise SSH pour les commandes et pour le transport de données, les ports UDP.

Architecture

Trois composants distincts constituent l'architecture en couches du protocole SSH :

• Le protocole TCP (Transmission Control Protocol) de TCP/IP est couramment utilisé par la couche transport (RFC 4253), le port numéro 22 étant réservé comme port d'écoute du serveur. Cette couche implémente le chiffrement, la compression, la vérification de l'intégrité, l'échange initial de clés et l'authentification du serveur. Bien que chaque implémentation puisse permettre davantage, elle expose à la couche supérieure une interface pour transmettre et recevoir des paquets de texte en clair allant jusqu'à 32 768 octets chacun. Habituellement, après le transport de 1 Go de données ou après une heure, selon la première éventualité, la couche de transport organise le rééchange des clés.
  
• L'authentification du client est gérée via la couche d'authentification de l'utilisateur (RFC 4252), qui propose également plusieurs techniques d'authentification. L'authentification pilotée par le client signifie que le client SSH, et non le serveur, peut demander un mot de passe à l'utilisateur. Seules les demandes d'authentification du client reçoivent une réponse du serveur. Les techniques d'authentification des utilisateurs suivantes sont souvent utilisées :
  Mot de passe, une technique simple d'authentification par mot de passe qui inclut la possibilité de modifier le mot de passe. Tous les logiciels n'utilisent pas cette technique.
• Prenant généralement en charge au moins les paires de clés DSA, ECDSA ou RSA, le Clé publique est une technique d'authentification basée sur une clé publique. D'autres implémentations acceptent également les certificats X.509.
Clavier interactif(RFC 4256) est une technique flexible dans laquelle le serveur fournit une ou plusieurs invites de saisie d'informations, le client les affiche, puis renvoie les réponses que le client a saisies. Utilisé par certains paramètres OpenSSH pour offrir efficacement une authentification par mot de passe lorsque PAM est le fournisseur d'authentification de l'hôte sous-jacent, ce qui peut parfois empêcher la connexion avec un client qui ne prend en charge que la technique d'authentification par mot de passe simple.
• La fonctionnalité d'authentification unique pour les sessions SSH est fournie via GSSAPI techniques d'authentification, qui offrent un système extensible pour gérer l'authentification SSH à l'aide de mécanismes externes comme Kerberos 5 ou NTLM. Bien qu'OpenSSH dispose d'une implémentation GSSAPI fonctionnelle, les implémentations commerciales SSH intègrent souvent ces techniques pour une utilisation dans les entreprises.
• L'idée des canaux qui définissent les services SSH proposés est définie par la couche connexion (RFC 4254). Nous pouvons multiplexer plusieurs connexions SSH à partir d’une seule. Les deux transmettent des données dans les deux sens. Les requêtes de canal transmettent des données hors bande spécifiques à un canal donné, telles que le code de sortie d'un processus côté serveur ou le changement de taille d'une fenêtre de terminal. De plus, en utilisant la taille de la fenêtre de réception, chaque canal contrôle son flux. Le client SSH effectue une demande globale pour transférer un port côté serveur. Les types de canaux courants incluent :
  • Shell pour les shells SFTP, exec et terminaux (y compris les transferts SCP)
  • Direct-TCPIP pour les connexions transférées du client vers le serveur.
  • Connexions transférées serveur à client à l'aide de forwarded-tcpip
  • Pour confirmer la légitimité de l'hôte, l'enregistrement DNS SSHFP (RFC 4255) propose les empreintes digitales de la clé publique de l'hôte.

Grâce à sa conception ouverte, nous pouvons utiliser SSH pour un large éventail de tâches en plus de sécuriser les shells, ce qui lui confère une grande polyvalence.

qu'est-ce qu'obj en java

Vulnérabilités

SSH-1

En raison de la protection inadéquate de l'intégrité des données fournie par CRC-32 dans cette version du protocole, une vulnérabilité dans SSH 1.5 a été identifiée en 1998, permettant l'insertion non autorisée de matériel dans un flux SSH crypté. Dans la plupart des implémentations, ils ont ajouté un correctif appelé SSH Compensation Attack Detector. Plusieurs de ces implémentations révisées incluaient une nouvelle faille de dépassement d'entier, permettant aux attaquants d'exécuter du code arbitraire avec root ou les capacités du démon SSH.

Une faille permettant aux attaquants de modifier le dernier bloc d'une session chiffrée par IDEA a été découverte en janvier 2001. Une autre faille permettant à un serveur malveillant de transmettre une connexion client à un autre serveur a été découverte le même mois.

En raison de ses vulnérabilités inhérentes, SSH-1 est généralement considéré comme obsolète et doit être évité en supprimant explicitement le repli de SSH-1. La plupart des serveurs et clients actuels prennent en charge SSH-2.

Récupération de texte brut pour CBC

Une vulnérabilité théorique qui permettait de récupérer jusqu'à 32 bits de texte brut à partir d'un bloc de texte chiffré à l'aide de la méthode de chiffrement standard de l'époque, CBC, a été découverte dans toutes les versions de SSH en novembre 2008. La solution la plus simple consiste à passer à CTR, contre mode, au lieu du mode CBC, qui rend SSH immunisé contre l'attaque.

La NSA soupçonnée de décryptage

La divulgation par Edward Snowden de documents sensibles au Spiegel le 28 décembre 2014 implique que la National Security Agency sera potentiellement en mesure de décoder certaines communications SSH.