Le manuel Secure Shell SSH

Tutoriel sur ce magnifique protocole qui a commencé ses aventures en 1997, offrant une grande variété d'outils qui se distinguent par leur sécurité, étant très étendu, je le diviserai en plusieurs entrées en essayant de couvrir la chose la plus importante à la fois au niveau du client et du serveur.

Qu'est-ce que le protocole Secure Shell ?Secure Shell ou SSH est un protocole réseau qui permet l'échange de données sur un canal sécurisé entre deux ordinateurs. SSH utilise des techniques de cryptage qui rendent illisibles les informations qui transitent par le support de communication et aucun tiers ne peut découvrir le nom d'utilisateur et le mot de passe de la connexion ou ce qui est écrit pendant toute la session. SSH utilise la cryptographie à clé publique pour authentifier l'ordinateur distant et lui permettre d'authentifier l'utilisateur si nécessaire.

SSH est généralement utilisé pour démarrer une session sur une machine distante, où vous pouvez exécuter des commandes, mais il permet également le tunneling, le transfert arbitraire des ports TCP et des connexions X11; Les transferts de fichiers peuvent également être effectués à l'aide des protocoles SFTP ou SCP associés.

Nous pouvons voir que sa grande attraction est sa caractéristique plus que suffisante pour remplacer l'ancien protocole TELNET, qui manque de cryptage des informations, compromettant les données, y compris les identifiants d'accès.

Le serveur SSH, offre par défaut le port TCP 22. Un client SSH est généralement utilisé pour établir des connexions à un serveur sshd qui accepte les connexions distantes. Les deux se trouvent généralement sur la plupart des systèmes d'exploitation modernes, notamment Mac, Linux, Solaris et OpenVMS.

La prise en charge de Windows pour sa version Server devrait être officiellement publiée cette année, tandis qu'au niveau client, elle offre une grande variété d'options mettant en évidence PuTTY par rapport aux autres.

Apprendre à utiliser Putty

OpenSSHOpenSSH (Open Secure Shell) est un ensemble d'applications qui permettent des communications cryptées sur un réseau, en utilisant le protocole SSH. Il a été créé comme une alternative libre et ouverte au protocole SSH, c'est le plus utilisé sous Linux et ce sera celui que nous utiliserons tout au long des entrées.

1. Installer Secure Shell SSH

Dans presque toutes les distributions sa version client est pré-installée alors que sa version serveur est disponible par référentiel, son installation devrait être très simple.

Debian, Ubuntu, Linux Mint et dérivés

 sudo apt-get install openssh-server

Centos, Rhel, Fedora

 sudo yum installer openssh-server

Arch-Linux

 pacman -Syu openssh

Nous vérifions qu'il fonctionne avec :

 curl localhost: 22

En cas de fonctionnement correct il doit retourner :

[couleur = # 696969] [/Couleur]

Connexion au serveur
En utilisant le client, nous pouvons nous connecter au serveur qui peut être distant même si nous avons les deux versions pour nous connecter en interne à l'aide de localhost.

Le moyen le plus simple de se connecter serait :

 ssh utilisateur @ hostaddress

En cas de connexion en interne ce serait :

 utilisateur ssh @ localhost

Nous avons une grande variété d'options lors de la connexion, je vais en expliquer quelques-unes très utiles, vous pouvez lister toutes vos options avec :

 homme ssh

Nous les montrons ici :

Options SSH homme
-CDemander la compression des données pour économiser de la bande passante ou des données en cas de connexion à un réseau mobile.

-lPrécisez l'utilisateur avec lequel nous allons nous connecter.

-ETCréez un fichier journal dans lequel l'erreur standard sera déviée.

-FNous sélectionnons un autre fichier de configuration utile pour les serveurs avec des options inhabituelles.

-gRequis pour le tunneling de port.

-jeNous choisissons le dossier que nous utiliserons pour une clé privée alternative.

-KActiver lors de l'utilisation des informations d'identification GSSAPI.

-nEn l'utilisant conjointement avec X11 de cette manière, tout le journal généré par l'application est détourné vers / dev / null.

-ou alorsRequis pour utiliser des options plus avancées telles que ServerAliveInterval 30.

-pSélectionnez un port autre que 22 pour vous connecter à l'hôte.

-vIl montre toutes les étapes nécessaires pour établir la connexion.Vous pouvez obtenir encore plus d'informations avec -vv -vvv.

-XNécessaire si nous voulons utiliser le transfert X11.

-OActive le transfert sécurisé X11.

Nous nous connecterons au serveur test.solvetic.com avec l'utilisateur jcarrillo en utilisant une clé privée différente située dans notre dossier / home / jcarrillo / keys-aws en utilisant le port 8022 de notre instance sur AWS.

 Exemple → ssh -C -i "~ / keys-aws /" -p 8022 -l jcarrillo test.solvetic.com

Comme nous pouvons le voir, c'est un outil étendu mais très complet qui mérite plus d'entrées pour pouvoir couvrir ses fonctions nécessaires pour tout administrateur système de niveau intermédiaire ou professionnel.

Passons maintenant à sa configuration au niveau client-serveur, générant des clés publiques et privées, l'utilisation de la redirection de port dans des situations réelles, la redirection du serveur X via la redirection X11, l'utilisation de scp, sftp, ssh-agent entre autres .

2. Sécuriser le serveur SSH

On continue avec OpenSSH en se concentrant sur sécuriser notre serveur SSH, pour éviter tous types d'attaques qui pourraient compromettre notre serveur. Toutes ces configurations se feront dans le fichier sshd_config situé dans /etc/ssh/ que l'on pourra modifier avec n'importe quel éditeur de texte dans mon cas utiliser vigueur:

 sudo vim / etc / ssh / sshd_config

Voyons maintenant comment le modifier.

Modifier sshd_config
À l'intérieur, nous verrons un fichier de configuration typique basé sur « Option de valeur » Si l'une des options n'est pas trouvée par défaut, il faut placer la ligne complètement, dans les autres cas il s'agira uniquement de passer de 0 à 1 de Non à Oui ou de décommenter une ligne.

Modifier le port 22
Est essentiel changer le port par défaut en un port aléatoire de nombreux scripts sont configurés pour attaquer ce port, il est recommandé de le changer dans le gamme de 1000 à 23000 s'assurer que le port n'est pas utilisé par un autre service.

Nous ne devons pas non plus utiliser des ports tels que 2222, 8022 ou 1022, ils sont tout aussi courants que 22 et de nombreux scripts sont configurés pour les attaquer.

port 2345

Si nous avons SELINUX activé, nous devons utiliser une commande supplémentaire pour autoriser l'accès de l'extérieur au nouveau port.

Semanage port -a -t ssh_port_t -p tcp 2345 #Changement du port 22 pour la sécurité

Utiliser le protocole 2 par défaut
Nous devons nous assurer que toutes nos connexions sont effectuées sous le protocole 2 car 1 présente de nombreuses vulnérabilités.

Protocole 2

Il est temps de saisir les identifiants
Section de recherche "Authentification". Vos deux premières options sont également importantes. Le premier est le nombre de secondes dont l'utilisateur distant disposera pour se connecter à votre machine. Définissez cette valeur sur quelques secondes, la connexion ne prend pas longtemps si nous connaissons le compte et le mot de passe.

De cette façon, nous évitons certains scripts qui profitent de ce temps. La valeur typique en termes de sécurité est de 30, bien qu'elle puisse être encore moins.

ConnexionGraceTime 30

Désactiver l'accès racine
Ce C'est l'option la plus importante pour être victime d'une attaque, ils ont besoin de 3 choses :

• Utilisateur
• Port
• Mot de passe

Si nous désactivons root, ils en ont déjà un car root est un utilisateur commun sur tous les systèmes. En plus de cela, cet utilisateur peut faire des ravages en ayant toutes les autorisations activées.

PermitRootLogin non

Activer l'accès contrôlé
Nous pouvons contrôler quel utilisateur peut se connecter via SSH et même placer une clause pour se connecter uniquement à partir d'une certaine adresse IP. Ceci est similaire à ce que propose AWS pour nous connecter à vos instances.

Autoriser les utilisateurs [email protected]

Il est important de n'autoriser l'accès qu'aux utilisateurs qui ont besoin d'un accès à distance et si possible de les limiter à une adresse IP connue.

Configurer le nombre de tentatives infructueuses
Si nous mettons le mot de passe mal, le serveur nous donne plusieurs tentatives pour le ressaisir, cela doit être limité ou vous pouvez être victime d'un script de force brute, nous pouvons le placer 2 ou 3 fois.

MaxAuthEssaye 2

Nombre de connexions autorisées simultanément
Cela peut varier selon la façon dont vous utilisez le serveur, mais l'idéal est de le contrôler, il suffit d'ajouter le nombre total d'utilisateurs autorisés par SSH.

MaxStartups X

Après avoir effectué toutes les modifications dans notre fichier, nous devons redémarrer notre service sshd, Cela peut varier en fonction du gestionnaire de service.

SystèmeD

 systemctl redémarrer sshd

Upstart / Sysinit

 redémarrage du service sshd

Tous ces changements ajoutent un niveau de sécurité supplémentaire mais il faut garder à l'esprit :

• Utilisez des mots de passe alphanumériques.
• Porter Authentification par clés publiques/privées quand c'est possible.
• Complétez la sécurité avec SELINUX et les pare-feu.
• Contrôlez l'accès aux utilisateurs qui doivent se connecter à distance.

Authentifier les clés publiques/privées SSH

Utilisation actuelle Clés SSH C'est une exigence indispensable, cette authentification est largement utilisée par les administrateurs pour automatiser les tâches entre différents serveurs et est même utilisée par les développeurs pour accéder aux SCM tels que GIT, GITHUB, GITLAB entre autres.

Il offre une grande sécurité et la possibilité de créer des tâches automatisées basé sur un script en tant que Arrière ou alors Répliquer les modifications à plusieurs nœuds en même temps.

Lors de l'utilisation d'une clé SSH (public et privé), ils peuvent facilement se connecter à un ou plusieurs serveurs, sans avoir à saisir de mot de passe à chaque fois. Il est possible de configurer vos clés sans mot de passe, mais ce serait imprudent, si quelqu'un obtenait votre clé, il pourrait l'utiliser. Nous verrons comment générer des clés, les distribuer et utiliser ssh-agent pour obtenir une plus grande sécurité.

Génération de clés sans phrase secrète
Tout d'abord, assurez-vous d'avoir installé OpenSSH, ce n'est pas nécessaire, le serveur uniquement le client.

On commence par Générer une clé de type DSA avec une sécurité de 1024 bits, largement suffisante même si vous pouvez aller plus loin et générer une clé de type RSA avec une limite de 4096.

 ssh-keygen -b 1024 -t dsa

Il nous demandera l'emplacement où il enregistrera les clés par défaut ~ / .ssh

 Entrez le fichier dans lequel enregistrer la clé (/home/test/.ssh/id_dsa)

Ensuite, il demandera une phrase pour le moment, nous n'en utiliserons aucune et nous la laisserons vide et il nous dira que la clé a été créée et nous reflète.

L'image sera toujours différente, elle est générée aléatoirement, alors si on va dans le dossier .ssh on doit avoir 2 fichiers

id_dsa -----> Clé privée (Ne la partagez avec personne, c'est comme votre TDC).
id_dsa.pub ----> C'est celui que l'on partage pour se connecter.

Partager la clé publique
Dans le cas où nous souhaitons partager la clé publique dans SCM ou Chef, Puppet, Jenkins, nous visualisons le fichier de clé publique, le copions et le collions là où il correspond.

 plus id_dsa.pub ssh-dss AAAAB3NzaC1kc3MAAACBAN6SEI4Qqzb23pJYRXIAtPmGJHln5hFdthFq43ef + ifR29v2IknXCFwefKK8jorSDiUEY / 1F / yp0xao mjhFQu1jNXOgF0PAZTfivRVFn6Q9FRsyXU9s + fx + + L22sV7GkCHPxAAAAFQCyF1Gdh3 xQiW3mf3y4IX654O82SLGl7Vhh5UsvG8r8d8pV6R Cap4xr / J44xDDn 0gFArHmFwAxfQAAAIEAmVYjPYAdQ9DCNWP + + + 03anWgyoZqSPPs23djyVQ756U4VitM0GiIQQ89HCdvTFFpSagnfdVpWh4 Hxo4Y5skKihnPMtB bFNbP / 2SmGdPz1AOmb7tvRrTkj5VLtXeDeB3ulowUKarwiBVVvAvxtxmozoZHOADWqrEPizxIAAACAU2DF1ZGTiJMP OhVB7mlsVhhkq53OxKKJbZqsl9hkOiSxaLUfQBNu6Ae441ekIObqolWNCBIvCO3uQYOozyzNGBhqHE7FVq 1oXguj + + + 2GAQ UGNkee96D2by S7daieIKNmFer2hO / SBxzepMrWAiIUnUsP5irmYspkjGlQxP + hxl = test @ solvetic 

Au cas où vous voudriez le partager pour accéder à un serveur, je recommande toujours d'utiliser ssh-copy-id est inclus dans OpenSSH et est très facile à utiliser :

 ssh-copy-id user @ remote-server-ip -i spécifie l'emplacement de la clé à utiliser.

Il existe d'autres moyens comme :

 ssh utilisateur @ remote-server-ip \ 'cat >> .ssh/authorized_keys2' <.ssh/id_dsa.pub

 scp ~ / .ssh / id_dsa.pub utilisateur @ remote-server-ip

Désormais, les clés sont connectées et vous n'avez plus qu'à entrer l'hôte.

 ssh -l utilisateur ip-serveur-distant

Cette fois, il ne demandera aucun mot de passe et nous pouvons utiliser des scripts sans interaction.

Générer une phrase secrète et associer avec ssh-agent
La Sécurité des clés SSH Il est basé sur notre clé privée qui fonctionne comme une carte d'accès, mais si quelqu'un vole notre clé, il pourra accéder à tous les endroits auxquels nous avons accès. Mais lors de la génération d'une phrase secrète, nous pouvons avoir un niveau supplémentaire, non seulement la clé est nécessaire, mais nous n'avons pas besoin d'introduire notre phrase.

Cette fois, nous allons créer une clé rsa avec une plus grande sécurité en configurant une phrase.

 ssh-keygen -b 4096 -t rsa -C "Clé avec phrase secrète" # -C Ajouter un commentaire. 

Étant une phrase, nous pouvons utiliser des espaces, des points et des caractères spéciaux

 exemple ---> Ceci est ma nouvelle clé avec Fr @ S3.

Nous partageons la nouvelle clé :

 scp ~ / .ssh / id_rsa.pub utilisateur @ remote-server-ip

Cette fois on a besoin de la clé et de la Passphrase mais la saisir plusieurs fois est fastidieuse mais on peut la compléter avec ssh-agent il faut la démarrer.

 ssh-agent

Nous ajoutons notre clé

 ssh-add Entrez la phrase secrète pour /home/user/.ssh/id_rsa : # Nous entrons la phrase que nous avons configurée. 

Maintenant, nous pouvons nous connecter à n'importe quel serveur qui utilise notre clé sans avoir à entrer notre mot de passe.

Je recommande cette méthode si vous êtes en dehors de l'intranet, client et serveur à différents points sur Internet, et que nous n'utiliserons pas de tâches automatisées, mais plutôt se connecter au serveur à des fins d'administration à distance, il est préférable d'indiquer un mot de passe ou très long passphrase (15 caractères ou plus, majuscules, minuscules, chiffres et symboles) à la clé publique.

De cette manière il sera pratiquement impossible de se faire pirater par cette méthode, puisque non seulement le pirate devra connaître le mot de passe mais il devra disposer d'un certificat public valide sur le serveur pour pouvoir s'authentifier. (Bien sûr en supposant que le serveur n'a jamais été compromis et qu'il est complètement à jour et avec la meilleure sécurité possible).

Avez-vous aimé et aidé ce tutoriel ?Vous pouvez récompenser l'auteur en appuyant sur ce bouton pour lui donner un point positif