SSH¶

Générer une clé publique avec la commande suivante (nous utiliserons le chiffrement RSA 2048 bits)¶

ssh-keygen -t rsa

Nous pouvons aussi préciser un nom de clé, pour ce faire il faudra préciser le chemin complet:

ssh-keygen -t rsa /home/utilisateur/.ssh/id_rsa

Envoyer cette clé au serveur SSH¶

ssh-copy-id -i user@serveur-ssh.fr

Là aussi si le nom de la clé a été personnalisée, il faudra préciser le chemin complet:

ssh-copy-id -i /home/utilisateur/.ssh/cle-utilsateur-rsa user@serveur-ssh.fr

Nous pouvons aussi utiliser la commande scp pour envoyer notre clé vers le serveur distant

scp /home/utilisateur/.ssh/cle-utilisateur-rsa utilisateur@serveurssh.fr:/home/utilisateur/.ssh/client-autorisés(authorized_client)

Dans le cas où il n'y aurait pas d'accès par mot de passe d'autorisé, nous accéderons physiquement à la machine avec notre clé publique (sur une clé usb par exemple...) et nous copierons le contenu de la clé publique id_rsa.pub dans le fichier ~/.ssh/authorized_keys

cat id_rsa.pub >> ~/.ssh/authorized_keys

note: Si le fichier authorized_keys n'existe pas il suffit de créer un fichier vide, par exemple avec touch

touch authorized_keys

En cas d'erreur (Agent admitted failure to sign using the key)¶

Si la clé a le nom par défaut:

ssh-add

Si le nom de la clé à été changée:

ssh-add /home/utilisateur/.ssh/cle-utilisateur-rsa

Supprimer la clé publique d'un hôté connu (en cas de soucis de connexion par exemple)¶

ssh-keygen -R 192.168.1...

On peut préciser le fichier des hôtes connus en plus

ssh-keygen -f "/home/jo/.ssh/known_hosts" -R 192.168.1...

Sauvegarde et restauration du dossier caché .ssh¶

Ce dossier se trouve à la racine du home de chaque utilisateur, ex:

/home/jo/.ssh

Ce dossier contient les clés ssh privées et publiques ainsi que les hôtes (serveur SSH) connus. Il est donc important de le mettre de côté. Par contre il nécessite une certaine attention au niveau des droits:

le dossier .ssh doit être en 755
le fichier id_rsa doit être en 600 (clé privée, donc ne pas mettre entre toutes les mains !)
le fichier id_rsa.pub (clé publique, qui doit être consultable) en 644
le dossier known_hosts en 644 aussi

Gérer ses serveurs SSH en cluster avec l'outil mssh (multiple ssh)¶

Prérequis: installer mssh

fichier de configuration de mssh à placer dans dans le home de l'utilisateur(.mssh_clusters):

/home/jo/.mssh_clusters

Contenu et syntaxe de ce fichier:

#mes serveurs ssh

machine1: utilisateur@192.168.1.4
machine2: user@192.168.1.5
machine3: utilisateur@192.168.1.250:60000 (nous pouvons préciser le port)

serveurs: [machine1] [machine2] [machine3] ...
...

il suffit ensuite de lancer mssh en précisant les alias du fichier de config ci-dessus:

mssh -a serveurs

Et hop ! tous les terminaux s'ouvriront !

Note: mssh sait aussi utiliser le fichier de config dans ~/.ssh/config

ex:

web-ct: web-ct
teamspeak-ct: teamspeak-ct
subsonic-ct: subsonic-ct
dl-ct: root@dl-ct
ninja-ct: ninja-ct
roberto-ct: roberto-ct
dgc-ct: root@dgc-ct
jeedom-ct: jeedom-ct 
pi-hole-ct: pi-hole-ct
zabbix-ct: zabbix-ct

serveurs: [web-ct] [teamspeak-ct] [subsonic-ct] [dl-ct] [ninja-ct] [roberto-ct] [dgc-ct] [jeedom-ct] [pi-hole-ct] [zabbix-ct]

ninja: [ninja-ct] [roberto-ct]

Inspirée de ce site: [https://www.vpsinfo.com/tutorial/ssh-multiple-servers-with-mssh/ https://www.vpsinfo.com/tutorial/ssh-multiple-servers-with-mssh/ ]

Créer un fichier de config dans .ssh¶

Afin de faciliter la connexion à des serveurs SSH, il peut être intéressant de créer un fichier config dans:

/home/utilisateur/.ssh/config

Le contenu du fichier est de la forme suivante:

host mon-srv
    hostname nom-de-domaine.fr ou adresse IP
    port 22 (par défaut) 
    user utilisateur

On peut préciser quelques options dont l'option port forwarding (redirection de port/tunnel)

LocalForward 5901 127.0.0.1:5901

Il ne reste maintenant qu'à se connecter au serveur en entrant:

ssh mon-srv

Connexion par rebond¶

Il est possible de se connecter à un serveur B en passant par l'intermédiaire serveur A.

Comme ça il n'y a besoin qu'un seul NAT sur le serveur SSH (une sorte de proxy, d'intermédiaire)

Pour cela il faut utiliser l'option '-J' depuis le client SSH

ssh -J utilisateurA@ip_serveurA utilisateurB@ip_serveur_B

Autoriser ou non la connexion par mot de passe¶

Pour autoriser ou non la connexion par mot de passe, il va falloir éditer le fichier sshd:

nano /etc/ssh/sshd_config

Et ajouter et modifier l'option PasswordAuthentication

# Authentication:

#LoginGraceTime 2m     
PermitRootLogin no
PasswordAuthentication no
#StrictModes yes    
#MaxAuthTries 6     
#MaxSessions 10
....

Autoriser la connexion en root uniquement avec une clé¶

Pour autoriser la connexion en root uniquement avec une clé, il suffit d'ajouter l'option PermitRootLogin without-password au fichier sshd_config

nano /etc/ssh/sshd_config

# Authentication:

#LoginGraceTime 2m     
PermitRootLogin without-password
PasswordAuthentication yes
#StrictModes yes    
#MaxAuthTries 6     
#MaxSessions 10

Tunnel SSH local avec l'option "-L" (local):¶

ssh -L port:localhost:port user@serveur-ssh

exemple pour le port de vnc par défaut 5901:

ssh -L 5901:localhost:5901 user@mon-serveur

Tunnel SSH distant avec l'option "-R" (remote):¶

ssh -R port:localhost:port user@serveur-ssh

exemple pour le port à tout faire 8080

ssh -R 8080:localhost:80 user@serveur-ssh

Nous utiliserons ici l'option "-D" de ssh (Dynamic)

ssh -D 8080 user@serveur-ssh

Notre tunnel est maintenant prêt, il nous reste plus qu'à paramétrer Firefox pour qu'il utilise "localhost" (nous-mêmes) pour sufer:

Aller dans menu, puis préférences (ou options sous windows)
Rubrique Avancé, onglet Réseau
Appuyer sur le bouton paramètres (une nouvelle fenêtre va alors s'ouvrir)
Nous choisirons l'option "configuration manuelle du proxy"
Remplir dans la case (Hôte SOCKS)= 127.0.0.1
Port=8080
Valider son choix par le bouton OK

Voilà maintenant si on vérifie notre IP externe avec le site ipchicken.com , on peut constater que ce n'est pas la même. En effet Firefox utilise à présent celle de notre serveur SSH (proxy SOCKS) distant.