SSH
Aller à la navigation
Aller à la recherche
Le wiki : Accueil - Administrateur - Bureautique - Développeur - Intégrateur - Marketing - Multimédia - Objets numériques - Jeux - We make Hack
SSH
Abandon de Telnet pour SSH
# Telnet a été créé dans les années 80. # Telnet est un protocole qui permet d'accéder à distance à une machine, basique, mais dangereux. # La connexion n'est pas sécurisée, les données sont transférées en clair sur le réseau. Il n'y a aucun chiffrement. # Il sert à échanger des messages standards d'une machine à une autre. Il est donc conseillé de ne pas utiliser Telnet mais uniquement SSH.
# Le client Telnet se trouve dans le paquet telnet. Ce paquet est installé par défaut. # Le serveur Telnet se trouve dans le paquet telnetd. Il n'y a aucune configuration à faire.
# Se connecter à un serveur Telnet puis indiquer votre login et votre mot de passe : telnet nom_DNS_du_serveur_telnet
# Telnet, c'est comme SSH, mais en moins bien !
Usage des clés SSH
SSH (Secured SHell) est un protocole sécurisé avec des clés privées et des clés publiques pour communiquer entre deux ordinateurs. Il est utilisé en général pour la gestion des serveurs sous GNU/Linux.
Quand un administrateur système se fait pirater son serveur, c'est souvent qu'il a laissé le port 22 SSH par défaut et accessible sans désactiver root et l'identification par mot de passe. Quand le mot de passe est un mot du dictionnaire, les attaques Brute Force ont de grandes chances d'aboutir. Le serveur est alors compromis. Utiliser un mot de passe fort de plus de 8 caractères, un mélange de lettres minuscules, majuscules, chiffres et caractères de ponctuation. De préférence, utiliser uniquement une paire de clés privée et publique avec passphrase.
Une clé publique => A exporter sur chaque machine ou l'on veut se connecter. Une clé privée => Permet de prouver son identité aux serveurs SSH. Une passphrase => Permet de sécuriser la clé privée.
Installer le client SSH OpenSSH
# Installer le client OpenSSH permet aux utilisateurs d'accéder aux systèmes à distance, en rentrant leur login et leur mot de passe, ou, avec un mécanisme de clefs. # OpenSSH est la version libre du client et du serveur SSH.
# Installer le clientopenssh-clientpour pouvoir se connecter à un serveur SSH :sudo apt install openssh-client
# Il n'est pas nécessaire d'installer le serveur OpenSSH sur la machine qui servira de client. sudo apt-get remove openssh-server
# Faire les mises à jour des paquets pour conserver un système sécurisé : apt update apt upgrade
# Consulter le manuel pour SSH : man ssh man ssh_config
Créer une paire de clé SSH
Générer une clé RSA ou ED25519
# L'utilisation du chiffrement DSA est déprécié depuis OpenSSH 7 !
# Générer une clé SSH avec cette commande lancée par votre utilisateur ne nécessite pas l'utilisation de sudo ou de root. # Si aucune option n'est spécifiée, une clé RSA de 2048 bits sera créée. # Il est fortement déconseillé d'utiliser des clés inférieur à 1024. ssh-keygen -b 4096 ssh-keygen -t rsa -b 4096 -C "Un commentaire sur la clé." ssh-keygen -t rsa -b 4096 -f ~/.ssh/web-admin -C "La clé RSA pour l'administrateur web."
# Question : # Si je crypte une clé RSA en 4096 bits, une fois l'empreinte stockée dans know_hosts, elle m'indique une empreinte ECDSA. # Si j'affiche les randomart images depuis le fichier know_hosts, en haut de la randomart, je lis ECDSA également. # Pourquoi ?
############################################################################### # Privilégier le chiffrement ED25519 lors de la création d'une nouvelle clé ! # ############################################################################### # Les clés ECC (ECDSA et ED25519) sont plus petites mais aussi sécurisées que leurs ancêtres, ce qui nécessite moins de ressources pour crypter et déchiffrer. # L'algorithme utilisé par ECDSA est très critiqué par certains spécialistes de la sécurité et c'est pourquoi ED25519 a été créé. # L'inconvénient du format ED25519 est qu'il n'est pas encore compatible avec tous les OS, contrairement aux clés RSA. # L'ANSI et Aeris conseillent de sécuriser SSH avec une authentification par clé ED25519 lorsque c'est possible. # Les clés ECC étant plus légères, elles permettent une meilleure performance. # Si aucune option n'est spécifiée, une clé ED25519 de 256 bits sera créée. ssh-keygen -t ed25519 -N votre-phrase-secrète ssh-keygen -t ed25519 -C "Commentaire" ssh-keygen -t ed25519 -N votre-phrase-secrète -C "Commentaire" -b 384 -f "/emplacement/dossier-cle/nom-de-la-cle-sans-extension-par-defaut"
# Ce tableau présente l'équivalence entre la taille des clés RSA (bits) et la taille des clés ECC (bits) : 1024 bits RSA = 160 bits ECC 2048 bits RSA = 224 bits ECC 3072 bits RSA = 256 bits ECC 7680 bits RSA = 384 bits ECC 15360 bits RSA = 521 bits ECC
Option "-N" pour définir la phrase secrète (Passphrase). Option "-t" pour définir le type de clé, RSA, DSA, ed25519 ... Option "-b" pour définir la longueur de la clé en bits. Option "-f" pour définir ou sera créé la clé privée et son nom. Option "-C" pour ajouter un commentaire, très utile pour retrouver une clé parmi d'autre. Lire le commentaire avec la commande less et le chemin du fichier. # Par défaut si aucun commentaire n'est ajouté, le nom du compte et le nom de la machine sont ajoutés sous la forme de "nom@machine". Option "-i .ssh/web-admin.private " pour indiquer avec quelle clé privée se connecter au serveur SSH.
# Lors de la création de la paire de clés SSH, répondre aux questions suivantes : Generating public/private rsa key pair. # Changer éventuellement la localisation de la clé SSH, les dossiers doivent exister. Enter file in which to save the key (/home/zencool/.ssh/id_rsa): /home/zencool/.ssh/id_rsa/DropletDigitalOcean # Ajouter une passe phrase facultative. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/zencool/.ssh/id_rsa/DropletDigitalOcean. Your public key has been saved in /home/zencool/.ssh/id_rsa/DropletDigitalOcean.pub. The key fingerprint is: SHA256:TzTV6l6VVcGw59IpwB7WouNHqInGO4EO6XlkolNzcQA zencool@debian The key's randomart image is: +---[RSA 4096]----+ | E. .oo.+| | . ... o..| | . o* + .o| | . . .=.= +.o| | . .o S+.+ o = | | +o+o.. +oo . + | |o.Bo +.o ..o . | |oo o... . . | | .. .. | +----[SHA256]-----+
# Consulter le manuel : man ssh-keygen
Randomart image
# L'image générée permet un rendu visuel de notre clé SSH. # Cette commande devrait être utilisée sur la clé publique mais peut être utilisée sur la clé privée : ssh-keygen -lvf /home/utilisateur/.ssh/dossier/id_rsa_private
# Les randomart images des empreintes de clés du fichier known_hosts de notre machine locale peuvent être affichées avec la commande suivante : ssh-keygen -lvf ~/.ssh/known_hosts
# Comparer la randomart image à chaque connexion : # On ajoute "-o VisualHostKey=yes" à la commande de connexion SSH, et, si cette image est différente, c'est qu'on est probablement victime d'une attaque de l'homme du milieu.
Afficher la randomart image à chaque connexion
# Ajouter le paramètre "-o VisualHostKey=yes" à la commande de connexion pour afficher le randomart image. # Modifier la configuration du client SSH de la machine locale pour ne pas avoir à ajouter le paramètre "-o VisualHostKey=yes" à chaque tentative de connexion.
# Ajouter le paramètre VisualHostKey yes dans la configuration globale du client SSH :
sudo nano /etc/ssh/ssh_config
VisualHostKey yes
# Ajouter le paramètre VisualHostKey=yes dans la configuration personnalisée de l'utilisateur de la machine locale :
sudo nano .ssh/config
# Pour tous les hôtes :
Host *
VisualHostKey=yes
# Lors de la toute première connexion à un serveur, le serveur envoie sa propre clé publique et demande de l'accepter. # Confirmer la connexion avec "yes". La clé publique au format ECDSA par défaut est ajoutée à know_hosts.
############################################################# # Attention ! Ce paramètre s'applique au client uniquement. # #############################################################
# Dans le cas de la configuration d'un serveur SSH, il ne redémarrera pas si la directive "VisualHostKey yes" a été ajoutée. # VisualHostKey yes
Changer la passphrase qui protège votre clef privée
ssh-keygen -p
Utiliser une keychain à la place d'une passphrase
# Utiliser une keychain est alternative à la passphrase qui n'est pas obligatoire puisque utiliser une passphrase est totalement cohérent en ce qui concerne la sécurité de l'accès au serveur SSH ! Source : https://www.cyberciti.biz/faq/ssh-passwordless-login-with-keychain-for-scripts/
Protéger la connexion avec une authentification à deux facteurs
Renforcer la sécurité de SSH avec 2FA. L'authentification multifactorielle peut être activée avec OATH Toolkit ou DuoSecurity.
Source : https://www.cyberciti.biz/open-source/howto-protect-linux-ssh-login-with-google-authenticator/ Source : https://www.nongnu.org/oath-toolkit/ Source : https://duo.com/
Droits CHMOD a appliquer aux clés SSH
# Par défaut les fichiers créés localement depuis l'interface graphique, avec un clique droit créer un fichier, ont les droits CHMOD à 664. # Ajouter des contenus de clés par copier coller dans des fichiers créés manuellement ne va donc pas respecter le contexte de sécurité recommandé. # Suite à une identification en simple utilisateur, un message d'alerte rappel qu'il est indispensable de donner des droits moindre à la clé privée, sinon, la clé privée sera ignorée.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0664 for '/home/USER/.ssh/vps/id_rsa_private' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored.
# Passer les droits du dossier .ssh et des sous dossiers à 700 : cd ~/ sudo chmod -R 700 .ssh/ sudo chown -R utilisateur:utilisateur .ssh/
# Passer les droits des fichiers à 644 et les clés privées à 600 :
cd ~/.ssh/
sudo find . -type f -exec chmod 644 {} \;
sudo chmod 600 cle.private
sudo chmod 600 authorized_keys
# Par défaut, les répertoires /home et /home/user ont un CHMOD de 755. # Faut t'il attribuer des droits différents que 755 sur le dossier /home/user et /home ?
Correct file permissions for ssh keys and config : https://gist.github.com/grenade/6318301
Lire le contenu de vos clés
Avec un logiciel de traitement de texte
# Lire et afficher la clé publique ou privée avec un bloc notes. cat /home/user/.ssh/id_rsa.pub cat /home/user/.ssh/id_rsa
Avec cat
# Lire et afficher la clé publique avec cat. cat /home/zencool/.ssh/id_rsa/DropletDigitalOcean.pub https://pastebin.com/xVANZLbZ
# Lire et afficher la clé privée avec cat. cat /home/zencool/.ssh/id_rsa/DropletDigitalOcean https://pastebin.com/G9MZCEfs
Avec ssh-keygen -e
# Lire et afficher la clé publique et son commentaire. # Se positionner dans le dossier qui contient la clé publique ou privée. # Lancer la commande ssh-keygen avec le paramètre -e. # Le nom de la clé publique ou privée a lire est demandé à la saisie. # La clé publique uniquement sera affichée avec son commentaire. ssh-keygen -e
Régénérer les clés SSH qui identifient le serveur
# Les clés d'hôte du serveur SSHD sont stockées dans le dossier de configurations de OpenSSH. # Pour réinitialiser les empreintes de clés, supprimer les fichiers suivants : sudo rm -v /etc/ssh/ssh_host_*
# Exemple de l'affichage résultant : removed '/etc/ssh/ssh_host_dsa_key' removed '/etc/ssh/ssh_host_dsa_key.pub' removed '/etc/ssh/ssh_host_ecdsa_key' removed '/etc/ssh/ssh_host_ecdsa_key.pub' removed '/etc/ssh/ssh_host_ed25519_key' removed '/etc/ssh/ssh_host_ed25519_key.pub' removed '/etc/ssh/ssh_host_rsa_key' removed '/etc/ssh/ssh_host_rsa_key.pub'
# Recréer de nouvelles clés sur le serveur SSHD : sudo dpkg-reconfigure openssh-server
# Redémarrer le serveur : sudo systemctl restart ssh
# Mettre à jour tous les fichiers known_hosts du ou des clients ssh. # Retirer l'ancienne clé : ssh-keygen -R 139.99.173.195 # Le paramètre -f permet de spécifier l'emplacement du fichier des hôtes connus : ssh-keygen -f "/home/utilisateur/.ssh/known_hosts" -R "Adresse IP du serveur"
# Se reconnecter et accepter la nouvelle empreinte de clé : ssh debian@139.99.173.195 -i /home/utilisateur/.ssh/serveur1/private_key_vps -o VisualHostKey=yes
# Cette réinitialisation des clés aura également pour effet de mettre à jour la randomart image.
Régénérer une clé publique à partir d'une clé privée
ssh-keygen -y -f cle.private > cle.pub
# Le commentaire qui avait pu être ajouté lors de la création initiale ne sera plus présent. # Ajouter manuellement un commentaire à la fin de la clé publique.
Exporter une clé SSH publique depuis une machine cliente vers un serveur distant
# Exporter une clé SSH publique créée depuis une machine cliente vers le fichier "/home/utilisateur/.ssh/authorized_keys" d'un utilisateur existant sur un serveur distant.
Configurer le fichier authorized_keys
Ajouter la copie de la clé publique dans le fichier authorized_keys
Ajouter la copie de la clé publique dans le fichier authorized_keys avec ssh-copy-id
# L'idéal est de créer la paire de clé privée et publique SSH depuis la machine locale et d'exporter l'empreinte de la clé avec ssh-copy-id vers le serveur distant.
Générer la paire de clés SSH privée et publique sur la machine locale
ssh-keygen -b 4096 # Ou : ssh-keygen -t rsa -b 4096 -C "Ceci est un commentaire pour identifier la clé SSH de notre utilisateur."
Le répertoire .ssh/ doit exister sur le serveur distant
# Le créer manuellement si il n'existe pas : ssh user@serveur cd ~/ mkdir .ssh exit
Installer le paquet ssh-copy-id sur la machine locale
sudo apt install ssh-copy-id.
Ajouter une clé publique SSH dans le fichier authorized_keys d'un utilisateur créé sur le serveur distant
# L'utilisateur du serveur distant pour lequel on souhaite ajouter une clé publique SSH dans son fichier authorized_keys doit être autorisé à accéder au serveur dans la configuration du serveur SSH. # Ne pas limiter l'authentification à une authentification par clé SSH sur le serveur, sinon, on ne pourra pas ajouter la clé SSH dans le fichier authorized_keys de l'utilisateur avec ssh-copy-id.
# Utiliser la commande ssh-copy-id :
ssh-copy-id -i /path/de/la/cle.pub utilisateur@serveur
ssh-copy-id -i /path/de/la/cle.pub utilisateur@serveur -p 11033
# La commande ssh-copy-id permet d'ajouter la clé publique sur le serveur distant : ssh-copy-id -i /home/user/.ssh/id_rsa.pub utilisateur@xxx.xxx.xxx.xxx # Avec une séquence de frappe ( Non testé ) : for x in 2222 4444 8888; do nmap -Pn --host_timeout 201 --max-retries 0 -p $x xxx.xxx.xxx.xxx && sleep 1; done && ssh-copy-id -i /home/user/.ssh/id-rsa.pub "-p 22 utilisateur@xxx.xxx.xxx.xxx -o VisualHostKey=yes"
# Le mot de passe de l'utilisateur du serveur distant est demandé.
# La clé est ensuite automatiquement ajoutée à ~/.ssh/authorized_keys sur le serveur.
# Se reconnecter au serveur distant pour vérifier que la clé publique SSH ait bien été ajoutée dans le fichier authorized_keys de l'utilisateur : ssh user@serveur cd .ssh/ ~/.ssh$ ls -la authorized_keys
# Facultatif : # Autre possibilité pour tester la connexion, se connecter directement en spécifiant le chemin de la clé à utiliser qui utilise une passe phrase. # Si la passe phrase est demandée et que la connexion est établie avec le serveur, sans erreur, c'est que la clé publique a bien été ajoutée sur le serveur distant. ssh user@serveur -i /home/user/.ssh/dossier/id_rsa.private -o VisualHostKey=yes
Ajouter l'empreinte de la clé publique au fichier authorized_keys avec cat
Ajouter la clé publique dans le fichier authorized_keys avec cat. L'authentification au serveur ne doit pas être limitée à une authentification par clé SSH, sinon, on ne pourra pas ajouter la clé RSA du nouvel utilisateur dans le fichier authorized_keys avec ssh-copy-id. L'utilisateur du serveur distant pour lequel on souhaite ajouter la clé publique SSH dans le fichier authorized_keys doit être, si nécessaire, autorisé à accéder au serveur depuis la configuration du serveur SSH.
# Envoyer votre clé sur un serveur SSH avec cat : cat ~/.ssh/id_rsa.pub | ssh utilisateur@ip_du_serveur "cat - >> ~/.ssh/authorized_keys"
# Envoyer votre clé sur un serveur SSH avec cat, en changeant de port : ssh -p22 utilisateur@serveur 'cat >> ~/.ssh/authorized_keys' < ~/.ssh/id_rsa_utilisateur.pub
# Avec une séquence de frappe ( Non testé ) : for x in 1111 2222 3333; do nmap -Pn --host_timeout 201 --max-retries 0 -p $x serveur && sleep 1; done && ssh -p3333 utilisateur@serveur 'cat >> ~/.ssh/authorized_keys' < ~/.ssh/id_rsa_utilisateur.pub
# Vérifier les chmod : # Le dossier .ssh doit être en 700 et appartenir au simple utilisateur local. # Le fichier authorized_keys doit être en 600 et appartenir au simple utilisateur local.
Ajouter l'empreinte de la clé publique au fichier authorized_keys avec scp
# Ajouter la clé SSH publique d'un utilisateur client vers l'utilisateur créé à distance sur le serveur. # Autre méthode rapide en ligne de commande pour envoyer votre clé sur un serveur ssh : scp ~/.ssh/id_rsa.pub user@server1.cyberciti.biz:~/.ssh/authorized_keys
# Vérifier les chmod : Le dossier .ssh doit être en 700 et appartenir au simple utilisateur local. Le fichier authorized_keys doit être en 600 et appartenir au simple utilisateur local.
Ajouter l'empreinte de la clé publique au fichier authorized_keys par copier coller
# Ajouter la clé SSH publique d'un utilisateur client vers l'utilisateur créé à distance sur le serveur. # Lire la clé locale et la copier. cat .ssh/emplacement/id_rsa.pub
# Dans le cas de l'utilisateur root locale connecté à l'utilisateur root distant. # Ajouter la clé publique du client root au compte de l'utilisateur sudoers distant. # Sur la console distante, passer de root à toto. La connexion SSH de root à root reste établie, de root à toto. ## La connexion SSH reste vraiment établie ?. su - toto mkdir .ssh chmod 700 .ssh chown -R toto:toto .ssh cd .ssh nano authorized_keys # Ajouter la clé au fichier .ssh/authorized_keys qui conserve la liste des clés autorisées à se connecter. # Coller la clé publique qui provient de la machine cliente locale. # Ici, nous sommes sur la machine serveur distante. chmod 600 authorized_keys exit
Vous pouvez maintenant vous connecter SSH en tant que nouvel utilisateur toto en utilisant la clé privée comme authentification. L'utilisateur toto pourra travailler avec les privilèges de root grâce à sudo.
Pour l'utilisateur root par défaut, aller dans le dossier : cd /root/.ssh
Options de configuration du fichier authorized_keys
# Certaines options de configurations peuvent être ajoutées au début de la partie publique de la clé présente dans le fichier ~/.ssh/authorized_keys d'un utilisateur.
# Exemple du début du fichier authorized_keys pour une clé RSA sans aucune option de configuration : cat ~/.ssh/authorized_keys ssh-rsa iMEyIOc6TAw3+w/RBkHXbabKYgI1...
# Sécuriser la connexion par clé SSH en limitant l'utilisation d'une clé RSA spécifique renseignée dans le fichier "~/.ssh/authorized_keys" à une adresse IP. # Cela permet de réduire les risques d'utilisation de cette clé depuis la machine d'un utilisateur non autorisé en cas de perte ou de vol. # Exemple du début du fichier authorized_keys pour une clé RSA avec association d'une limitation par adresse IP : cat ~/.ssh/authorized_keys from="192.168.1.1" ssh-rsa iMEyIOc6TAw3+w/RBkHXbabKYgI1...
# Noter que l'utilisateur pourra supprimer cette restriction puisqu'il est en mesure de modifier son propre fichier authorized_keys. # Cela ne limite donc pas vraiment un utilisateur aux connexions à partir d'une seule adresse IP. # Cela permet surtout de limiter les connexions à distance à son compte à une seule adresse IP. # Cela peut être une différence à prendre en considération. # Pour empêcher l'utilisateur de supprimer la restriction, le fichier authorized_keys pourrait être donné à l'utilisateur root.
# Différentes options peuvent être cumulée, en séparant chaque option par une virgule.
# Exemple du début du fichier authorized_keys pour une clé RSA avec association d'une limitation par adresse IP et / ou d'un nom d'hôte : cat ~/.ssh/authorized_keys from="xx.xx.xx.xx,ma_machine.mon_domaine.com" ssh-rsa iMEyIOc6TAw3+w/RBkHXbabKYgI1...
# Mon nom d'hôte machine "serveur" ou "serveur.localdomain" ou l'adresse IP du réseau "192.168..." ne semblent pas fonctionner. # Mon adresse IP fournit par la box ou le hostname ci-dessous permet l'autorisation. # Le problème c'est que je suppose que l'adresse IP comme le hostname peuvent être amenés à changer, ce qui nous laisserait au dehors du serveur. from="laubervilliers-xxx-x-xx-xx.yxx-xx.abo.wanadoo.fr"
################################################ # On peut configurer plusieurs autres options. # ################################################
# Refuser les shells de connexion interactifs : # Empêche l'allocation de tty (Une demande d'allocation d'un pty échouera.) no-pty
# Exécuter une commande particulière : command="/usr/local/bin/my-prog" ssh-rsa iMEyIOc6TAw3+w/RBkHXbabKYgI1...
# Combiner le refus de toutes les commandes et autorise une commande spécifique comme une sauvegarde à distance rsync et ssh pour garantir que l'utilisateur ne pourra rien exécuter d'autre. restrict,command="/usr/local/bin/my-prog" ssh-rsa iMEyIOc6TAw3+w/RBkHXbabKYgI1...
# Toutes les options !La documentation est disponible depuis le manuel de sshd dans la section "AUTHORIZED_KEYS FILE FORMAT" : https://man.openbsd.org/OpenBSD-current/man8/sshd.8#AUTHORIZED_KEYS_FILE_FORMAT cert-authority command="command" environment="NAME=value" expiry-time="timespec" from="pattern-list" # Refuser l'utilisation de la redirection d'agent : no-agent-forwarding # Refuser l'utilisation de redirection de port : no-port-forwarding no-pty no-user-rc # Refuser l'utilisation de X11 : no-X11-forwarding permitlisten="[host]:port" permitopen="host:port" principals="principals" restrict tunnel="n"
AWS
Importer la clé SSH publique depuis l'espace client ou depuis l'interface du serveur ?
DigitalOcéan
Importer la clé SSH publique lors de la création du Droplet.
# Se connecter. ssh root@ip_serveur -i /home/user/.ssh/dossier/cle_privee # Saisir la passe phrase si créée pour le Droplet. Enter passphrase for key '/home/zencool/.ssh/digitalocean/id_rsa': # A la première connexion, le mot de passe root est à changer. # Demander le rappel du mot de passe root initial par mail. You are required to change your password immediately (root enforced)
Github
Importer la clé SSH publique depuis l'espace client.
OVH
Importer la clé SSH publique dans l'espace client
Aller dans l'espace client (Votre nom, mon compte.) Cliquer sur "Mes clés SSH" Cliquer sur Ajouter une clé Cliquer sur Une clé SSH Nommer la clé Copier la clé récupérée précédemment dans le cadre "Saisissez votre clé" Cliquer sur Ajouter
Si vous vous connectez pour la première fois à un VPS, OVH recommande de consulter les guides suivants :
Installer un VPS
Choisir par exemple la version de Debian Jessie depuis le panel OVH. Importer automatiquement la clé qui a été ajoutée dans l'espace client.
Se connecter au serveur avec SSH. ssh root@37.59.111.111 -i /home/USER_LOCAL/.ssh/id_rsa.pub
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed.
# Supprimer l'identification par défaut lors de la première connexion. ssh-keygen -f "/home/utilisateur/.ssh/known_hosts" -R 37.59.111.111
# Host 37.59.111.111 found: line 4 /home/utilisateur/.ssh/known_hosts updated. Original contents retained as /home/utilisateur/.ssh/known_hosts.old Relancer la connexion.
The authenticity of host '37.59.111.111 (37.59.111.111)' can't be established. ECDSA key fingerprint is SHA256:5es4CpWVzo...Smcg7zuqlYUvk. Are you sure you want to continue connecting (yes/no)? yes : Permanently added '37.59.111.111' (ECDSA) to the list of known hosts. Enter passphrase for key '/home/USER_LOCAL/.ssh/id_rsa': .......
apt update apt upgrade
Installer sudo nano
# Ajouter un utilisateur sur le serveur distant : adduser demo Ajouter au groupe sudo : usermod -a -G sudo demo
# Vérifier que tout va bien jusque la, que l'on puisse se reconnecter : exit ssh root@37.59.111.111 -i /home/USER_LOCAL/.ssh/id_rsa Enter passphrase for key '/home/USER_LOCAL/.ssh/id_rsa': OK, le root est accessible avec la passephrase, sans erreur.
# Tester le nouvel utilisateur demo. ssh demo@37.59.111.111 -i /home/USER_LOCAL/.ssh/id_rsa demo@37.59.111.111's password: La passephrase n'est pas encore demandée, accès par mot de passe.
# Copier les fichiers de root vers demo : mkdir /home/demo/.ssh sudo bash cd /root/.ssh cp * /home/demo/.ssh/ exit cd /home/demo/.ssh/ ls # La copie de authorized_keys a été effectuée. exit
# Tester la connexion avec l'utilisateur secondaire sudoers : ssh demo@37.59.111.111 -i /home/zencool/.ssh/id_rsa Enter passphrase for key '/home/zencool/.ssh/id_rsa': # La passephrase est bien demandée.
L'utilisateur root est toujours autorisé. La connexion par mot de passe est toujours autorisée. Désactiver maintenant l'utilisateur root et la connexion par mot de passe.
Importer la clé SSH publique pour le support
Importer la clé SSH publique pour le support OVH. Source : https://docs.ovh.com/fr/fr/cloud/dedicated/ovh-ssh-key/
Importer la clé SSH publique en mode rescue pour un serveur distant
VPS Activer le mode Rescue sur un VPS : https://docs.ovh.com/fr/vps/mode-rescue-vps/
Dédié Mode Rescue : https://docs.ovh.com/fr/dedicated/ovh-rescue/
Vérifier si le port 22 SSH est ouvert sur sa machine
# Tester la connexion locale avec SSH. ssh localhost
# Exemple avec l'utilisateur Git zer00cool créé pour utiliser Git en local et autorisé dans le fichier de configuration de SSH. # Le mot de passe à utiliser, deux fois, est le mot de passe de l'utilisateur zer00cool. su zer00cool Mot de passe : zer00cool@machine /home/zencool $ ssh localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. ECDSA key fingerprint is SHA256:QAfc3awmrnSUyMWsJ6PIL48dJmXUVsX26D4BSaZumSs. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. zer00cool@localhost's password: Welcome to Linux Mint 18 Sarah (GNU/Linux 4.8.0-59-generic x86_64) * Documentation: https://www.linuxmint.com 0 paquet peut être mis à jour. 0 mise à jour de sécurité. Last login: Sat Dec 23 19:22:54 2017 from 127.0.0.1
# La connexion SSH sera refusée si l'utilisateur n'est pas autorisé dans le fichier de configuration de SSH. ssh localhost ssh: connect to host localhost port 22: Connection refused
Ouvrir le port 22 SSH sur sa box
De préférence, ne pas ouvrir le port 22 SSH par défaut mais choisir un autre port comme le port 11033.
Source : craym.eu/tutoriels/utilitaires/ouvrir_les_ports_de_sa_box.html
Ouvrir iptables avec une règle pour le port 22
iptables -A INPUT -p tcp -d 0/0 -s 0/0 --dport 22 -j ACCEPT
Se connecter à une adresse avec SSH
Avec une clé SSH publique
La paire de clés SSH a été générée localement et la clé SSH publique a été partagée sur la machine distante.
# Avec le même identifiant utilisé sur le client et le serveur. ssh ip_du_serveur
# Connexion standard. ssh utilisateur@ip_du_serveur
# Connexion avec passphrase. ssh utilisateur@ip_du_serveur # Entrer la passphrase.
# Utiliser le mode verbose pour connaître la configuration chargée. ssh -v utilisateur@ip_du_serveur
# Connexion avec la clé privée en paramètre. ssh utilisateur@ip_du_serveur -i /home/utilisateur/.ssh/dossier/cle_privee
# Connexion avec un numéro de port spécifique. ssh -l utilisateur -p NumeroDePort ip_du_serveur
Avec une clé pem
Ici, la clé pem est créée depuis AWS pour utiliser Amazon Lightsail. Une fois la clé .pem chargée sur la machine locale, la connexion peut se faire de la façon suivante :
# Changer les droits sur la clé. chmod 400 /path/my-key-pair.pem # Lancer la connexion. ssh -i AWS750heures.pem admin@35.176.60.197 # Accepter la connexion. The authenticity of host '35.176.60.197 (35.176.60.197)' can't be established. ECDSA key fingerprint is SHA256:KIQFYJt2fzdoM+jibnlR5S2THIVxFBOyO4lrg7Uzi4g. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '35.176.60.197' (ECDSA) to the list of known hosts.
Que faire si le serveur distant ne répond pas
Vérifier l'adresse IP du serveur distant. Vérifiez que le port 22 n'est pas bloqué par iptables. En cas de doutes, supprimer toutes les règles iptables. Donner le chemin de la clé publique ou privée lors de la connexion. Si le serveur tourne sur un autre port, préciser le numéro du port : ssh utilisateur@ip_du_serveur -p 11033
Si SSH ne fonctionne vraiment plus, redémarrer Telnet ou Webmin.
Votre manager de votre VPS ou serveur dédié n'affiche plus le voyant du SSH
Suite au changement du port 22 SSH par défaut sur mon VPS OVH, le manager n'arrive plus à savoir si SSH est activé. Normal, il recherche un service sur le port 22. Le voyant est donc au rouge.
Arrêter Démarrer Redémarrer le service SSH
# Arrêter le service SSH. /etc/init.d/ssh stop # Démarrer le service SSH. /etc/init.d/ssh start # Redémarrer le service SSH pour prendre en compte les modifications du fichier de configuration. /etc/init.d/ssh restart # Recharger le fichier de configuration. /etc/init.d/ssh reload
Sécuriser SSH
Surveiller les logs de connexions
Surveiller les connexions en lisant régulièrement le fichier de log /var/log/auth.log
Modifier la configuration du client SSH depuis le fichier /etc/ssh/ssh_config
Le fichier "/etc/ssh/ssh_config" permet de configurer les paramètres global de la machine pour toutes les connexions vers des serveurs "ssh".
sudo nano /etc/ssh/ssh_config
Il est possible de configurer des paramètres de configuration dans chaque compte. Éditer pour cela le fichier/home/user/.ssh/configdans le répertoire utilisateur. Si le fichier "config" n'existe pas, le créer puis l'éditer avec les mêmes options que pour le fichier de/etc/ssh/ssh_config.sudo nano /home/user/.ssh/config
Modifier la configuration d'un utilisateur local depuis le fichier .ssh/config
# Éditer le fichier de configuration de l'utilisateur courant sur la machine locale : sudo nano ~/.ssh/config
# Forcer l'affichage de la randomart image :
Host *
VisualHostKey=yes
#[serveur1]
Host raccourci1
HostName xxx.xxx.xxx.xxx
User user1
IdentityFile ~/.ssh/dossier1/id_rsa_user1.private
# Se connecter rapidement : ssh user1@xxx.xxx.xxx.xxx
# Se connecter avec la commande complète : ssh user1@xxx.xxx.xxx.xxx -i /home/utilisateur-local/.ssh/dossier1/id_rsa_user1.private -o VisualHostKey=yes
#[serveur2]
Host raccourci2
HostName yyy.yyy.yyy.yyy
User user2
IdentityFile ~/.ssh/dossier2/id_rsa_user2.private
# Se connecter rapidement : ssh user2@yyy.yyy.yyy.yyy
# Se connecter avec la commande complète : ssh user2@yyy.yyy.yyy.yyy -i /home/utilisateur-local/.ssh/dossier2/id_rsa_user2.private -o VisualHostKey=yes
# Se connecter avec la commande complète + Séquence de port Knocking
# for x in 1234 5678 9999; do nmap -Pn --host_timeout 201 --max-retries 0 -p $x yyy.yyy.yyy.yyy && sleep 1; done && ssh user2@yyy.yyy.yyy.yyy -i /home/utilisateur-local/.ssh/dossier2/id_rsa_user2.private -o VisualHostKey=yes
# Lancer la connexion ssh : ssh raccourci1
# Je n'ai pas encore pu trouver plus facile pour lancer une séquence de frappes. # Les options renseignées plus haut permettent malgré tout de réduire la taille du script ainsi, depuis le terminal : # for x in 1234 5678 9999; do nmap -Pn --host_timeout 201 --max-retries 0 -p $x yyy.yyy.yyy.yyy && sleep 1; done && ssh user2@yyy.yyy.yyy.yyy
Options dépréciées
# La directive "RSAAuthentication yes" qui permet l'authentification avec clés RSA est dépréciée depuis Debian Stretch. # Utiliser le Protocole 2 devrait permettre l'utilisation des clés RSA (Surement pour celles suffisamment fortes de plus de 1024 bits, et, de préférence, de plus de 2048 voir même 4096 bits actuellement. # Après le redémarrage du serveur SSH, la connexion fonctionnera toujours même si l'option RSAAuthentication est commentée. # Si la préférence n'est pas mentionnée, c'est cette option qui est utilisée par défaut : RSAAuthentication yes # Laisser cette option commentée car elle est dépréciée et correspond au protocole 1 de SSH.
# Pour supprimer cette ligne dans le fichier de configuration : sed -i '/RSAAuthentication/d' /etc/ssh/sshd_config
# Les lignes suivantes sont également dépréciées : sed -i '/KeyRegenerationInterval/d' /etc/ssh/sshd_config sed -i '/ServerKeyBits/d' /etc/ssh/sshd_config sed -i '/RhostsRSAAuthentication/d' /etc/ssh/sshd_config sed -i '/UsePrivilegeSeparation/d' /etc/ssh/sshd_config
Limiter les tentatives de connexion
# Limiter a un nombre maximum les tentatives de connexions SSH non authentifiée, pour chaque adresse IP, avant de bloquer l'adresse IP. # Le 3 correspond au nombre de tentatives maximum autorisées avant d'être rejetée. # Le 50 correspond au pourcentage de chance que la nouvelle tentative soit rejetée. # Le 5 correspond à la probabilité que les connexions augmente linéairement jusqu'à 100% pour 5 connexions, puis, de voir toutes les demandes de connexion être bloquées. MaxStartups 3:50:5
# Limiter le nombre de tentatives de connexion : MaxAuthTries 3
# Limiter le nombre de sessions simultanées : MaxSessions 3
Changer le port de connexion 22 par défaut pour SSH
# Numéro de port sur lequel SSH se connecte à l'hôte distant. Port 22
Changer le port par défaut du serveur SSH permet de réduire les attaques provenant de robots qui scannent en permanence les ports pour y trouver des failles. Il existe au maximum 65535 ports au sein du protocole TCP/IP, certains sont normalisés du port numéro 0 à 1023 pour êtres utilisés par un service Internet. La plupart sont libres de 1024 à 65535. Choisir un nombre élevé comme nouveau numéro de port. Choisir par exemple le numéro de port 11033, mais, vérifier sa disponibilité.
# Vérifier si le port 11033 est ouvert. nmap -sT -p 11033 127.0.0.1
# Affiche Starting Nmap 7.12 ( https://nmap.org ) at 2017-12-24 17:55 CET Nmap scan report for localhost (127.0.0.1) Host is up (0.000094s latency). PORT STATE SERVICE 11033/tcp closed unknown Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds
Ici le port 11033 est fermé car il n'est pas utilisé. Si je comprend bien, quand il sera utilisé par un service de la machine GNU/Linux, il sera ouvert automatiquement.
Ouvrir le même port 11033 sur la box qui devrait normalement empêcher par défaut l'utilisation d'un port non standard.
Authentification avec une clé SSH
# Autorise l'authentification par clé SSH : PubKeyAuthentication yes
# Oblige l'authentification par clé SSH : AuthenticationMethods publickey
# Oblige l'authentification par clé, et, par mot de passe utilisateur : # AuthenticationMethods publickey,password
# Pour chaque paire de clés autorisées pour un utilisateur donné qui existe sur le serveur, ajouter l'empreinte de la clé publique dans le fichier ".ssh/authorized_keys" de cet utilisateur.
# Spécifier le chemin du fichier authorized_keys qui renseigne les clés autorisées de l'utilisateur.
# La chemin ".ssh/authorized_keys" est proposé par défaut depuis la configuration du serveur SSH :
AuthorizedKeysFile .ssh/authorized_keys
# Tester une connexion en ajoutant le paramètre 'PubkeyAuthentication=no' : ssh root@serveur -o PubkeyAuthentication=no # Le message d'erreur retourne que la connexion est impossible et nécessite une clé privée pour correspondre à la clé publique stockée sur le serveur. Permission denied (publickey).
Désactiver la connexion SSH par mot de passe
# Cette option autorise ou interdit l'authentification de base avec mot de passe. # Il ne sera plus possible de se connecter avec un identifiant / mot de passe, il faudra une paire de clés publique/privé valides, avec éventuellement une passe phrase. PasswordAuthentication no PermitEmptyPasswords no /etc/init.d/ssh restart
Limiter le temps pour se connecter
LoginGraceTime 20s
ClientAliveInterval - Contacte le serveur pour empêcher la déconnexion
# Définir une durée pour recontacter le serveur et empêcher la déconnexion : ClientAliveInterval 900 # Concerne le nombre maximal de requêtes : ClientAliveCountMax 0
Quelques paramètres de configuration complémentaires
# Permet de définir vers quel machine les paramètres vont s'appliquer, l'étoile veut dire toutes. Hote *
# Spécifie si le ssh doit vérifier l'adresse IP de l'hôte qui se connectent au serveur pour détecter une usurpation DNS. CheckHostIP yes
# Permet de définir la clé privée a utiliser pour s'authentifier lors de la connexion sur la machine distante. IdentityFile ~/.ssh/id_rsa
# Permet de définir le nom du compte utilisateur à distance qu'il faut utiliser pour ce connecter. User nom_du_compte
HashKnownHosts permet de chiffrer known_hosts avec ecdsa-sha2-nistp256
# Chaque fois que le client SSH se connecte à un serveur, il stocke la clé publique du serveur. # Ces informations sont stockées dans un nom de fichier nommé known_hosts. # Le fichier known_hosts est disponible dans le sous-répertoire .ssh de l'utilisateur associé côté client. # Dans le cas où la signature du serveur change, SSH protégera l'utilisateur en informant de ce changement.
# Cette option de configuration est très utile, mais introduit également un nouveau risque. # Auparavant, il était courant de stocker le nom d'hôte associé à la clé. # Le résultat est une «image» du réseau, révélant quels systèmes sont connectés. # Cela a permis aux vers et autres scripts malveillants d'utiliser facilement ces informations et de se propager à d'autres systèmes, une fois qu'ils avaient un seul système compromis.
# Le nom d'hôte haché avec ecdsa-sha2-nistp256 est illisible pour l'œil humain ou les scripts malveillants. # Pour chaque nouvelle connexion à l'hôte associé, l'algorithme de hachage donnera la même chaîne. # De cette façon, le client sait qu'il a déjà une clé stockée et la compare pendant le processus de prise de contact avec le serveur. HashKnownHosts yes
Autoriser ou interdire des utilisateurs avec Pam
# PAM fournit la gestion des sessions et des comptes ! # Garder l'option PAM activée même si l'authentification par mot de passe ChallengeResponseAuthentication est désactivée.
# L'authentification challenge-réponse est une famille de protocoles dans lesquels une question ("challenge") et une réponse valide ("réponse") permettent l'authentification.
# L'option "ChallengeResponseAuthentication" contrôle la prise en charge du schéma d'authentification "clavier interactif" défini dans la RFC-4256.
# Le schéma d'authentification "clavier interactif" pourrait poser à un utilisateur un nombre quelconque de questions à facettes multiples.
# En pratique, il ne demande souvent que le mot de passe de l'utilisateur.
# Pour utiliser une authentification challenge-response, configurer le serveur pour utiliser un backend, par exemple PAM, qui enverra les challenges et vérifiera les réponses. # Comme le serveur n'est pas configuré par défaut, "ChallengeResponseAuthentication" est défini sur "no" pour empêcher SSH d'utiliser un serveur non configuré.
# L'exemple le plus simple de protocole challenge-réponse est l'authentification par mot de passe, le challenge demandant le mot de passe et la réponse valide étant le mot de passe correct. # Un adversaire qui peut espionner une authentification par mot de passe peut alors s'authentifier de la même manière. # Une solution consiste à émettre plusieurs mots de passe, chacun ayant son propre identifiant. # Le vérificateur peut utiliser n'importe quel identifiant et le prouveur doit disposer du mot de passe correct pour cet identifiant. # Un adversaire qui intercepte une paire de messages défi-réponse n'a aucun indice pour aider à relever un défi différent à un moment différent.
UsePAM yes ChallengeResponseAuthentication no
ServerAliveInterval - Indiquer au serveur SSH que le client est toujours en vie
# Éditer la configuration du client : sudo nano /etc/ssh/ssh_config
# Cette directive est très pratique si l'on a pas un accès root à la machine. # La directive ServerAliveInterval va permettre au client d'envoyer toutes les x secondes une requête au serveur SSH pour lui signaler qu'il est toujours en vie.
# Indiquer au serveur SSH que le client est toujours en vie pour éviter la déconnexion par timeout : ServerAliveInterval 120
Clé publique et fichier known_hosts
# La liste des empreintes des hôtes connus est stockée dans le fichier ~/.ssh/known_hosts # Une clé publique enregistrée dans le fichier know_hosts permet de se souvenir de l'identité d'un serveur sur lequel une connexion a été établie. # Elles servent a avertir si un serveur est remplacé par un autre serveur qui pourrait être celui d'un pirate.
# Ce fichier devrait pouvoir être vidé sans risque. Faire une copie par précaution.
# L'option ssh-keygen -l permet de retrouver l'empreinte d'une clé SSH. # Lancer la commande ssh-keygen -l # Indiquer le chemin de la clé ./ssh/ssh_host_rsa_key.pub pour connaître l'empreinte rsa de la clé SSH.
# Ne pas confondre une connexion par clé publique SSH et une connexion par mot de passe ! # Lors d'une connexion SSH avec le mot de passe du compte distant, aucune clé publique n'est inscrite dans ce fichier. # L'authentification par mot de passe "PasswordAuthentication yes" est autorisée dans le fichier de configuration du serveur SSH.
# Quand l'utilisateur root de la machine cliente aura partagé sa clé SSH publique dans authorized_keys grâce aux droits de l'utilisateur sudoers sur la machine distante... # Passer PasswordAuthentication à no depuis sudo nano /etc/ssh/sshd_config
# Dans certains cas, le fichier known_hosts peut être utilisé et renseigné depuis un autre endroit. # Pour l'utilisateur zer00cool et son dossier Git de référence, la clé publique est stockée dans le fichier /var/git/.ssh/known_hosts # Exemple avec cette installation de Git : Récupérer le dépôt Git.
Exemple pour comparer deux empreintes fingerprint
# Machine locale : ssh -v serveur OpenSSH_7.5p1 Debian-5, OpenSSL 1.0.2l 25 May 2017 (...) debug1: Server host key: ecdsa-sha2-nistp256 SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
# Machine distante : # Suivant l'algorithme utilisé, modifier le type de clé à interroger : ssh_host_dsa_key ou ssh_host_ecdsa_key ou ssh_host_ed25519_key ou ssh_host_rsa_key. ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key 256 SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Fail2ban protège le port 22 SSH par défaut
# Quand le port 22 SSH par défaut est modifié, indiquer dans jail.local, dans la partie SSH, le nouveau port 11033 SSH. [ssh] enabled = true port = ssh,sftp,NumeroDePort filter = sshd logpath = /var/log/auth.log maxretry = 3
Google Authenticator pour SSH
Utiliser Google Authenticator pour protéger votre connexion SSH avec un code de validation à 2 facteurs.
Créer un tunnel SSH inverse
Contourner les restrictions web avec un tunnel SSH proxy SOCKS5
L'hypothèse la plus sage est que tout Internet public n'est pas digne de confiance. Utiliser le tunnel SSH peut être utilisé pour se protéger contre des attaques potentielles de Man-In-The-Middle, contourner des pare-feu en utilisant des tunnels sécurisés. L’utilisation des proxy est courante pour accéder à un site réservé à certaines adresses IP, ou pour échapper au filtre HTTP de son entreprise ou encore pour surfer anonymement.
Avantage d'un proxy
Un proxy peut avoir plusieurs avantages. Le proxy vous rendre anonyme en masquant votre adresse IP, vous n'apparaissez plus avec votre propre adresse IP. Le Proxy mets en cache les pages les plus demandées pour accélérer votre navigation Le proxy permet d'accéder à des pages non accessibles en échappant le filtre http. Le proxy vous donne la possibilité de naviguer des sites web bloqués dans votre Pays.
Inconvénient d'un proxy
# Si vous passez par un proxy, alors ce dernier connaîtra tous vos mots de passe, sauf si vous utilisez HTTPS/SSL. # Le proxy peut modifier les pages à la volée avant de vous les donner par exemple il peut ajouter une publicité dans un site que vous consultez. # Certains proxy peuvent être configurés pour censurer des sites.
# En règle général les entreprises préfèrent désactiver le Port Forwarding pour éviter la fuite d'informations : AllowTcpForwarding no # Spécifie si le transfert de sockets de domaine Unix est autorisé : AllowStreamLocalForwarding no # Spécifie si les hôtes distants sont autorisés à se connecter aux ports transférés pour le client : GatewayPorts no # Spécifie si le transfert de périphérique est autorisé : PermitTunnel no
Ouvrir un tunnel SSH vers le serveur
Cette commande déporte la connexion locale vers le proxy tant que la fenêtre du terminal est ouverte : ssh -D 9999 -C utilisateur@serveur ssh -D 9999 -C utilisateur@serveur -i /chemin/de/la/cle/prive.private
-v pour le mode verbeux. -4 utiliser uniquement ipv4 -g Permet aux hôtes distants de se connecter aux ports redirigés locaux. -C : Compresse toutes les données (en utilisant un algorithme de compression standard gzip). -f : Faire passer le processus en arrière-plan juste avant l'exécution de la commande. -q : Provoque la suppression de la plupart des messages d’avertissement et de diagnostic. -D : Indique à SSH que nous voulons connecter le tunnel SSH SOCKS sur le port spécifié et crée un transfert de port dynamique.
# Cette option semble plutôt conseillée, elle interdit l'usage de commandes sur le terminal du serveur une fois la connexion avec le tunnel SSH proxy SOCKS5 établie. -N Indique à SSH de ne pas exécuter de commande à distance une fois le tunnel activé. Ceci est utile pour simplement transférer des ports.
# Utiliser un numéro de port qui n'a pas été assigné : cat /etc/services
Configurer le navigateur Web manuellement pour utiliser le port 9999 en tant que proxy SOCKS v5.
Avec Firefox : Aller dans Préférences (about:preferences) Général Paramètres réseau Cliquer sur le bouton "Paramètres..."
Configuration manuelle du proxy : Hôte SOCKS : localhost 9999 en SOCKS v5 Pas de proxy pour : localhost, 127.0.0.1
On peut aussi cocher les cases suivantes : Utiliser un DNS distant lorsque SOCKS v5 est actif Activer le DNS via HTTPS
Tester le proxy
Une fois la configuration du tunnel terminée, vérifier que le tunnel est opérationnel avec cette commande : ps -ef | grep ssh
La machine locale demande les pages au serveur proxy. Le proxy va chercher les pages et les retournera à votre ordinateur.
Le navigateur ne connaît alors qu’une seule adresse, celle du serveur proxy ! Tester l'adresse IP avec le site What Is My IP : https://www.whatismyip.com
Une fois fait, modifier le numéro de port dans la configuration du navigateur. L'accès web ne devrait alors plus fonctionner. C'est que la configuration est bien prise en compte.
Une fois la connexion avec le serveur coupée, le proxy ne permettra plus la navigation. Revenir à un usage normal avec le proxy du système.
Note : Le serveur proxy semble fonctionnel, puisque l'adresse IP a changée et que la navigation est pleinement fonctionnelle ! Pourtant, pour chaque page que je visite depuis le navigateur, un message d'erreur est affiché sur le terminal. channel 13: open failed: connect failed: Connection refused channel 14: open failed: connect failed: Connection refused channel 15: open failed: connect failed: Connection refused
Ajouter le paramètre -q permet de ne pas afficher les messages d'erreur dans le terminal. Cela ne permet pas pour autant de corriger la cause du problème. Cela supprime également l'affichage de la bannière de debian et de la randomart image.
-->
/etc/ssh/sshd_config ################# # Spécifie si le transfert TCP est autorisé. AllowTCPForwarding yes
# Spécifie les destinations vers lesquelles le transfert de port TCP est autorisé. (Bloque la connexion avec localhost:9999 ou 127.0.0.1:9999 ) PermitOpen any
# Spécifie si le système doit envoyer des messages TCP keepalive. Si ils sont envoyés, la mort de la connexion ou le crash de l'une des machines sera correctement remarqué. # Si TCP keepalives n'est pas envoyé, les sessions peuvent se bloquer indéfiniment sur le serveur, laissant des utilisateurs «fantômes» consommer les ressources du serveur. # La mort de la connexion ou le crash de la machines sera remarqué pour mettre fin à la connexion : TCPKeepAlive yes
Les messages d'erreurs sont toujours affichés. #################
Avec -v --> channel 3: open failed: administratively prohibited: open failed debug1: channel 3: free: direct-tcpip: listening port 9999 for 127.0.0.1 port 443, connect from ::1 port 40044 to ::1 port 9999, nchannels 4 debug1: Connection to port 9999 forwarding to socks port 0 requested. debug1: channel 3: new [dynamic-tcpip]
debug1: Connection to port 9999 forwarding to socks port 0 requested. debug1: channel 4: new [dynamic-tcpip]
channel 23: open failed: connect failed: Connection refused debug1: channel 23: free: direct-tcpip: listening port 9999 for 127.0.0.1 port 443, connect from ::1 port 41702 to ::1 port 9999, nchannels 31 debug1: Connection to port 9999 forwarding to socks port 0 requested. debug1: channel 23: new [dynamic-tcpip] channel 23: open failed: connect failed: Connection refused debug1: channel 23: free: direct-tcpip: listening port 9999 for 127.0.0.1 port 443, connect from ::1 port 41704 to ::1 port 9999, nchannels 31 debug1: channel 14: free: direct-tcpip: listening port 9999 for 51.77.188.246 port 443, connect from ::1 port 41628 to ::1 port 9999, nchannels 30
? Rien n'écoutait le port 9999 sur la machine de destination. J'ai redémarré le service NTOP, puis tout a fonctionné et je me suis débarrassé du message d'erreur.
? Cannot resolve hostname remote DNS. Traffic is tunneled but DNS request no. Try to edit you DNS hosts file manually and add the service you wish to access
connect failed: Connection refused -> Le firewall refuse la connexion
La machine "distante" est inaccessible avec ssh pour une raison quelconque. Peut être un problème du fait que le port 22 soit fermé sur la box ? ssh: connect to host localhost port 22: Connection refused
Spécifier l'ip de la machine cliente depuis ~/.ssh/config ? # Host remote.server.com # HostName remote.server.com # Port 10022 # User useronremote # IdentityFile ~/.ssh/keys/key1/openssh.keyforremote.priv # LocalForward 2222 SSHBeyondRemote.server.com:22
Informations complémentaires
https://www.culture-informatique.net/cest-quoi-un-serveur-proxy/ https://www.panoptinet.com/cybersecurite-decryptee/pourquoi-utiliser-un-proxy.html http://www.prodigemobile.com/tutoriel/a-quoi-sert-proxy/
Créer un tunnel SSH pour envoyer ses mails
# Utiliser un tunnel SSH pour envoyer ses mails lors de vos déplacements. # Cette commande relie le port 9999 de votre ordinateur portable au port 25 de votre serveur distant. # Le port distant doit être celui sur lequel vous avez configuré votre serveur mail pour écouter le réseau. ssh -f USER@SERVEUR -L 9999:SERVEUR:25 -N
# Configurer ensuite votre client de messagerie pour utiliser localhost:9999 en tant que serveur SMTP. # Avec Kmail ou Thunderbird, plusieurs comptes SMTP peuvent être configurés, permettant alors de choisir un serveur SMTP en particulier pour envoyer les mails en un simple clic.
Configuration du client SSH local
Le client local doit autoriser les tunnels. Dans /etc/ssh/ssh_config AllowTcpForwarding yes
Pour permettre l’accès à ce tunnel aux autres machines du réseau local, il faut autoriser un paramètre supplémentaire. GatewayPorts yes
Configuration du serveur SSH distant
Sur l'ordinateur distant, la machine inaccessible, créez le tunnel. ssh -NR 11033:localhost:22 utilisateur@ip_du_client_local
Une fois le tunnel établi, il reste a remonter le tunnel pour établir la connexion SSH depuis local. ssh -p 11033 utilisateur@127.0.0.1
Avec autossh et une connexion SSH sans mot de passe, vous pouvez très facilement créer un script de démarrage sur le serveur distant pour que le tunnel soit toujours récréé sans intervention humaine. autossh -i /path/to/privateKey.rsa -NR 11033:localhost:22 utilisateur@ip_du_client_local
Il suffit d’ajouter cette commande dans vos scripts de boot, par exemple, /etc/rc.local
Ici on utilise SSH pour ouvrir l’accès à un serveur SSH, mais on pourrait envisager d’ouvrir l’accès à n’importe quel serveur qui tournerait sur distant, par exemple un serveur web pour du monitoring Munin. Sur le serveur distant : ssh -NR 22280:localhost:80 user@ip_du_client_local Sur la machine locale : firefox "http://127.0.0.1:22280"
Vous pouvez centraliser sur votre serveur local des tunnels venant de tous les noobs que vous aidez régulièrement. L’astuce est de remplacer le port compris entre 1024 et 65535. et de maintenir une liste exhaustive de ceux-ci !
Ressources complémentaires pour Tunnel SSH inverse
Autre solution de contournement de Nat avec Pwnat : http://samy.pl/pwnat/
Redémarrer automatiquement les sessions et tunnels SSH avec autossh
Redémarrer automatiquement les sessions et tunnels SSH : https://packages.debian.org/stable/net/autossh
Transformer sa machine en serveur SSH pour accepter les connexions entrantes
Si vous voulez accéder à votre PC depuis un autre lieu vous devez le transformer en serveur.
Installer le paquet openssh-server : sudo apt-get install openssh-server
Lors de l'installation, certaines étapes intéressantes s'effectuent automatiquement : Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... * Restarting OpenBSD Secure Shell server sshd [ OK ]
RSA et DSA sont deux algorithmes de chiffrement asymétrique. SSH peut travailler avec plusieurs algorithmes de chiffrement différents. Lors de l'installation une clé publique et d'une clé privée pour chacun des deux algorithmes (RSA et DSA) sont créés.
Démarrer ou arrêter le serveur SSHD
# Démarrer SSHD : sudo /etc/init.d/ssh start
# Arrêter SSHD : sudo /etc/init.d/ssh stop
# Recharger la configuration : sudo /etc/init.d/ssh reload
# Redémarrer SSHD : sudo /etc/init.d/ssh restart
Connaître le statut du serveur SSHD
sudo /etc/init.d/ssh status sudo service sshd status
Se connecter au serveur SSH avec un login et un mot de passe
# Commande de connexion à utiliser depuis la machine cliente : ssh login@ip_du_serveur
# Pour se connecter : # L'adresse IP est celle du serveur distant. # Le login est le nom d'utilisateur existant sur le serveur distant. # Le mot de passe a utiliser pour votre utilisateur sur le serveur distant.
# La commande ifconfig permet de trouver une adresse IP locale, par exemple 192.168.0.11. # Pour simuler une connexion réseau en vous connectant depuis votre PC vers votre PC, utiliser l'adresse IP 127.0.0.1 ou localhost.
# Le serveur devrait répondre et demander une confirmation d'authenticité du serveur : The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is 49:d9:2d:2a:df:fd:80:ab:e9:eb:59:37:58:34:de:f7. Are you sure you want to continue connecting (yes/no)? # Le fingerprint (empreinte) du serveur est 49:d9:2d:2a:df:fd:80:ab:e9:eb:59:37:58:34:de:f7. C'est un numéro unique qui permet d'identifier le serveur. # Si quelqu'un tente de se faire passer pour le serveur, le fingerprint changera. Vous saurez qu'il se passe quelque chose d'anormal. # Valider le fingerprint avec yes. # Le serveur et le client vont échanger une clé de chiffrement. # Le serveur devrait demander au bout de quelques secondes votre mot de passe sauf si une clé SHH a déjà été configurée : # utilisateur@localhost's password:
# Si aucune erreur ne s'affiche, c'est que vous êtes bien connecté. # Un message de bienvenue apparaît avec un prompt qui correspond à la console du PC distant. # Vous êtes connectés. Vous pouvez effectuer toutes les opérations que vous voulez comme si vous étiez chez vous. utilisateur@login-desktop:~$
Fingerprint d'une clé publique
# Obtenir la fingerprint d'une clé publique : ssh-keygen -lf ~/.ssh/id_rsa.pub
# Obtenir la fingerprint d'un hôte connu dans le fichier know_hosts : # L'option -F permet de chercher un hôte. L'option -l affiche la fingerprint. ssh-keygen -l -F xxx.xxx.xxx.xxx
# Utiliser ssh-keyscan pour comparer l'empreinte de votre known_hosts à celle du serveur :
ssh-keyscan xxx.xxx.xxx.xxx | awk '{print $3}' | base64 -d | openssl md5 -c
# Je suppose que l'empreinte affichée signifie qu'il y a bien correspondance.
Se connecter en SSH avec un utilisateur sudoers pour configurer le serveur distant
Se connecter par SSH en tant que root pour créer un utilisateur du système et l'ajouter dans le groupe sudoers. Un utilisateur sudoers peut utiliser la commande sudo pour devenir root.
Éditer le fichier de configuration du serveur SSH /etc/ssh/sshd_config
# Ne pas confondre avec le fichier /etc/ssh/ssh_config qui est le fichier de configuration du client SSH.
# Éditer la configuration du serveur SSH :
sudo nano /etc/ssh/sshd_config
# Faciliter la lecture des fichiers de configuration en production en supprimant tous les commentaires présents par défaut. # Attention, en relisant le fichier en production, les exemples de commandes qui n'ont pas été activées ne seront plus présents. # Il sera donc indispensable d'étudier le fichier par défaut pour connaître les options qui devront être activées dans la configuration en production.
# Sauvegarder une copie de la configuration existante par défaut : cd /etc/ssh/sshd_config /etc/ssh/sshd_config.defaut # Enlever les commentaires sur le fichier de production : sudo grep -E -v '^(#|$|;)' /etc/ssh/sshd_config
Journalisation des tentatives de connexion dans /var/log/auth.log
# Loguer les tentatives de connexions dans /var/log/auth.log en ajoutant la ligne suivante : SyslogFacility AUTH
Changer le port du serveur SSH
# Le serveur SSH écoute sur le port 22 qui est le port par défaut de SSH. # Le faire écouter sur plusieurs ports à la fois en rajoutant des lignes similaires pour ne pas couper le réseau au serveur distant SSH. Port 22 Port 11033
Préciser le nouveau port 11033 à la prochaine connexion en ligne de commande. ssh -l NomUtilisateur -p NumeroDePort IP
Configurer SSH pour utiliser le Protocole 2
# Permet l'authentification RSA, clé publique/privé généré avec "ssh-keygen". # Établir une seconde connexion avec un deuxième terminal pour éviter une configuration non fonctionnelle. # Si la connexion refuse de s'établir avec la nouvelle configuration, remettre la configuration fonctionnelle en utilisant le premier terminal toujours connecté au serveur.
# Ajouter tout en haut du fichier de configuration une ligne Protocole 2. # La version la plus récente du protocole est la version 2, normalisée par l'Internet Engineering Task Force (IETF) en janvier 2006. # Elle apporte quelques corrections au niveau de la sécurité par rapport à SSH-1 (notamment au niveau des algorithmes utilisés). # L'ancien protocole 1 est moins sécurisé et doit être désactivé, sauf si vous savez que vous en avez spécifiquement besoin. Différences en le Protocole 1 et le Protocole 2 : http://www.snailbook.com/faq/ssh-1-vs-2.auto.html
# Éditer le fichier de configuration du serveur SSH : sudo nano /etc/ssh/sshd_config
# Le Protocole 2 est mieux sécurisé. Protocol 2
# Redémarrer pour appliquer les modifications : sudo /etc/init.d/ssh restart # ou sudo systemctl restart sshd
HostKey - Clé publique du serveur SSH
# Les clés d'hôte sont stockées par défaut dans le répertoire /etc/ssh, dans des fichiers commençant par "ssh_host_<rsa / dsa / ecdsa / ed25519>_key". # Les clés d'hôte sont normalement générées automatiquement lors de la première installation d'OpenSSH ou lors du premier démarrage de l'ordinateur. # Le programme ssh-keygen peut être utilisé pour générer des clés d'hôte supplémentaires ou pour remplacer des clés existantes. # L'emplacement peut être modifié dans le fichier de configuration du serveur.
# Cette configuration gère le type de la clé publique du serveur qui sera ajoutée dans le fichier know_hosts du client SSH sur la machine locale. # Utiliser ED25519 semble correspondre aux recommandations de l'ANSI pour prendre l'habitude d'utiliser ce type de chiffrement lors d'une étape de création d'une paire de clés pour un utilisateur. # HostKey /etc/ssh/ssh_host_rsa_key # HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key # DSA est considéré comme obsolète ! # HostKey /etc/ssh/ssh_host_dsa_key
# Comparer une clé publique permet de s'assurer que le serveur auquel on se connecte est le bon et permet d'éviter de se faire piéger avec une attaque de type man-in-the-middle. # Si un attaquant récupère la clé privée d'un utilisateur, il pourra effectuer des attaques de type intermédiaire sur le réseau pour obtenir les mots de passe des utilisateurs. # Il pourra alors prendre le contrôle du serveur et l'administrer en tant que sudoers si la clé privée dérobée correspondait à un utilisateur autorisé à administrer le serveur. # Un rendu visuel de la clé publique peut être effectué avec l'affichage de la randomart image lors de la connexion pour faciliter la comparaison des clés publiques.
# On peut obtenir les clés publiques du serveur distant avec la commande "ssh-keyscan". Il ne s'agit pas des fingerprint ! # Deux clés publiques sont affichées, car, j'autorisais encore RSA et ED25519. ssh-keyscan xxx.xxx.xxx.xxx # xxx.xxx.xxx.xxx:22 SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2 xxx.xxx.xxx.xxx ssh-rsa AAAAB3NzaC1yc2EAAA ... ... ... cYqgG0i4RmmDY0bI+z8B # xxx.xxx.xxx.xxx:22 SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2 # xxx.xxx.xxx.xxx:22 SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2 xxx.xxx.xxx.xxx ssh-ed25519 AAAAC3NzaC1lZDI1N ... GMPPkTEMI7pCNg7a8HPBeFv+
# Trouver la clé publique correspondante à l'adresse IP d'un serveur distant qui a été enregistrée dans le fichier know_hosts : ssh-keygen -H -F xxx.xxx.xxx.xxx
# Informations complémentaires sur les clés d'hôte : HostKey : https://www.vandyke.com/solutions/host_keys/host_keys.pdf
# La plupart des clients SSH stockent les noms d'hôte de manière non chiffrée par défaut. # De ce fait, si une personne, ou un virus, réussit à s'introduire sur la machine, il lui est alors très facile de lister tous les serveurs auxquels vous vous êtes connectés. # Pour peu que vous ayez une clé privée sans passphrase ou un agent en cours d’exécution, l'intrus pourra naviguer sur vos autres machines. Source : http://www.qanuq.com/2018/05/05/securiser-ssh-known-hosts/ Source : http://nms.csail.mit.edu/projects/ssh/
Spécifier le fichier des clés autorisées
# Ajouter la clé publique du client autorisé à se connecter au serveur dans le fichier des clés publiques autorisées sur le serveur distant.
# Rappel pour créer la clé SSH : Créer une paire de clés SSH.
# Rappel pour transférer la clé SSH : Exporter la clé SSH publique du client vers un utilisateur du serveur distant.
AuthorizedKeysFile .ssh/authorized_keys
Désactiver la connexion SSH par mot de passe
# Cette option autorise ou interdit l'authentification de base avec mot de passe. # Il ne sera plus possible de se connecter avec un identifiant / mot de passe, il faudra une paire de clés publique/privé valides, avec éventuellement une passe phrase. PasswordAuthentication no PermitEmptyPasswords no
PermitRootLogin - Choix de connexion pour l'utilisateur root sur le serveur SSH
# La directive PermitRootLogin est activé par défaut avec la valeur "yes".
# La valeur "No" désactive les connexions root qui ne seront plus autorisées.
# Avant de mettre la valeur "no" il faut se connecter par SSH en tant que root pour créer un utilisateur du système et l'ajouter dans le groupe sudoers.
PermitRootLogin no
# Tester la désactivation de l'utilisateur root : ssh root@serveur
Limiter les tentatives de connexion
# Permet de limiter a un nombre maximum les tentatives de connexions SSH par adresse IP, sans être authentifié, avant de bloquer l'adresse IP. # Le 5 correspond au nombre de tentatives maximum autorisées avant d'avoir droit à une nouvelle chance. # Le 50 correspond au pourcentage de chance que la nouvelle tentative soit rejetée. # La probabilité que les connexions soient bloquées augmente alors linéairement jusqu’à 100% pour 20 connexions. MaxStartups 5:15:20
Limiter le nombre de tentatives de connexion : MaxAuthTries 3
Limiter le nombre de sessions simultanées : MaxSessions 2
Autoriser la connexion pour un utilisateur ou un groupe
# Autoriser la connexion pour les utilisateurs suivants : AllowUsers moi toi # Autoriser la connexion pour les groupes suivants : AllowGroups administrateurs sudoers
Interdire la connexion pour un utilisateur ou un groupe
# Interdire la connexion à l'utilisateur root et à l'utilisateur debian : DenyUsers root debian # Interdire la connexion aux utilisateurs des groupes suivants : DenyGroups group1 group2
# Note : # L'utilisateur debian est un utilisateur sudoers sans mot de passe sur un serveur VPS OVH.
Limiter le temps pour se connecter
LoginGraceTime 20s
Contacte le serveur pour empêcher la déconnexion
# Définir un temps pour recontacter le serveur et empêcher la déconnexion. ClientAliveInterval 200 ClientAliveCountMax 0
# ATTENTION en cas de processus trop long, le processus est tué, et, le résultat est incertain. # Il pourrait donc être conseillé de désactiver cette option, ou, de lui donner un délai suffisamment important.
Déport d'affichage - Export Display
# Autoriser le déport d'affichage par SSH : X11Forwarding no
Améliorer le message affiché suite à une demande de connexion au serveur SSH
# Améliorer le message affiché suite à une demande de connexion au serveur SSH depuis le fichier "/etc/issue". sudo nano /etc/issue
# Les options suivantes devraient pouvoir être intégrées, mais, lors de mes essais, les commandes n'ont pas été interprétées : \b : Insert the baudrate of the current line. \d : Insert the current date. \s : Insert the system name, the name of the operating system. \l : Insert the name of the current tty line. \m : Insert the architecture identifier of the machine, eg. i486 \n : Insert the nodename of the machine, also known as the hostname. \o : Insert the domainname of the machine. \r : Insert the release number of the OS, eg. 1.1.9. \t : Insert the current time. \u : Insert the number of current users logged in. \U : Insert the string “1 user” or “ users” where is the number of current users logged in. \v : Insert the version of the OS, eg. the build-date etc.
Ajouter votre message personnalisé :
-@
.##@
.####@
@#####@
. *######@
.##@o@#####@
/############@
/##############@
@######@**%######@
@######` %#####o
@######@ ######%
-@#######h ######@.`
/#####h**`` `**%@####@
@H@*` `*%#@
*` `*
#################################################
# Demande de connexion au serveur visionduweb ! #
#################################################
# Afficher un message pour l'utilisateur lors de sa demande de connexion SSH. Banner /etc/issue
PrintMotd - Affichage de /etc/motd en mode interactif
# Spécifie si sshd doit afficher le contenu du fichier /etc/motd quand un utilisateur se connecte en mode interactif. # Sur certains systèmes, il est aussi affiché par l'interpréteur de commandes (shell), par le fichier /etc/profile ou équivalent.
# Refuser l'affichage de /etc/motd en mode interactif. # La valeur no désactive complètement l'impression de motd. PrintMotd yes
Modifier le message par défaut de Debian une fois la connexion SSH établie
# On peut modifier le message par défaut de Debian une fois la connexion établie depuis le fichier "/etc/motd". sudo nano /etc/motd
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.
# Remplacer le message par les dièses suivants, qui se placeront sous l'image ascii art:
#################################################
Personnaliser un message utilisateur pour obtenir des informations sur le système
# Personnaliser un message pour notre utilisateur pour obtenir des informations sur le système suite à la connexion SSH. # Modifier le fichier suivant : sudo nano /home/utilisateur/.bash_profile sudo chown utilisateur. /home/utilisateur/.bash_profile
# Ajouter les lignes :
echo "#################################################" echo "" echo "Informations sur les connexions SSH actuellement établies :" w echo "" echo "Espace disque et pourcentage d'occupation avec df -h -x tmpfs :" df -h -x tmpfs echo "" echo "Mémoire RAM et swap disponible avec free -m :" free -m echo "" echo "Utilisation de tmpfs avec df -h | grep tmpfs :" df -h | grep tmpfs echo "#################################################"
Contre-mesures contre les attaques de fichiers .rhosts et hosts.equiv
Introduction aux commandes r
Liste d'hôtes et d'utilisateurs ayant l'autorisation d'accéder à votre système par une commande « r » avec des privilèges « de confiance » Autorise ou interdit à des ordinateurs et à des utilisateurs l'utilisation des commandes « r » (telles que rlogin, rsh ou rcp) sans donner de mot de passe.
Man page Debian : https://manpages.debian.org/stretch/manpages-fr/hosts.equiv.5.fr.html Man page Ubuntu : http://manpages.ubuntu.com/manpages/trusty/fr/man5/hosts.equiv.5.html
Secure the .rhosts and hosts.equiv Files to Avoid Linux Hacks : https://www.dummies.com/programming/networking/secure-the-rhosts-and-hosts-equiv-files-to-avoid-linux-hacks/ Les fichiers rhosts : http://n8on.free.fr/hackzines/hacker2020/8/rhost.htm
Désactiver les commandes r
Un bon moyen d'empêcher l'utilisation abusive de ces fichiers consiste à désactiver les commandes r.
Deux méthodes sont proposées : - Mettre en commentaire les lignes commençant par shell, login et exec dans inetd.conf. - Éditer les fichiers rexec, rlogin et rsh situés dans le répertoire /etc/xinetd.d en ouvrant chaque fichier dans un éditeur de texte et en modifiant disable = no en disable = yes.
Bloquer l'accès
Quelques contre-mesures peuvent bloquer l’accès non autorisé aux fichiers .rhosts et hosts.equiv.
Deux méthodes sont proposées : - Bloquer les adresses usurpées au niveau du pare-feu. - Définir les autorisations de lecture pour le propriétaire de chaque fichier uniquement. Changer les droits du fichier .rhosts pour chaque utilisateur : chmod 600 ~/.rhosts Changer les droits du fichier hosts.equiv dans le répertoire /etc : chmod 600 hosts.equiv
Utiliser Tripwire pour surveiller ces fichiers et être alerté lorsque l’accès est obtenu ou que des modifications sont apportées. Télécharger tripwire : https://sourceforge.net/projects/tripwire/
Interdire la prise en compte des fichiers de configuration des commandes r avec SSH
# SSH peut émuler le comportement de la commande obsolète rsh, il suffit de désactiver les accès non sécurisés pour RSH. # Interdire la prise en compte des fichiers ~/.rhosts et ~/.shosts de l'utilisateur en mettant à jour sshd_config avec les paramètres suivants : IgnoreRhosts yes
HostbasedAuthentication - Authentification basée sur l'hôte
# Il pourrait être intéressant de coupler la clé SSH et la passphrase avec une identification par hôte. A suivre pour plus d'informations. # Pour le moment, on désactive cette option, ce qui est cohérent avec la désactivation précédente de rhosts.
# Refuser l'authentification basée sur l'hôte : HostbasedAuthentication no
Host-based Authentication : https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication
UseDNS - Authentification basée sur les DNS
# L'option UseDNS est pour la plupart inutile. # Si les machines clientes sont présentes sur Internet, il y a de fortes chances qu'elles n'aient pas de DNS inversé, que leur DNS inversé ne se résout pas en avant ou que leur DNS ne fournisse aucune information autre que "appartient à ce ISP" que l'adresse IP indique déjà.
# Refuser l'authentification basée sur les DNS : UseDNS no
AcceptEnv LANG LC_*
# Permet au client de définir des variables d'environnement dès l'établissement de la connexion : AcceptEnv LANG LC_*
# Utile en particulier pour LC_CTYPE, qui indique entre autres l'encodage du terminal.
Aller plus loin avec KEX Ciphers MAC
Vous devez comprendre la cryptographie pour appliquer les paramètres suivants. Sinon, utiliser les valeurs par défaut.
# Spécifier les algorithmes KEX (échange de clés) disponibles : KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
# Spécifier les ciphers autorisés : Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
# Spécifier les algorithmes MAC (Message authentication code) : MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
Récupérer la liste des chiffrements et des alog supportés par le serveur OpenSSH
ssh -Q cipher ssh -Q cipher-auth ssh -Q mac ssh -Q kex ssh -Q key
Noter que la commande ssh -Q ne montrera que les chiffrements et algorithmes pris en charge par le client SSH, pas le serveur. Pour voir comment le serveur est actuellement configuré pour les utiliser, il est préférable d’exécuter la commande suivante : sshd -T | grep "\(ciphers\|macs\)"
Il est plus difficile de recommander ce qui devrait être supprimé et autorisé, car la sécurité des chiffrements et des macs change à mesure que de nouvelles vulnérabilités sont découvertes. Au début 2018, quelques chiffrements et macs raisonnables à utiliser sont les suivants : ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
Comme pour toutes les modifications que vous apportez, veillez toujours à effectuer des tests approfondis auprès de tous les clients, car vous ne souhaitez pas désactiver un chiffrement ou un Mac utilisé par un client plus ancien qui ne prend pas en charge les nouveaux chiffrements.
StrictModes
# Spécifie si sshd doit vérifier les modes et le propriétaire des fichiers de l'utilisateur et du répertoire de base (home directory) de l'utilisateur avant d'accepter une connexion. # C'est normalement souhaitable, parce que quelquefois, les novices laissent accidentellement leur répertoire ou leurs fichiers en accès complet à tout le monde.
# Vérifie les modes et le propriétaire des fichiers et du répertoire home de l'utilisateur avant de se connecter : StrictModes yes
LogLevel
# LogLevel INFO
# LogLevel VERBOSE enregistre l'empreinte digitale de la clé de l'utilisateur lors de la connexion. # Permet d'avoir une trace d'audit claire de la clé utilisée pour se connecter : LogLevel VERBOSE
Subsystem sftp /usr/lib/openssh/sftp-server
# Journaliser les accès aux fichiers de niveau sftp qui ne seraient pas journalisés autrement : # Subsystem sftp /usr/lib/openssh/sftp-server Subsystem sftp /usr/lib/openssh/sftp-server -f AUTHPRIV -l INFO
Quitter, valider avec le Y pour yes et ENTRER pour enregistrer la modification
CTRL-X, puis Y, puis ENTER
Tester la validité de la syntaxe pour la nouvelle configuration
Avant d'appliquer les changement et de redémarrer SSH, vérifier la syntaxe de la configuration : sudo sshd -t
Mode de test étendu : sudo sshd -T
Appliquer les changements
Rester bien connecté au premier terminal durant cette étape ! Ouvrir un deuxième terminal pour recharger la configuration du serveur SSH. Redémarrer le serveur distant et quitter le premier terminal entraîne le risque de la perte d'accès SSH. Penser à bien vérifier que l'accès SSH fonctionne correctement en ouvrant une nouvelle connexion depuis un nouveau terminal !
Pour un serveur local, il peut être redémarré, la machine étant physiquement accessible, la configuration peut être modifiée par root ou un utilisateur sudoers. Pour un serveur distant il est indispensable de s'assurer que la connexion fonctionnera toujours suite à la prise en compte de la nouvelle configuration.
Recharger la configuration SSH depuis un second terminal
# Debian/Ubuntu Linux : # Cette commande fonctionne et un retour d'information est affiché en retour :sudo /etc/init.d/ssh reload# Pas sur que cette commande fonctionne car aucune information n'est donnée en retour :sudo service ssh reload# Préférer la commande suivante : # Pas sur que cette commande fonctionne car aucune information n'est donnée en retour :sudo systemctl reload ssh
# CentOS/RHEL/Fedora Linux :
sudo systemctl restart sshd.service
# OpenBSD :
doas /etc/rc.d/sshd restart
# FreeBSD :
sudo service sshd restart
Si la nouvelle configuration a bien été prise en compte : La connexion par mot de passe est désactivée. Seul l'utilisateur "toto", par exemple, avec les droits sudoers, peut être utilisé maintenant pour se connecter au serveur avec sa paire de clés privée/publique. L'utilisateur root du serveur distant ne peut plus être utilisé pour se connecter. (Un pirate devra trouver le nouvel utilisateur utilisé, sa paire de clé privée/publique, son mot de passe sudoers.)
La configuration du serveur SSH
Un exemple complet et commenté pour configurer un serveur SSH :
################################ # Configuration du Serveur SSH # ################################ # Le Protocole 2 est mieux sécurisé : Protocol 2 # Port à utiliser : Port 22 # Clé publique du serveur à utiliser pour identifier le serveur : # HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ed25519_key # Oblige l'authentification par clé SSH : # Valeur commentée par défaut ! AuthenticationMethods publickey # Interdire l'authentification par mot de passe : PasswordAuthentication no # Interdire les mots de passe vide : PermitEmptyPasswords no # Autoriser la connexion pour les utilisateurs suivants : AllowUsers user1 user2 user3 user4 # Choix de connexion pour l'utilisateur root sur le serveur SSH : PermitRootLogin no # Interdire certains utilisateurs : DenyUsers root # Durée maximum autorisée pour établir la connexion : LoginGraceTime 25s # Limiter a un nombre maximum les tentatives de connexions SSH non authentifiée : MaxStartups 3:50:5 # Maximum de 3 essais pour renseigner la passe phrase : MaxAuthTries 3 # Maximum de 3 sessions ouvertes en même temps : MaxSessions 3 # Autorise l'authentification par clé SSH : PubkeyAuthentication yes # Clés publiques autorisées pour établir une connexion : AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 # Interdire la prise en compte des fichiers de configuration des commandes r avec SSH : IgnoreRhosts yes # Le serveur d'authentification challenge-response PAM n'est pas configuré par défaut : ChallengeResponseAuthentication no # PAM fournit la gestion des sessions et des comptes ! UsePAM yes # Refuser l'export display : X11Forwarding no # La valeur no désactive complètement l'impression de motd. PrintMotd yes # Refuser l'authentification basée sur les DNS : UseDNS no # Refuser l'authentification basée sur l'hôte : HostbasedAuthentication no # Permet au client de définir des variables d'environnement dès l'établissement de la connexion : AcceptEnv LANG LC_* # Loguer les tentatives de connexions dans /var/log/auth.log en ajoutant la ligne suivante : SyslogFacility AUTH # Permet d'avoir une trace d'audit claire de la clé utilisée pour se connecter : LogLevel VERBOSE # Journaliser les accès aux fichiers de niveau sftp qui ne seraient pas journalisés autrement : # Subsystem sftp /usr/lib/openssh/sftp-server Subsystem sftp /usr/lib/openssh/sftp-server -f AUTHPRIV -l INFO # Définir un temps limite d'inactivité pour forcer la déconnexion : ClientAliveInterval 900 # Concerne le nombre maximal de requêtes : ClientAliveCountMax 0 # Vérifie les modes et le propriétaire des fichiers et du répertoire home de l'utilisateur avant de se connecter : StrictModes yes # La mort de la connexion ou le crash de la machines sera remarqué pour mettre fin à la connexion : TCPKeepAlive yes # Afficher un message pour l'utilisateur suite à une demande de connexion : Banner /etc/issue # En règle général les entreprises préfèrent désactiver le Port Forwarding pour éviter la fuite d'informations : AllowTcpForwarding no # Spécifie si le transfert de sockets de domaine Unix est autorisé : AllowStreamLocalForwarding no # Spécifie si les hôtes distants sont autorisés à se connecter aux ports transférés pour le client : GatewayPorts no # Spécifie si le transfert de périphérique est autorisé : PermitTunnel no # Spécifie les destinations vers lesquelles le transfert de port TCP est autorisé : PermitOpen any # Spécifier les algorithmes KEX (échange de clés) disponibles : KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 # Spécifier les ciphers autorisés : Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr # Spécifier les algorithmes MAC (Message authentication code) : MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
Configurer le serveur SSH pour un usage local avec l'utilisateur Git zer00cool
Utiliser Git avec SSH et un utilisateur Git local zer00cool
L'utilisateur zer00cool est créé pour utiliser Git en local. Voir la procédure pour créer l'utilisateur : Installer et utiliser Git sur Linux.
Les paramètres du serveur SSH sont configurés dans le fichier /etc/ssh/sshd_config pour permettre à l'utilisateur local de pouvoir travailler avec Git.
# L'utilisateur zer00cool utilise le dossier /var/git/ comme dépôt de référence Git. # L'empreinte de la clé SSH est stockée dans le fichier /var/git/.ssh/known_hosts # Pour le moment l'utilisateur Git zer00cool n'a pas de clé privée ni publique. # La connexion à SSH se fera avec le mot de passe utilisateur zer00cool. # Lancer la connexion SSH avec zer00cool pour utiliser Git. ssh zer00cool@localhost
Autoriser l'utilisateur zer00cool
Liste des comptes utilisateurs qui seront accessibles à distance par le protocole SSH. Ajouter les utilisateurs autorisé les un après les autres séparés par un espace.
# Ajouter les deux lignes suivantes pour n'autoriser que le ou les utilisateurs et groupes renseignés. AllowUsers zer00cool AllowGroups zer00cool
# A ajouter pour n'autoriser que localhost. # La deuxième syntaxe autorise une connexion au serveur SSH avec le compte zer00cool mais uniquement depuis la machine distante qui a l'adresse IP 127.0.0.1. AllowUsers zer00cool@127.0.0.1 AllowUsers zer00cool@127.0.1.1 /etc/init.d/ssh restart
Autoriser une adresse IP
# Décommenter la ligne ListenAddress et ajouter l'adresse IP de la seule interface que le serveur ssh doit écouter.
# Dans mon cas je laisse deux IP en écoute.
ListenAddress 127.0.0.1
ListenAddress 127.0.1.1
/etc/init.d/ssh restart
Sécuriser la connexion SSH pour root
Interdire la connexion par mot de passe pour root
# Cette option autorise ou interdit l'authentification de root avec mot de passe. # Il ne sera plus possible de se connecter avec l'utilisateur root et son mot de passe. # Il faudra une paire de clés SSH valides et une passphrase pour accéder de façon sécurisée.
# PermitRootLogin Yes PermitRootLogin without-password /etc/init.d/ssh restart
Interdire la connexion SSH pour root
# Plus restrictif, root ne pourra plus se connecter localement avec SSH. # Penser a bien créer un utilisateur secondaire pouvant se connecter par clés et passphrase.
# PermitRootLogin prohibit-password PermitRootLogin no /etc/init.d/ssh restart
# En cas de tentative, il semble que l'adresse IP du serveur local soit ajoutée au fichier /etc/host.deny # Vérifier si cela ne provient pas d'un autre service de protection que denyhosts.
Verrouiller les utilisateurs dans leurs répertoires personnels
Protéger un dossier avec chroot.
Lancer une commande ou un programme à distance avec SSH
Lancer une commande
# Lancer un programme via des lignes de commandes ajoutées dans un fichier texte : ssh user@remotehost "`cat filename.txt`"
Lancer un programme
# Lancer un programme : ssh user@remotehost sudo poweroff
Établir une connexion SSH vers un terminal déporté avec screen
# Ouvrir la connexion SSH normalement.
# Créer un screen et le nommer : screen -S testscreen
# Détacher le screen : Ctrl+a+d
# Afficher la liste de screen disponibles : screen -ls
# Se connecter en SSH directement vers le screen détaché depuis la machine cliente : ssh -t USER@SERVEUR screen -r testscreen
# Si il n'y a qu'un seul screen détaché, inutile de nommer le screen cible.
# Si aucun screen n'a été détaché, lancer la commande suivante depuis la machine cliente : ssh -t USER@SERVEUR /usr/bin/screen -xRR
Sécuriser SSH
Installer denyhosts
Installer le paquetdenyhostspour protéger SSH. Autoriser des connexions SSH avechosts.allow. Refuser toutes les connexions SSH avechosts.deny.
SSH Guard
Même si vous pensez que tout est correctement configuré pour interdire les mots de passe, il est préférable d’avoir une deuxième couche de défense. Source : https://www.sshguard.net
Limite TCP
Mettre en place une limite TCP pour SSH.
Fail2ban
Fail2ban protège SSH, FTP et dovecot... Fail2ban.
Utiliser un VPN par certificat
Avec un VPN, on peut fermer SSH, ou FTP, au d'autres services au public. La connexion ce fait avec des certificats clients. Permet d'authentifier chaque machine qui se connecte.
Penser a sécuriser FTP, dovecot, webmin
Webmin n'est pas protégé par fail2ban. Pour protéger Webmin : Fermer Webmin ... ou utiliser un proxy SSH. Avec un proxy SSH, on utilise une connexion SSH pour encapsuler le flux.
Transfert de fichiers par SSH
lftp
Lftp peut être utilisé comme client FTP mais lftp sait aussi transférer des fichiers par SSH. Pour se connecter par SSH en utilisateur toto sur le serveur ordi1.exemple.org : % lftp sftp://toto@ordi1.exemple.org
scp
Pour transférer le fichier test1.txt situé dans le répertoire courant vers le home du compte toto de la machine ordi1.exemple.org sur laquelle tourne un serveur SSH : % scp test1.txt toto@ordi1.exemple.org:
Pour récupérer le fichier test2.txt situé dans le répertoire personnel de l'utilisateur toto de la machine ordi2.exemple.org et l'écrire dans le répertoire courant : % scp toto@ordi2.exemple.org:test2.txt .
Pour récupérer tous les fichiers ayant l'extension .txt situés dans le répertoire /usr/local de la machine ordi2.exemple.org et l'écrire dans le sous-répertoire test-scp du répertoire courant : % scp toto@ordi2.exemple.org:'/usr/local/*.txt' test-scp
Pour transférer l'intégralité du sous-répertoire test-scp du répertoire courant vers le sous répertoire incoming du home de l'utilisateur toto de la machine ordi1.exemple.org : % scp -r test-scp toto@ordi1.exemple.org:incoming
SFTP
La connexion SFTP est en instance de configuration. SFTP
sshfs
# Le système sshfs serait meilleur que NFS. apt install sshfs
# Il est nécessaire d'avoir sshd. apt install openssh-server
# Créer un dossier de partage sur le serveur : mkdir partage
# Se déconnecter puis se reconnecter ainsi : sshfs utilisateur-du-serveur@adresse-ip-du-serveur:/home/debian/partage /home/zer00cool/Partage
SSH avec Windows
Se connecter à SSH avec PuTTY
Télécharger PuTTY
Télécharger PuTTY depuis son site officiel : https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html Utiliser la version live de PuTTY ou installer PuTTY.
L'agent SSH de PuTTY s'appelle Pageant.
Générer une paire de clés
Générer une paire de clés publique et privée avec Puttygen.
Enregistrer la clé publique dans un fichier en cliquant sur « Save public key ». Vous pouvez nommer ce fichier comme vous voulez, par exemple cle.pub.
Enregistrer la clé privée en cliquant sur « Save private key ». Vous pouvez nommer ce fichier comme vous voulez, par exemple cle.ppk.
Placer la clé publique sur le serveur distant
cd /.ssh echo "votre_cle_publique_a_copier" >> authorized_keys
Renseigner la clé privée dans PuTTY
Onglet Connection / SSH / Auth Cliquer sur le bouton « Browse » pour sélectionner notre clé privée. Sélectionner afficher tous les fichiers pour sélectionner la clé privée id_rsa_nomdelacle.private
Renseigner avec quel utilisateur se connecter
Onglet Connection Ajouter un nom dans Logical name of remote host. Par exemple, "Serveur VPS - utilisateurautorise".
Onglet Connection / Data Ajouter dans Auto-login username le nom d'utilisateur utilisateurautorise.
Changer l'encodage pour UTF-8
Onglet Windows / Translation Choisir UTF-8 pour Remote character set.
Renseigner l'adresse IP du serveur
Onglet Session Renseigner l'adresse IP du serveur : xx.xxx.xx.xx Le port peut également être spécifié, en général, il s'agit du port 22 par défaut.
Sauvegarder le profil de connexion qui vient d'être créé
Saisir un nom pour votre profil pour ne pas avoir à ressaisir les informations. Cliquer sur Save.
Connexion
La connexion peut s'effectuer.
Lancer la connexion avec Putty. Une alerte demande d'accepter l'empreinte de connexion au serveur. Accepter la nouvelle empreinte.
Erreur de format de la clé privée
Une nouvelle alerte empêche la connexion : No supported authentification methods available (server sent publickey)
PuTTY préfère les fichiers PPK : La conversion du fichier de notre clé privée PEM doit être réalisée vers PPK pour pouvoir se connecter au système hôte.
Utiliser PuTTYgen pour charger la clé privée et la convertir pour PuTTY. Une fois la clé chargé, le message suivant est affiché par PuTTY : Successfully imported foreign key (OpenSSH SSH-2 private key (old PEM format)). To use this key with PuTTY, you need to use the "Save private key" command to save it in PuTTY's own format. Ajouter un commentaire pour reconnaître la clé : "Cle de connexion utilisateur lecannabistejp". On conserve la valeur de 4096 bits et on enregistre la nouvelle clé privée.
Indiquer l’emplacement de la nouvelle clé privée convertie dans les options de PuTTY.
Avec cette clé privée convertie pour PuTTY, la connexion au serveur distant sera fonctionnelle depuis PuTTY.
Exporter la configuration de PuTTY
Ouvrir l'éditeur de registre regedit. Aller à l'emplacement de PuTTY : HKEY_CURRENT_USER\Software\SimonThatam\PuTTy\Sessions Sauvegarder les sessions existantes.
Pourquoi ne pas utiliser PuTTY
Malgré de nombreuses tentatives, je n'ai pas réussi a afficher la randomart image lors de la première demande de connexion au serveur. Dès lors, on ne peut pas vérifier visuellement que la clé du serveur distant corresponde à notre clé privée. Pour des raisons de sécurité, on préférera utiliser un autre client SSH.
Se connecter à SSH avec cmder
Installer cmder
Site officiel : https://cmder.net Télécharger cmder : https://github.com/cmderdev/cmder/releases/download/v1.3.11/cmder.zip
Décompresser cmder sur le bureau puis le déplacer à la racine du disque dur. Entrer dans le dossier cmder pour créer un raccourci de l’exécutable vers le Bureau.
Penser a bien adapter le nom de votre utilisateur
Dans les exemples suivants, le nom d'utilisateur courant de Windows est "OxyLunatic". Penser a bien modifier "OxyLunatic" par le nom d'utilisateur qui utilise actuellement la machine Windows. On peut trouver le nom d'utilisateur qui utilise actuellement le système depuis un terminal avec la commande "net config workstation".
Placer vos clés SSH dans le bon dossier
Vérifier que le dossier .ssh existe dans le dossier de l'utilisateur courant, sinon, le créer : cd C:\Users\OxyLunatic # Vérifier si le dossier .ssh existe déjà : ls -la # Créer le dossier .ssh si il n'existe pas : mkdir .ssh
Déplacer les clés privées et publiques dans le dossier .ssh de l'utilisateur courant. C:\Users\OxyLunatic\.ssh
Créer une configuration SSH personnalisé pour votre utilisateur courant en ouvrant le terminal cmder : cd C:\Users\OxyLunatic\.ssh
Ouvrir le fichier vide config : nano config
Ajouter la ligne suivante va permettre d'afficher la randomart image à chaque connexion. Cela permet de vérifier visuellement qu'on tente bien de se connecter au bon serveur et que la passphrase de notre clé privée peut être saisie en confiance. VisualHostKey=yes
Fermer et enregistrer le fichier : Au clavier : CTRL + x Saisir y pour yes : y Valider avec entrée : Entrée
La commande de connexion pour l'utilisateur OxyLunatic, vers l'utilisateur du serveur distant : ssh utilisateur-distant@serveur-distant -i C:\Users\OxyLunatic\.ssh\id_rsa_.private.pem
Export Display
Introduction
L'export display consiste à se logguer à distance en mode graphique, comme on le fait avec un client et un serveur SSH en mode texte. On peut alors exécuter des applications graphiques sur le serveur distant : la fenêtre graphique de l'application et son contenu seront envoyés par le réseau vers la machine cliente ; les données du clavier et de la souris de la machine cliente sont envoyées vers le serveur.
L'export display nécessite une bonne connexion réseau entre le client et le serveur puisque le serveur envoie des images de l'écran au client...
Source : linux.developpez.com/formation_debian/export-display.html
Utiliser l'export display
# Se connecter au serveur : ssh -X user@serveur
# Lancer alors l'application graphique de votre choix : # Un simple startx devrait suffire à lancer X. # Sinon, installer startx ou xinit qui permettent de simplifier le lancement d'un serveur X pour démarrer une session X.
# GDM peut être installé pour configurer et utiliser l'export display.
# Étape 1 : installer xauth sur le serveur et sur le client : sudo apt-get install xauth
# Étape 2 : vérifier que X11 forwarding est activé dans SSH sudo nano /etc/ssh/sshd_config AllowTcpForwarding yes X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost yes AddressFamily inet
# Sur le client, on édite aussi la configuration SSH : sudo nano /etc/ssh/ssh_config ForwardAgent yes ForwardX11 yes ForwardX11Trusted yes
# Étape 3 : session en SSH sur le serveur # Connectez-vous en SSH à votre serveur avec l'option -Y : ssh -Y SERVEUR # Lancer : echo $DISPLAY # Si tout va bien, le serveur devrait afficher : localhost:10.0
Utiliser Putty et Xming
Attention, Xming n'est pas du tout open source si j'en crois cette page : www.straightrunning.com/XmingNotes/terms.php#head-4
Utiliser le client X SSH Mobaxterm
MobaXterm est votre boîte à outils ultime pour l'informatique à distance. MobaXterm fournit les outils de réseau distants essentiels pour Windows (SSH, X11, RDP, VNC, FTP, MOSH, ...) et les commandes Unix (bash, ls, cat, sed, grep, awk, rsync, ...) sur le bureau Windows.
Site officiel Mobaxterm mobatek : https://mobaxterm.mobatek.net
Utiliser X Cygwin
x.cygwin.com
Cacher le port de connexion SSH avec le Port Knocking
Voir également le Port Knocking.
Autres améliorations à mener concernant la sécurité de SSH
# Créer une interface réseau pour SSH, par exemple, eth1, différente de l'interface depuis laquelle vous répondez aux demandes, par exemple, eth0.
Gérer les clés SSH
# Il existe plusieurs moyens de gérer les clés ou les sessions SSH. # Faire des recherches complémentaires sur les avantages ou inconvénients des solutions suivantes :
- Stocker ses clés dans KeePass2. - ssh-agent - gpg-agent - keychain - ssh-ident - vault - keybase.io
Agent SSH
L'agent SSH est un programme qui tourne en arrière-plan en mémoire et qui retient les clés privées pendant toute la durée de votre session.
# Lancer le programme ssh-add sur l'ordinateur client. $ ssh-add Enter passphrase for /home/utilisateur/.ssh/id_rsa: Identity added: /home/utilisateur/.ssh/id_rsa
L'agent SSH ne demande la passphrase qu'une seule fois au début. Vous pouvez maintenant vous connecter plusieurs fois sur un ou plusieurs serveurs sans avoir besoin de ressaisir la passphrase.
# Afficher toutes les clés actuellement en mémoire. ssh-add -l
# Afficher l'empreinte des clés en mémoires. ssh-add -L
# Supprimer la passphrase d'une clé qui est en mémoire. ssh-add -d
# Retirer toutes les passphrases de la mémoire. ssh-add -D
Bibliographie
NAVIGATION
PARTICIPER ET PARTAGERBienvenue sur le wiki de Amis SH. De nombreuses pages sont partagées sur ce wiki. Créer un compte utilisateur pour participer sur le wiki. Les pages présentées sur le wiki évoluent tous les jours. Certaines recherches sont peu abouties et incluent des erreurs. Utiliser la recherche interne du wiki pour trouver votre contenu. La page de discussion de Amis SH vous permet de poser vos questions. Consulter le site amis-sh.fr pour installer votre propre serveur web. Améliorer le contenu des pages avec vos retours depuis l'onglet discussion. Ce contenu ne doit pas servir à nuire à autrui ou à un système informatique. Protéger votre système Linux ou Windows avec cette page dédiée à la sécurité. |
SOUTENIR CE WIKISoutenir le wiki avec un don en monnaie numérique : AEON - Bitcoins - Bitcoins Cash - Bitcoins Gold - Bitcore - Blackcoins - Basic Attention Token - Bytecoins - Clams - Dash - Monero - Dogecoins - Ğ1 - Ethereum - Ethereum Classique - Litecoins - Potcoins - Solarcoins - Zcash OBTENIR DE LA MONNAIE NUMERIQUEObtenir gratuitement de la monnaie numérique : Miner de la cryptomonnaie. |