SSH

De Analyse Développement Hacking
Sauter à la navigation Sauter à la recherche
Consulter le wiki : Accueil du wiki - Objectifs - Administrateur - Bureautique - Développeur - Intégrateur - Marketing - Multimédia - Objets numériques - Jeux - We make Hack
Consulter le site : Accueil du site - Annuaire - Blog - Forum - Outils - Utilisateur     Consulter le Redmine : Accueil du Redmine

Sommaire

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 client openssh-client pour 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 clé SSH

Générer une clé RSA ou ed25519

# Générer une clé SSH avec cette commande lancée par le simple utilisateur sans droits supplémentaires.
# 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
# Consulter le manuel :
man ssh-keygen
# L'utilisation du chiffrement DSA semble être déprécié.
# DSA peut être considéré comme équivalente par rapport à une clé RSA de longueur égale.
# DSA est plus rapide pour la génération de signature, mais plus lent pour la validation.
# RSA est plus lent pour le chiffrement, mais plus rapide pour le déchiffrement.
# Les certificats RSA sont bien plus déployés que les certificats DSA au niveau des entreprises.
# L'ANSI et Aeris conseillent de sécuriser SSH avec une authentification par clé Ed25519 lorsque c’est possible.
ssh-keygen -t ed25519 -C "Commentaire"
ssh-keygen -t ed25519 -N votre-mot-de-passe
# ssh-keygen -t rsa -b 4096 -f ~/.ssh/web-admin -C "La clé RSA pour l'administrateur web."
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.
# 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]-----+

Randomart image

L'image générée permet un rendu visuel de notre clé SSH.
Afficher la randomart image de notre clé privée ou publique : 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.

Toujours afficher la randomart image lors de la connexion SSH

# 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.
# Soit depuis le fichier de configuration globale du client SSH :
sudo nano /etc/ssh/ssh_config
VisualHostKey yes

# Soit depuis le fichier de configuration personnalisé de l'utilisateur de la machine locale :
nano .ssh/config
VisualHostKey=yes

Changer la passphrase qui protège votre clef privée

ssh-keygen -p

Utiliser une keychain plutôt qu'une passphrase

Il est possible d'utiliser une keychain plutôt qu'une passphrase : 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 sur les clés

Par défaut les fichiers créés localement avec l'interface graphique, par clique droit créer un fichier, ont les droits à 664.
Suite à une identification en simple utilisateur, un message d'alerte rappel qui 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.
# Sur la machine locale :
Le fichier id_rsa contient la clef privée et doit obligatoirement avoir la permission 600.
Le fichier id_rsa.pub contient la clef publique et peut avoir les permissions 644.
# Sur le serveur distant :
Le dossier .ssh doit avoir les droits 700.
chown dossier .ssh avec la commande suivante : sudo chown -R utilisateur:utilisateur .ssh
Le fichier id_rsa contient la clef privée et doit obligatoirement avoir la permission 600.
Le fichier id_rsa.pub contient la clef publique et peut avoir les permissions 644.

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 d'hôte OpenSSH sous Linux

# 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.

Exporter la clé SSH publique du client vers un utilisateur du serveur distant

Cas général pour un serveur Debian

Avec ssh-copy-id

L'idéal serait de créer la paire de clé privée et publique depuis la machine locale et d'exporter l'empreinte de la clé avec ssh-copy-id vers le serveur distant.
# Ajouter la clé SSH publique d'un utilisateur client vers l'utilisateur créé à distance sur le serveur.
Utiliser la commande ssh-copy-id sur le modèle :
ssh-copy-id -i /path/de/la/cle.pub utilisateur@serveur
ssh-copy-id -i /path/de/la/cle.pub utilisateur@serveur -p 11033
Si ssh-copy-id n'est pas installé la commande avorte.
Sinon, votre mot de passe est demandé, celui de votre compte distant, pas la passphrase.
La clé est ensuite automatiquement ajoutée à ~/.ssh/authorized_keys sur le serveur.
Se connecter à nouveau pour vérifier si l'accès fonctionne toujours normalement.
Le paquet ssh-copy-id ne semble pas être trouvé sur Debian Stretch.
Si la méthode ssh-copy-id ne fonctionne pas
# 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

Ajouter l'empreinte de la clé publique au fichier authorized_keys avec cat

# 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 :
cat ~/.ssh/id_dsa.pub | ssh utilisateur@ip_du_serveur "cat - >> ~/.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 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.

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 :
Ok.png Source : Tutoriel OVH : https://www.ovh.com/fr/g1769.creation_des_cles_ssh
https://www.ovh.com/fr/g1260.comment_se_connecter_a_son_vps
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.
Ok.png 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.

Manager-ovh-ssh-off-defaut-22.jpg

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 le fichier de configuration de SSH

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/config dans 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

Indiquer le chemin de la clé privée à utiliser pour chacun des serveurs

sudo nano ~/.ssh/config

Host localhost
User UtilisateurDistant1
IdentityFile /home/user/.ssh/id_dsa_11

Host ip_serveur
User UtilisateurDistant2
IdentityFile /home/user/.ssh/id_dsa_22

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

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é publique

# Oblige l'authentification avec une clé publique :
AuthenticationMethods publickey
# On pourrait dupliquer l'authentification par clé, et, par mot de passe utilisateur.
# AuthenticationMethods publickey,password
# Permet de s'authentifier avec une clé publique.
PubKeyAuthentication yes
/etc/init.d/ssh restart

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
/etc/init.d/ssh restart

Limiter le temps pour se connecter

LoginGraceTime 20s

Définir un temps limite d'inactivité pour forcer la déconnexion

# Définir un temps limite d'inactivité pour forcer la déconnexion.
ClientAliveInterval 300
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_dsa
# Permet de définir le nom du compte utilisateur à distance qu'il faut utiliser pour ce connecter.
User nom_du_compte
# Permet d'avoir un fichier known_hosts plus lisible.
HashKnownHosts yes

Autoriser ou interdire des utilisateurs avec Pam

# PAM fournit également la gestion des sessions et des comptes.
# Garder cette option activée même si l'authentification par mot de passe ChallengeResponseAuthentication est désactivée.
# En sécurité informatique, 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 forme particulière d'authentification challenge-response, il faudra 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" de sorte que SSH n'utilise pas de 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.
# Quand d’autres méthodes de sécurité des communications ne sont pas disponibles, l’armée américaine utilise le chiffrement numérique AKAC-1553 TRIAD pour authentifier et chiffrer certaines communications.
# TRIAD comprend une liste de codes d'interrogation à trois lettres, que le vérificateur est censé choisir de manière aléatoire, ainsi que des réponses aléatoires à trois lettres.
# Pour plus de sécurité, chaque jeu de codes n’est valable que pour une période de temps donnée, qui est généralement de 24 heures.
UsePAM yes
ChallengeResponseAuthentication no
Ok-ko.png Source : Linux PAM configuration that allows or deny login via the sshd server : https://www.cyberciti.biz/tips/linux-pam-configuration-that-allows-or-deny-login-via-the-sshd-server.html
Ok-ko.png Source : Challenge Réponse Authentification : https://en.wikipedia.org/wiki/Challenge–response_authentication

Empreinte de clé fingerprint

La liste des empreintes des hôtes connus est stockée dans le fichier ~/.ssh/known_hosts
Les fingerprint permettent de se souvenir de l'identité des serveurs auxquels nous nous sommes connecté.
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.
Pour l'utilisateur zer00cool et son dossier Git de référence, le fingerprint est stockée dans le fichier /var/git/.ssh/known_hosts
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é /etc/ssh/ssh_host_dsa_key.pub pour connaitre l'empreinte dsa d'un serveur.
Ne pas confondre avec une clé publique SSH.
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

Exemple pour comparer deux empreintes

# Poste client
ssh -v serveur
OpenSSH_7.5p1 Debian-5, OpenSSL 1.0.2l  25 May 2017
(...)
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
# Va correspondre à la clé visible côté serveur
ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key
256 SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Suivant l'algorythme utilisé, ça va être ssh_host_dsa_key ou _ecdsa_key ou _ed25519_key ou _rsa_key.

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

Comme vous passez par le proxy, alors ce dernier connaîtra tous vos mots de passe (sauf si vous utilisez HTTPS/SSL).
Le proxy  peut modifie les pages à la volée avant de vous les donner par exemple il peut ajouter une publicité dans un site que  vous avez consulté.
Certains proxy peuvent être configurés pour censurer des sites.
# En règle général les entreprises souhaitent désactiver le Port Forwarding pour éviter la fuite d'informations.
AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
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 pour utiliser le proxy

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

Configuration-du-proxy-sur-firefox.png

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.
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

Ok.png Reverse SSH accéder a un serveur derrière un nat firewall : https://geekfault.org/2011/02/19/reverse-ssh-acceder-a-un-serveur-derriere-un-natfirewall/
Reverse SSH Tunneling : https://www.howtoforge.com/reverse-ssh-tunneling
CCM : http://www.commentcamarche.net/forum/affich-18070378-reverse-ssh
Doc Ubuntu : https://doc.ubuntu-fr.org/tutoriel/reverse_ssh
Autre solution de contournement de Nat avec Pwnat : http://samy.pl/pwnat/

Redémarrer automatiquement les sessions et tunnels SSH avec autossh

Ko.png Redémarrer automatiquement les sessions et tunnels SSH : https://packages.debian.org/stable/net/autossh
Ko.png How to install autossh on Linux : http://ask.xmodulo.com/install-autossh-linux.html

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

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

Depuis la machine cliente : ssh utilisateur@ip_du_serveur
Le login est votre nom d'utilisateur sur le serveur distant et l'adresse IP celle du serveur distant.
# Si vous vous connectez depuis un autre endroit, utiliser l'adresse IP de votre box internet facile à trouver en allant sur www.whatismyip.com.
# Si vous vous connectez depuis un autre PC de votre domicile, sur le même réseau local, entrer l'adresse IP locale. La commande ifconfig permet de trouver l'adresse IP locale, par exemple 192.168.0.11.
# Si vous simulez une connexion réseau en vous connectant depuis votre PC vers votre PC, utiliser l'adresse IP 127.0.0.1 ou localhost.
# Nécessaire pour se connecter
L'adresse IP du serveur.
Le nom d'utilisateur par défaut sur le serveur.
Le mot de passe par défaut pour ce nom d'utilisateur.
# 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:~$

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.
sudo nano /etc/ssh/sshd_config
# 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

Authentification avec une clé publique

# Permet de s'authentifier avec une clé publique.
PubKeyAuthentication yes
# Tester :
ssh root@domaine_ou_ip -o PubkeyAuthentication=no
Permission denied (publickey).

Afficher la randomart image à chaque connexion

Ajouter la ligne suivante dans la configuration du serveur SSH pour ne pas avoir à ajouter le paramètre "-o VisualHostKey=yes" à la commande de connexion :
VisualHostKey yes

Autoriser la connexion par clés RSA

# 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 utilisation le premier terminal toujours connecté au serveur.
sudo nano /etc/ssh/sshd_config
# Ajouter tout en haut du fichier de configuration une ligne Protocol 2, pour RSA mais également pour ECDSA.
# Pour RSA et ECDSA :
Protocol 2
# Après le redémarrage du serveur SSH, la connexion fonctionnera toujours même si l'option RSAAuthentication est commentée.
# Laisser cette option commentée car elle est dépréciée et correspond au protocole 1 de SSH.
# Si la préférence n'est pas mentionnée, c'est cette option qui est utilisée par défaut.
# RSAAuthentication yes
# Redémarrer pour appliquer les modifications :
sudo /etc/init.d/ssh restart
# ou
sudo systemctl restart sshd
# Algorithmes HostKey pris en charge par ordre de préférence.
# J’accepte ici uniquement les clés RSA, mais, en cas d'ajout de la ligne "Protocol 2" au début du fichier de configuration, les clés ECDSA devraient également être autorisées.
HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_dsa_key # DSA est considéré comme obsolète.
# HostKey /etc/ssh/ssh_host_ecdsa_key
# HostKey /etc/ssh/ssh_host_ed25519_key
# Noter que les trois options suivantes semblent être dépréciées :
## KeyRegenerationInterval
## RhostsRSAAuthentication
## ServerKeyBits

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

Refuser la connexion de l'utilisateur root au serveur

# PermitRootLogin yes est activé par défaut.
# No désactive les connexions root distantes.
# 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 :
ssh root@domaine_ou_ip
Permission denied (publickey).

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

AllowUsers toto
AllowGroups administrateurs

Interdire la connexion pour un utilisateur

DenyUsers root
DenyGroups group1 group2

Limiter le temps pour se connecter

LoginGraceTime 20s

Définir un temps limite d'inactivité pour forcer la déconnexion

# Définir un temps limite d'inactivité pour forcer la déconnexion.
ClientAliveInterval 2000
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 avec yes
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".
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é :
#################################################
# Demande de connexion au serveur visionduweb ! #
#################################################

                   -@                
                  .##@               
                 .####@              
                 @#####@             
               . *######@            
              .##@o@#####@           
             /############@          
            /##############@         
           @######@**%######@        
          @######`     %#####o       
         @######@       ######%      
       -@#######h       ######@.`    
      /#####h**``       `**%@####@   
     @H@*`                    `*%#@  
    *`                            `* 

  ####################################

Ajouter les deux lignes suivantes pour charger le message dans la configuration SSH :
# Afficher un message pour l'utilisateur lors de sa demande de connexion SSH.
Banner /etc/issue

En complément

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 :
#################################################
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
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/

Refuser 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.
Refuser la prise en compte des fichiers ~/.rhosts et ~/.shosts de l’utilisateur en mettant à jour sshd_config avec les paramètres suivants :
IgnoreRhosts yes

Refuser l'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.
HostbasedAuthentication no
Host-based Authentication : https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication

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.

LogLevel

# 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 INFO
LogLevel VERBOSE
# Journalise les accès aux fichiers de niveau sftp qui ne seraient pas facilement journalisés autrement. (Lecture / écriture / etc.)
# 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.)

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 Debian.
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 paquet denyhosts pour protéger SSH.
Autoriser des connexions SSH avec hosts.allow.
Refuser toutes les connexions SSH avec hosts.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

Source : https://kgrall.wordpress.com/2017/12/06/serveur-ssh-ftp-securise-sftp/
Comment se connecter à un serveur SFTP avec FileZilla : https://help.one.com/hc/fr/articles/115005585709-Comment-se-connecter-%E0-un-serveur-SFTP-avec-FileZilla-

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


Source complémentaire : https://tutox.fr/2019/08/02/explorer-un-repertoire-distant-grace-a-sshfs/

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 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

Liens complémentaires sur l'export display

Voir Export Display : https://formation-debian.viarezo.fr/export-display.html
Se connecter à un Unix/Linux à distance : https://linux.developpez.com/formation_debian/export-display.html

Sécuriser le port SSH avec le Port Knocking

Voir également le Port Knocking.

Gérer les clés SSH

# Il existe plusieurs moyens de gérer les clés ou les sessions SSH.
# Stocker par exemple ses clés dans KeePass2.
# Sinon, faire des recherches complémentaires sur les avantages ou inconvénients des solutions suivantes :
ssh-agent
gpg-agent
keychain
ssh-ident
vault
keybase.io

Bibliographie

Ok.png Configurer SSH avec GNU/Linux et avec Windows : https://openclassrooms.com/courses/reprenez-le-controle-a-l-aide-de-linux/la-connexion-securisee-a-distance-avec-ssh
Ok.png How to disable ssh password login on Linux to increase security : https://www.cyberciti.biz/faq/how-to-disable-ssh-password-login-on-linux/
Ok.png Configuration initiale du serveur avec Debian 8 - https://www.digitalocean.com/community/tutorials/initial-server-setup-with-debian-8
Ok.png Top 20 OpenSSH Server Best Security Practices : https://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html
Ok.png 16 ultimate SSH hacks : https://www.itworld.com/article/2827172/16-ultimate-ssh-hacks.html
Ok.png Formation Debian SSH : https://formation-debian.viarezo.fr/ssh.html
Ok.png Manuel officiel : http://www.openssh.com/manual.html
Ok.png SSH est géré par OpenSSH : http://www.openssh.com
Ok-ko.png How to configure SSH Key based authentification on a linux server : https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server
Ok-ko.png Configurer et sécuriser un serveur Linux Debian Jessie : https://mespotesgeek.fr/fr/configuration-et-securisation-dun-serveur-linux-debian-jessie-partie-2/
Ok-ko.png Configuration initiale du serveur avec Ubuntu 16.04 - https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04
Ok-ko.png Installation initiale du serveur avec CentOS 7 - https://www.digitalocean.com/community/tutorials/initial-server-setup-with-centos-7
Ko.png Se connecter avec une clé SSH à un serveur distant : https://cplusn.com/2013/05/se-connecter-avec-une-cle-ssh-a-un-serveur-distant/
Ko.png Sécuriser son serveur et son client openssh : https://www.abyssproject.net/2016/08/securiser-son-serveur-et-son-client-openssh/
Ok-ko.png Keeping SSH access secure : https://debian-administration.org/article/87/keeping_ssh_access_secure
Ok-ko.png Définitions : http://www.faqs.org/docs/securing/chap15sec122.html
Ok-ko.png https://www.maketecheasier.com/customize-ssh-configuration-file/
Ko.png Chiffrement RSA : https://fr.wikipedia.org/wiki/Chiffrement_RSA
Ko.png https://www.memoinfo.fr/tutoriels-linux/configurer-serveur-ssh/
Ok-ko.png https://help.ubuntu.com/community/SSH/OpenSSH/Configuring
Ok-ko.png Documentation Ubuntu : https://doc.ubuntu-fr.org/ssh

NAVIGATION

PARTICIPER ET PARTAGER

Vous êtes sur le wiki de Vision du Web.
Les pages présentées sur le wiki évoluent tous les jours.
Certaines recherches sont peu abouties et incluent des erreurs.
Pour participer sur le wiki, créer un compte utilisateur en haut à droite.
La recherche interne du wiki permet de trouver le contenu qui vous intéresse.
Les informations présentes sur ce wiki sont issues d'une recherche personnelle.
Identifiez-vous pour poser vos questions sur la page de discussion de VisionDuWeb.
Améliorer le contenu des pages en faisant des propositions depuis l'onglet discussion.
Les informations du wiki ne doivent pas servir à nuire à autrui ou à un système informatique.
De nombreux outils gratuits sont listés et disponibles dans la boîte à outils de Vision du web.
D'autres pages du wiki peuvent correspondre à vos attentes. La liste de toutes les pages du wiki.

VALORISER LE WIKI

Valoriser le contenu partagé sur 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 NUMERIQUE

Obtenir gratuitement de la monnaie numérique :
Gagner des Altcoins - Miner des Altcoins.
Consulter le miroir du wiki depuis Planet Hoster : Le miroir du wiki version du 12 Juillet 2019.