Selon ssh.com et Wikipedia, la première version et implémentation du protocole SSH a été publiée en 1995. La tâche de l'auteur était de développer une alternative sûre à rlogin, telnet et rsh, qui étaient ensuite utilisés pour l'administration à distance. Il est curieux que l'émergence du protocole SSH ait été facilitée par un incident de sécurité de l'information, à la suite duquel l'attaquant a collecté une impressionnante base de données de noms d'utilisateur / mots de passe à partir des serveurs, en écoutant simplement le réseau universitaire et en extrayant des paquets d'authentification (les paires nom d'utilisateur / mot de passe ont été transmises sous forme non cryptée).
Le protocole a rapidement gagné en popularité et, après une longue période de perfectionnements et d'améliorations, a été normalisé par l'IETF en 2006. Depuis lors, il a réussi à devenir la norme de facto pour la gestion à distance des systèmes de console texte. En plus de la console texte elle-même, le protocole fournit une foule d'autres fonctions utiles, telles que le transfert de fichiers et la redirection de port. Il s'agit de la redirection de port et de son application pas trop évidente qui sera discutée dans cet article.
Le protocole SSH propose deux modes de redirection de port - avant et arrière. Le mode direct vous permet d'ouvrir un port TCP d'écoute côté client SSH et de transmettre toutes les connexions à ce port côté serveur.
Par exemple, si un serveur Bureau à distance (RDS) est en cours d'exécution sur notre serveur SSH, nous pouvons utiliser le protocole SSH pour se connecter à ce serveur même si une connexion réseau directe n'est pas possible (par exemple, il est bloqué par un pare-feu). Comme ça:
Le deuxième mode de redirection de port - inverse - vous permet d'échanger les rôles du serveur SSH et du client (tel qu'appliqué au port redirigé). En mode inverse, le port TCP d'écoute s'ouvre côté serveur SSH et l'application desservant ce port se trouve côté client SSH. Il est rarement utile, mais, en règle générale, très judicieusement.
En combinant ces deux modes et notre exemple avec un serveur de bureau distant, vous pouvez obtenir cette configuration:
À première vue, il semble redondant. Mais avec la redondance apparente, nous avons obtenu deux propriétés importantes:
- La seule chose requise du réseau pour qu'un tel schéma fonctionne correctement est de garantir l'adresse réseau de l'hôte sur lequel se trouve le serveur SSH. Les nœuds sur lesquels le serveur et le client RDS s'exécutent peuvent changer leurs adresses réseau au moins toutes les minutes (ou ils peuvent même avoir des adresses sur le réseau privé, nous n'avons besoin que du NAT sortant, qui est souvent appelé le libellé de «connexion Internet»).
- Malgré le fait que pour nous le serveur RDS est accessible de n'importe où sur Internet, les autres utilisateurs ne peuvent pas s'y connecter (à condition qu'il n'y ait pas de vulnérabilités dans le serveur SSH). Et puisque le protocole RDS a son propre contrôle d'accès, même en cas d'attaque réussie sur le serveur SSH, l'attaquant devra également effectuer une attaque sur RDS. La probabilité d'avoir à la fois une vulnérabilité de serveur SSH et une vulnérabilité de serveur RDS est bien inférieure à cette probabilité pour chaque composant individuellement.
Si vous regardez attentivement, alors dans ce diagramme, vous pouvez voir deux réseaux informatiques indépendants. One - transport - vous permet d'établir des connexions SSH. Un autre - interne - est utilisé à des fins appliquées. Nous allons essayer de tirer quelques conclusions intéressantes de cette observation dans les articles suivants, mais pour l'instant, revenons à nos expériences.
Connectez-vous à votre ordinateur personnel
Dans la cour du 21e siècle, la livraison d'un paquet réseau de la Sibérie à la Californie prend 0,1 seconde, le monde entier est empêtré dans les réseaux informatiques et TCP / IP est même dans les brosses à dents. Il semblerait qu'avec une telle connectivité de tout avec tout, nous aurions dû être en mesure de contrôler un ordinateur il y a longtemps non seulement grâce à une présence physique à proximité des périphériques d'entrée, mais également à distance, sur le réseau. De plus, il existe de nombreuses technologies et protocoles pour cela. Bureau à distance de Microsoft, variations VNC sur les systèmes * nix, solutions Citrix, des milliers d'entre eux ... Néanmoins, peu d'entre nous peuvent se vanter d'avoir la possibilité de se connecter à notre ordinateur personnel de n'importe où dans le monde en utilisant l'une de ces technologies.
Il y a deux raisons pour lesquelles peu peuvent se vanter de se connecter à leur propre ordinateur à la maison, et ils sont connectés les uns aux autres. Le premier est l'absence d'une adresse d'ordinateur domestique typique dans le réseau mondial. Les origines de cet état de fait remontent à 1981, au cours de laquelle la norme IPv4 a été décrite pour la première fois, et qui est utilisée à ce jour (seule, avec des modifications et des ajouts) pour adresser la plupart des sites sur Internet. Les auteurs de la norme ont décidé que l'espace d'adressage d'une capacité de 3,7 milliards d'adresses est suffisant pour tous les appareils dans le monde, mais la réalité s'est avérée dure. Internet IPv4 ne devrait pas être disponible d'ici septembre 2019.
De plus, un utilisateur Internet typique qui n'héberge pas de sites Web peut très bien profiter de tous les avantages de la civilisation sans avoir d'adresse sur le réseau mondial, se limitant à la place à une adresse sur un réseau privé et un fournisseur NAT. En d'autres termes, pour la plupart des internautes, il n'y a pas de différence entre la présence et l'absence d'une adresse IP globale pour leur équipement. Dans de telles circonstances, le nombre de ceux à qui le fournisseur délivre une adresse IP globale dans le réseau mondial diminue rapidement. Par conséquent, un ordinateur personnel typique se trouve sur un réseau privé et n'a pas d'adresse globale. Même si le fournisseur attribue toujours à l'équipement utilisateur une adresse dans le réseau mondial, cet équipement est un routeur domestique qui exécute NAT à partir d'un réseau privé domestique. L'utilisateur, bien sûr, peut «transférer le port» sur le routeur, mais même dans ce meilleur cas, l'adresse globale du routeur peut changer de jour en jour. Oui, il existe des fournisseurs qui fournissent le service «Static IP» pour une somme modique, mais dans la pratique, à ce moment, l'utilisateur se rend compte que le jeu ne vaut pas la chandelle, et si vous devez faire quelque chose avec votre ordinateur personnel, vous pouvez également appeler appeler.
Les plus persistants peuvent mener à bien cette quête jusqu'au bout et rencontrer la deuxième raison pour laquelle l'accès à leur ordinateur via Internet n'est un divertissement que pour ceux qui sont dynamiques. Cette raison est courante - la sécurité de l'information. Le réseau mondial est mondial, tôt ou tard, quelqu'un de l'autre bout du monde et avec de mauvaises intentions frappera à votre porte. L'analyse du port ouvert sur lequel le serveur de bureau distant répond n'est pas une tâche très difficile, et, bien sûr, tôt ou tard, TCP SYN arrivera sur votre port super secret 32167 depuis un village chinois.
Pour en revenir à notre transfert de port exotique en utilisant SSH, vous remarquerez que ses fonctionnalités éliminent ces deux raisons.
Construisez-vous un TeamViewer
Vous devez réserver immédiatement que TeamViewer est un excellent produit avec un grand nombre de capacités très différentes. Dans le cadre de cet article, nous ne collecterons pour nous-mêmes qu'un moyen de se connecter en toute sécurité via Internet via le protocole Remote Desktop à un ordinateur situé derrière NAT. Néanmoins, j'ose suggérer que c'est la connexion à n'importe quel ordinateur avec accès à Internet qui est la principale caractéristique distinctive de TeamViewer, en raison de laquelle ce produit est si populaire. Et c'est précisément une telle connexion que nous pouvons mettre en œuvre de nos propres mains en utilisant notre configuration SSH de la première partie de l'article.
Donc, les conditions de la tâche: il y a un ordinateur personnel et un ordinateur portable, tous deux exécutent Windows 10. Il est nécessaire de permettre à l'ordinateur portable d'accéder à l'ordinateur domestique en utilisant le protocole Remote Desktop depuis n'importe où dans le monde. Notre système comprendra notre serveur d'ordinateur de bureau à distance, un ordinateur portable avec un client de bureau à distance et un serveur SSH. Le serveur SSH est le seul composant qui nécessite une adresse IP globale et une disponibilité permanente. L'option la plus simple pour répondre à ces exigences est d'héberger un serveur SSH dans le cloud. Yandex.Cloud est génial (principalement en raison de sa politique de prix), nous allons donc l'utiliser. Le résultat est comme ceci:
Commençons par préparer notre ordinateur personnel. Tout d'abord, assurez-vous que l'accès à distance est généralement autorisé. Cela peut être fait via l'onglet Accès à distance dans les paramètres système supplémentaires:
Depuis avril 2018, Windows 10 dispose déjà d'un client ssh parmi les utilitaires de ligne de commande. Cela nous aidera à être moins distraits en installant différents logiciels et à nous mettre immédiatement au travail. Tout d'abord, nous générons une clé pour SSH. Ouvrez le shell PowerShell et exécutez 'ssh-keygen'. Lorsqu'on nous demande le mot de passe de la clé, laissez-le vide. Après avoir généré la clé, affichez sa partie ouverte sur la console avec la commande 'cat $ HOME / .ssh / id_rsa.pub'. Le résultat de la commande nous est utile pour démarrer le serveur SSH dans le cloud. Vous devriez obtenir quelque chose comme ceci:
Nous devons copier la partie privée de la clé SSH sur l'ordinateur portable. Cette partie de la clé se trouve dans le fichier '$ HOME / .ssh / id_rsa' (sans le suffixe ".pub"), et nous pouvons le copier comme un fichier normal. Par exemple, en utilisant un lecteur flash USB (nous supposons qu'il est monté en tant que lecteur F :)
copy $HOME/.ssh/id_rsa f:\
Exécutez maintenant notre serveur SSH. Créez une machine virtuelle (VM) dans Yandex.Cloud. Pour nos besoins, vous pouvez choisir une machine virtuelle «légère» avec 1 processeur virtuel et 0,5 gigaoctet de RAM. Dans la section des paramètres réseau, sélectionnez le réseau par défaut avec une adresse IP automatique. Dans la section «accès», entrez «home» comme identifiant, dans le champ de saisie de la clé SSH, copiez ce qui était affiché dans notre console à l'étape précédente:
Cliquez sur "Créer une VM" et attendez la fin. Une fois la création de la machine virtuelle terminée, nous devons connaître son adresse IP:
Nous aurons besoin de l'adresse IP de notre machine virtuelle pour exécuter le client SSH sur l'ordinateur domestique et l'ordinateur portable. Exécutez-le sur l'ordinateur de cette façon (dans cette commande et dans les commandes suivantes, vous devez remplacer 84.201.141.36 par l'adresse IP de votre machine virtuelle):
ssh -NR 3389:localhost:3389 home@84.201.141.36
Lorsqu'on leur demande de se connecter à un serveur inconnu, nous répondons «oui». Si alors nous ne voyons aucun texte sur la console, alors tout s'est bien passé. Configurez maintenant l'ordinateur portable. Copiez la clé privée de notre clé USB:
mkdir -Force $HOME/.ssh copy f:\id_rsa $HOME/.ssh/id_rsa
Et exécutez le client SSH:
ssh -NL 1025:localhost:3389 home@84.201.141.36
Vous pouvez maintenant exécuter le client d'accès au bureau à distance (mstsc.exe) sur l'ordinateur portable, en spécifiant localhost: 1025 comme adresse de connexion. Hourra, ça marche!
Ou fonctionne presque. Si vous arrêtez le processus SSH sur votre ordinateur personnel, il deviendra impossible de vous connecter. Nous devons faire en sorte que ce processus démarre automatiquement au démarrage du système et redémarre également lorsque la connexion est déconnectée. Cela peut être réalisé, par exemple, en créant un script PowerShell et en l'enregistrant comme obligatoire pour s'exécuter dans la stratégie de groupe au démarrage de l'ordinateur. Il vous suffit de considérer qu'il sera lancé au nom du compte système, ce qui signifie que vous devez vous assurer que notre clé SSH est disponible pour le compte système.
Passons à la clé en premier. Exécutez PowerShell en tant qu'administrateur et exécutez les commandes suivantes:
copy $HOME/.ssh/id_rsa "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" icacls "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" /reset
Dans le même temps, dans la même fenêtre PowerShell, activez l'exécution du script:
Set-ExecutionPolicy RemoteSigned
Créez maintenant le script réel. Ouvrons notre éditeur de texte préféré (le Bloc-notes convient également) et écrivons ce script (n'oubliez pas de remplacer l'adresse IP du serveur SSH par celle émise par Yandex):
while (1) { & $(get-command ssh |select -expandproperty Path) ` -i "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" ` -o StrictHostKeyChecking=accept-new -o ExitOnForwardFailure=yes ` -NR 3389:localhost:3389 home@84.201.141.36 Start-Sleep -Seconds 15 }
Enregistrez le script dans le répertoire que vous aimez. Enfin, enregistrez-le pour l'exécution automatique. Pour ce faire, lancez l'éditeur de stratégie de groupe (Win + R → gpedit.msc) et ouvrez les éléments «Configuration ordinateur» → «Configuration Windows» → «Scripts (début / fin)» → «Démarrage». Dans l'onglet "Scripts PowerShell", utilisez le bouton "Ajouter" et indiquez le chemin d'accès à notre script enregistré.
Nous ferons de même sur un ordinateur portable. Premier PowerShell en tant qu'administrateur:
copy $HOME/.ssh/id_rsa "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" icacls "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" /reset Set-ExecutionPolicy RemoteSigned
Ensuite, nous préparerons un script dans un éditeur de texte (il est légèrement différent du précédent, mais comme précédemment, nous remplaçons l'adresse IP par celle qui vous a été délivrée par Yandex):
while (1) { & $(get-command ssh |select -expandproperty Path) ` -i "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" ` -o StrictHostKeyChecking=accept-new -o ExitOnForwardFailure=yes ` -NL 1025:localhost:3389 home@84.201.141.36 Start-Sleep -Seconds 15 }
Le non-end l'enregistrera pour démarrer au démarrage en utilisant "gpedit.msc". Redémarrez l'ordinateur et l'ordinateur portable (pour vous assurer que tout démarre correctement) et le tour est joué! Maintenant, notre ordinateur personnel et notre ordinateur portable sont toujours connectés les uns aux autres (tant que notre machine virtuelle dans Yandex.Cloud est allumée et accessible).
Et alors?
Eh bien, n'est-ce pas génial? Dans n'importe quel café, dans n'importe quel aéroport, vous pouvez vous connecter à votre domicile et voir vos photos préférées avec des chats. Ou s'il vous plaît à la maison avec l'inclusion de la 5e symphonie de Beethoven à plein volume. Ou s'intéressez au succès de votre ferme minière. Ou voyez ce qui se passe à la maison avec une webcam. Mais combien d'applications ont une telle opportunité de "téléporter"? Mais notre solution présente également des inconvénients.
Tout d'abord, l'établissement d'une connexion n'est pas le processus le plus simple et le plus agréable. Et en cas de problème, le débogage est un peu plus compliqué que la configuration initiale. Bien sûr, ce problème est résolu par la persévérance et la patience, mais même la petite quantité de travail qui doit être dépensée peut soulever des doutes sur la faisabilité des efforts.
Deuxièmement, une machine virtuelle dans le cloud coûte de l'argent. Dans le cas de Yandex, le minimum sur lequel vous pouvez compter est de 480 roubles par mois. Bien sûr, ce n'est pas de l'argent exorbitant, mais toujours le leur, gagné dans la sueur d'une personne. S'il vaut la peine de regarder des photos avec des chats de cet argent, c'est à chacun de décider par lui-même, mais il se peut très bien que tous les avantages de notre solution soient barrés par son prix.
Le problème des prix peut être considérablement résolu en partageant les dépenses avec des amis et des personnes partageant les mêmes idées. Étant donné que la machine virtuelle est utilisée pour des tâches qui ne nécessitent aucune puissance de calcul notable, une dégradation des performances est extrêmement improbable. Et l'effet économique est perceptible: si vous louez une machine virtuelle avec dix personnes, tout le monde n'aura à payer que 48 roubles par mois. Certes, dans ce cas, l'harmonie peut être violée par la question de la confiance: toute personne partageant les mêmes idées a la possibilité de se connecter à un autre ordinateur via un serveur SSH. Dans le cas où tout le monde a des mots de passe forts sur ses comptes, ce n'est pas un problème. Mais, franchement, un mot de passe fort pour entrer dans votre ordinateur personnel est plus une exception qu'une règle.
À suivre
Donc, supposons que nous réunissions 10 personnes partageant les mêmes idées, que nous configurions tout comme décrit ci-dessus et que tout fonctionne pour tout le monde. Notre club d'amoureux des photos avec des chats en profite pour se rendre chez eux via Internet pour seulement 48 roubles par mois sans inscription ni SMS, tout le monde est heureux et heureux. La question est - les possibilités de notre «technologie» sont-elles limitées uniquement aux chats et est-il possible de l'utiliser pour quelque chose de plus sérieux?
Bien sûr que vous le pouvez. Si dans notre raisonnement nous remplaçons «ordinateur personnel» par «construire un serveur dans le cloud» et «ordinateur portable» par «ordinateur de travail au bureau», nous obtenons quelque chose digne du titre «système d'accès à l'infrastructure de développement». Et si nous avons une caméra IP au lieu d'un serveur de build et un poste de sécurité au lieu d'un ordinateur fonctionnel, nous obtenons un «système de surveillance vidéo».
Dans les deux cas, cependant, il sera nécessaire d'accorder plus d'attention aux problèmes de contrôle d'accès. En particulier, lors du partage d'un serveur SSH par plusieurs utilisateurs, je voudrais isoler ces utilisateurs les uns des autres. Et même avec ce partage, nous sommes obligés d'affecter chaque ressource distincte de chaque utilisateur à un port TCP distinct et de mémoriser son numéro. L'adressage par numéros peut bientôt devenir assez fastidieux, donc j'aimerais pouvoir attribuer des noms significatifs aux ressources. Mais nous verrons comment améliorer la situation dans le prochain article.
En attendant, merci de votre attention et merci de partager vos réflexions dans les commentaires.