Différences

Ci-dessous, les différences entre deux révisions de la page.

--- ssh [Le 25/04/2010, 14:36]
213.95.41.13
+++ ssh [Le 27/02/2024, 11:53] (Version actuelle)
bruno cosmétique
@@ Ligne 1: / Ligne 1: @@
+<note warning>Ce document ne traite traite pas le fonctionnement du serveur SSH de windows</note>
 {{tag>administration sécurité serveur}}
-----
 ====== SSH ======
-**OpenSSH** est une version libre de la suite de protocole de SSH, des outils de connectivité de réseau sur lesquels un nombre croissant de personnes sur l'Internet viennent s'appuyer. Beaucoup d'utilisateurs de Telnet, Rlogin, FTP, ou d'autres programmes identiques, ne se rendent pas compte que leur mot de passe est transmis à travers les réseaux en clair. **OpenSSH** chiffre tout le trafic (mots de passe y compris). **OpenSSH** fournit également une variété de méthodes d'authentification. Comme son nom l'indique, **OpenSSH** est développé dans le cadre du projet [[http://www.openbsd.org|OpenBSD]]
+<note>Cette page présente les usages les plus courants de SSH et sa configuration de base.
+Voir sur [[:ssh avancé|SSH Avancé]] pour les autres usages.</note>
-===== Installation du serveur SSH =====
+{{ :logo_openssh.png|Puffy la mascotte de OpenSSH}}
-Si vous voulez accéder à votre PC depuis un autre endroit vous devez le transformer en serveur au préalable.
+[[wpfr>Secure_Shell|SSH]] est un protocole réseau permettant d'établir une communication chiffrée entre deux machines. Il est notamment utilisé pour se connecter à distance à un serveur SSH, y exécuter des commandes ou transférer des fichiers de manière sécurisée.
-[[:tutoriel:comment_installer_un_paquet|installez le paquet]] **[[apt://openssh-server|openssh-server]]** sur votre poste.
-Par défaut, il se lance au démarrage.
+Par défaut, un serveur SSH écoute sur le port TCP standard 22. Un programme client SSH est généralement utilisé pour établir des connexions avec le serveur qui exécute un démon sshd.
-Pour l'activer après une fausse manipulation :
-  sudo /etc/init.d/ssh start
+SSH remplace de manière sécurisée :
+  * Telnet : vous pouvez exécuter des commandes depuis un réseau local ou Internet via SSH
+  * FTP : si vous ne souhaitez qu'ajouter ou modifier des fichiers sur un serveur, SFTP est bien plus adapté que FTP
+  * Et d'autres, via le « tunneling » : on peut accéder à un service réseau en le faisant circuler dans un tunnel SSH pour profiter de toutes les protections qu'il apporte. Vous pouvez donc sécuriser n'importe quel service grâce à SSH, comme VNC par exemple.
-Pour l'arrêter :
+<note important>Beaucoup d'utilisateurs de Telnet, Rlogin, FTP, ou autres programmes de communication ne se rendent pas compte que leurs données et notamment les mots de passe sont transmis en clair sur le réseau, ce qui constitue une faille de sécurité évidente (voir //[[wpfr>Analyseur_de_paquets|sniffing]]//).</note>
-  sudo /etc/init.d/ssh stop
+Les usages de SSH sont entre autre :
+  * Accéder à distance à la console en ligne commande (shell), ce qui permet d'effectuer la totalité des opérations courantes et/ou d'administration sur la machine distante.
+  * Déporter l'affichage graphique de la machine distante.
+  * Transferts de fichiers en ligne de commande.
+  * Montage ponctuel de répertoires distants, soit en ligne de commande, soit via [[:Nautilus]] sous [[:GNOME]] par exemple.
+  * Montage automatique de répertoires distants.
+  * Déporter de nombreux autres services ou protocoles (voir [[:ssh avancé|SSH Avancé]]).
+**OpenSSH** est la solution la plus utilisée pour mettre en place une communication SSH via un ensemble d'outils libres dont certains sont installés par défaut sur Ubuntu.
+Comme son nom l'indique, **OpenSSH** est développé dans le cadre du projet [[http://www.openbsd.org|OpenBSD]].
+C'est cette solution que nous traiterons sur cette page.
-===== Installation du client SSH =====
+===== Installation =====
+Si vous voulez accéder à un ordinateur (votre ordinateur personnel, votre serveur local, un serveur distant dont vous effectuez l'administration, etc.).
+Vous devez installer **[[apt>openssh-server]]** sur la machine à joindre en SSH,  cette machine sera le "serveur" SSH.
-Sur le poste client (qui va prendre l'accès à distance) **openssh-client** installé par défaut sous Ubuntu doit être présent.
+La partie cliente est fournie par le paquet [[apt>openssh-client]], qui est installé par défaut sous Ubuntu.
-Si vous devez prendre le contrôle sur un poste équipé de Windows vous pouvez installer [[http://www.chiark.greenend.org.uk/~sgtatham/putty/|PuTTY]] qui est disponible sous licence MIT (type BSD).
-===== Copier des fichiers via SSH =====
+Vous pouvez vérifier ce qui est déjà installé en tapant ces commandes :
+<code bash>ssh -V</code>
+qui retourne une ligne du type :
+<code>OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f  31 Mar 2020</code>
+et aussi la commande suivante pour connaître la version de la bibliothèque ssl:
+<code bash>dpkg -l libssl*</code>
+==== Installation du serveur SSH ====
-Pour copier un fichier à partir d'un ordinateur sur un autre avec SSH, vous devrez utiliser la commande **scp**. Cela ressemblera à ceci :
+[[:tutoriel:comment_installer_un_paquet|Installez le paquet]] **[[apt>openssh-server|openssh-server]]** sur votre poste.
-  scp <fichier> <username>@<ipaddress>:<DestinationDirectory>
-  scp -6 <élément> <nom>@[addresse ipv6]:<destination>
-\\
-Ou en termes profanes, si je désirais copier un fichier d'un de mes ordinateurs à l'autre, je procède de cette manière :
+=== Utilisation du serveur SSH ===
-  scp fichier.txt hornbeck@192.168.1.103:/home/hornbeck
+Le serveur SSH fonctionne en tant que [[:services|service]] lancé automatiquement au démarrage de la machine.\\
-  scp -6 fichier.txt albertine@[2a01:e35:2431::2a34]:/home/albertine
+Il est possible notamment de :
-\\
+  * L'[[#activer]] ou l'[[#arrêter]] : par exemple si vous souhaitez désactiver momentanément le serveur SSH
+  * Le [[#relancer]] : par exemple si vous faites une modification de configuration
-Ou copier un répertoire vers un ordinateur :
+Vous trouverez en fin de cette page plus d'information sur la [[#Configuration du serveur SSH]], peu sécurisée par défaut.
-  scp -r répertoire hornbeck@192.168.1.103:/home/hornbeck/
-  scp -6r répertoire/ albertine@[2a01:e35:2431::2a34]:/home/albertine
-\\
-Vous pouvez aussi bien copier des fichiers à partir des ordinateurs à distance sur votre disque local :
+== Vérifier le status  ==
-  scp hornbeck@192.168.1.103:/home/hornbeck/urls.txt .
+Saisissez dans un [[:terminal]] la [[:commande_shell|commande]] suivante :
-\\
+<code bash>sudo systemctl status ssh</code>
-Le point à la fin de commande indique de copier le fichier dans le répertoire courant. Vous pouvez aussi le renommer en le copiant (« mon.txt ») sur le disque local :
+== Activer ==
-  scp hornbeck@192.168.1.103:/home/hornbeck/urls.txt ./mon.txt
+Saisissez dans un [[:terminal]] la [[:commande_shell|commande]] suivante :
-\\
+<code bash>sudo systemctl start ssh</code>
-Vous pouvez très bien copier un fichier d'un ordinateur vers un autre tout en étant sur un troisième ordinateur :
+== Arrêter ==
-  scp nom@ordi1:chemin/fichier nom@ordi2:chemin/fichier
+<code bash>sudo systemctl stop ssh</code>
-\\
+== Relancer ==
+<code bash>sudo systemctl restart ssh</code>
+==== Installation du client SSH ====
-===== Navigation via sftp (secure file transfer protocol) =====
+Sur le poste client **openssh-client** est déjà installé par défaut. Dans le cas contraire [[:tutoriel:comment_installer_un_paquet|Installez le paquet]] **[[apt>openssh-client]]**.\\
+== Clients pour machines qui ne sont pas sous Linux ==
+<note tips>
+Sous windows10 vous pouvez installer une Ubuntu via [[wpfr>Windows_Subsystem_for_Linux|WSL]], vous aurez alors accès à un vrai client SSH :)
+</note>
-==== Nautilus ====
+Si vous devez prendre le contrôle depuis un poste équipé de Windows vous pouvez installer [[http://www.chiark.greenend.org.uk/~sgtatham/putty/|PuTTY]] qui est disponible sous licence MIT (une licence libre comparable à la licence BSD), openssh est installable dans le shell Windows depuis la version 1809 https://docs.microsoft.com/fr-fr/windows-server/administration/openssh/openssh_install_firstuse.
-En utilisant le navigateur de fichier [[:Nautilus]], vous pouvez également accéder aux emplacements à distance par l'intermédiaire de SSH pour passer en revue, éditer et copier, des fichiers. Ouvrez Nautilus, puis dans la fenêtre emplacement (Ctrl--L), entrez l'URL suivante (remplacez ''username'', ''hostname'' et ''port'' en conséquence) :
+Si vous voulez établir une connexion SSH depuis un smartphone Blackberry(r), vous pouvez installer [[http://bbssh.org/|bbssh]], qui est sous licence libre GPLv2, les sources sont fournies.
-   ssh://username@hostname:port
+Il existe aussi des clients SSH pour Android (connectbot), J2ME (téléphones portables Java), iPhone, et quasiment tous les systèmes d'exploitation trouvables.
-La copie de fichier se fait avec le glisser-déposer dans la fenêtre de Nautilus comme sur votre système de fichier local.
+<note tip>Vérifiez bien que [[:UFW]], le gestionnaire de firewall standard sous Ubuntu, n'est pas actif sur le __serveur SSH__ **AVANT** l'installation de SSH. Il ne devrait pas fonctionner si vous ne l'avez pas activé.\\
+Si UFW est actif,  vous avez intérêt à vérifier s'il laisse passer le port standard du protocole SSH, le 22. Si ce n'est pas le cas, vous ne pourrez pas utiliser SSH sur cette machine.\\
+Voyez la page [[:UFW]] pour connaître le fonctionnement du pare-feu, ou, utilisez [[:gufw|Gufw]] l'interface graphique du pare-feu UFW.
+</note>
-Pour accéder directement à un répertoire donné (pratique avec l'utilisation des signets), il suffit de rajouter le chemin en fin d'URL :
+===== Utilisations de SSH=====
-   ssh://username@hostname:port/le/chemin/voulu/
+==== Accès à distance à la console en ligne de commande (shell ssh) ====
-Il est également possible d'y avoir accès dans Nautilus par : fichier > se connecter à un serveur et choisir type de service : ssh.
+Pour ouvrir une session distant ayant un serveur SSH, vous devez écrire quelque chose comme ceci :
+<code>ssh <nom_utilisateur>@<ipaddress> -p <num_port></code>
+__Exemple__ :
+<code>ssh phyrex@192.168.23.42 -p 12345</code>
+L'option **-p <num_port>** qui précise le port utilisé par le serveur est facultative. Si rien n'est précisé, c'est le port 22 qui sera utilisé par défaut (protocole TCP).
+Pour se connecter avec SSH en IPV6 depuis un terminal, écrire sans crochet :
+<code>ssh -6 <nom_utilisateur>@<adresse ipv6> </code>
+__Exemple__ :
+par exemple pour un lien Internet :
+<code>ssh -6 alfred@2a01:e35:2431::2e57</code>
-==== Konqueror ====
-Le principe est similaire à celui utilisé  par Nautilus, à l'exception du nom de protocole : ''fish''.
+<note tip>
-Dans la barre d'adresse, tapez :
+Vous pouvez aussi appeler un ordinateur par son nom :
+<code>ssh utilisateur@nom_machine</code>
+à partir du moment où celui-ci est résolu en adresse IP par votre machine.
-  fish://<username>@<hostname>
+Cela peut se faire sur le réseau local par le fichier **/etc/hosts**  (ou bien, pour passer par une interface graphique, en tapant dans un terminal  <code>network-admin</code> puis en allant dans l'onglet "Hôtes", continuer en déverrouillant les droits administration en cliquant sur le cadenas, et enfin, en cliquant sur le bouton "ajouter"), éventuellement distribué d'un serveur vers les clients locaux au travers de [[wpfr>Network_Information_Service|NIS]], ou bien par un service de [[wpfr>Domain_Name_System|DNS]] si vous accédez à une machine distante (serveur loué) pour lequel vous avez enregistré un nom de domaine.
+</note>
+<note tip>Si vous voulez vous connecter à plusieurs machines situées derrière un routeur vous pouvez configurer celui-ci afin qu'il redirige chaque port TCP entrant vers une machine donnée.\\ __Exemple__ :\\ port externe 22001 redirigé vers 192.168.0.1:22\\
+port externe 22002 redirigé vers 192.168.0.2:22\\ Ensuite utilisez l'option -p 22002 pour connecter par exemple la machine ayant pour adresse 192.168.0.2 sur le réseau local</note>
-Une boite de dialogue apparaitra et demandera le mot de passe.
+==== Outil graphique pour les connexions SSH ====
-Attention, si vous ne mentionnez pas le nom d'utilisateur, c'est l'utilisateur courant sur la machine locale qui aura la main.
+[[:remmina|Remmina]] est actuellement l'outil le plus complet pour la gestion des bureaux à distance.
-==== Console ====
+==== Affichage graphique déporté (Tunneling serveurX par ssh) - Accéder aux applications graphiques ====
-Pour pouvoir parcourir vos fichiers accessibles par SSH, il vous faut monter un système de fichier. Visitez la doc prévue à cet effet : [[:sshfs|SSH Filesystem]].
+La commande ssh offre une fonctionnalité intéressante: la possibilité d'exécuter des applications X-Window à distance, ce qui est bien pratique pour travailler à distance, partager une machine ou simplement effectuer des tâches d'administration.
-Remarque : cette méthode permet aussi d'y accéder de manière transparente avec Nautilus ou [[:Konqueror]] sans utiliser les adresses spéciales précédentes.
+Il suffit de passer l'option -X à ssh :
+<code>ssh -X nomtilisateur@Ipserver</code>
+<note>L'option **-X** permet le déport d'applications X-Window (affichage graphique à distance). Cette possibilité est offerte grâce aux fonctions de tunneling réseau présentes dans SSH. N'oubliez pas qu'Ubuntu (Unix en général) est un système d'exploitation client/serveur, ce qui s'applique aussi à l'affichage géré par X-Window.</note>
-==== WinSCP ====
+Et on peut lancer :
+<code>nomUtilisateur@Ipserver$ xeyes</code>
-Parce qu'il est parfois nécessaire de faire un transfert de fichier à partir d'une machine sous MS Windows, il existe un logiciel libre nommé WinSCP qui permet de faire du SFTP (transfert de fichier par SSH) avec une interface semblable à celle des clients FTP.
+là, l’œil de Moscou vous regarde depuis votre écran local ! \\
+N.B. : pour que cet exemple fonctionne il faut que le paquet //x11-apps// qui fournit //xeyes// soit installé sur le serveur.
-[[http://winscp.net/eng/docs/lang:fr|Site officiel du logiciel WinSCP]]
+<note important>Pour que vous puissiez afficher des applications X11 via SSH il faut que votre serveur ait la fonction "X11Forwarding" activée et que xauth y soit installé ! Allez [[#configuration_du_serveur_ssh|À la fin de cette page]] pour savoir comment configurer votre serveur SSH.</note>
-==== Filezilla ====
-Sans avoir à chercher trop loin, [[filezilla|FileZilla]], le client FTP compatible Linux, Windows et Mac OS X, permet aussi la connexion à un serveur SFTP (SSH File Transfer Protocol) depuis la version 3.
+==== Transfert - copie de fichiers ====
-===== Monter un répertoire distant en utilisant sshfs =====
+Pour copier un fichier à partir d'un ordinateur sur un autre avec SSH, vous devrez utiliser la commande **scp** ou **rcp**. Cela ressemblera à ceci :
+<code>scp <fichier> <username>@<ipaddressDistant>:<DestinationDirectory></code>
+et en IPv6
+<code>scp -6 <élément> <nom>@[addresse ipv6]:<destination></code>
-**sshfs** est un outil permettant d'utiliser le protocole **ssh** comme un système de fichier et ainsi monter un répertoire distant à travers le protocole ssh.
+==Exemples ==
-Pour l'utiliser il vous suffit, pour cela, d'[[:tutoriel:comment_installer_un_paquet|installer le paquet]] ** [[apt://sshfs|sshfs]] **
+//__Pour un fichier:__//
-  sshfs <username>@<ipaddress>:/RepertoireDistant /Emplacement de montage
+<code>scp fichier.txt hornbeck@192.168.1.103:/home/hornbeck</code>
+et en IPv6
+<code>scp -6 fichier.txt albertine@[2a01:e35:2431::2a34]:/home/albertine</code>
+//__Pour un répertoire:__//
-===== Se connecter à un ordinateur distant via SSH =====
+<code>scp -r répertoire hornbeck@192.168.1.103:/home/hornbeck/</code>
+et en IPv6
+<code>scp -6r répertoire/ albertine@[2a01:e35:2431::2a34]:/home/albertine</code>
-Pour ouvrir une session sur un ordinateur distant ayant un serveur SSH, vous devez écrire quelque chose comme ceci :
+Vous pouvez aussi bien copier des fichiers à partir des ordinateurs à distance sur votre disque local :
+<code>scp hornbeck@192.168.1.103:/home/hornbeck/urls.txt .</code>
-  ssh <username>@<ipaddress> -p <num_port>
+Ici, le point **.** à la fin de commande indique de copier le fichier dans le répertoire courant.
-Exemple
-ssh phyrex@192.168.23.42 -p 12345
-L'option **-p xxx** est facultative. Si rien n'est précisé, c'est le port 22 par défaut qui sera utilisé.
- Pour se connecter avec ssh en ipv6 depuis un terminal, écrire sans crochet
-  ssh -6 <nom>@<adresse ipv6>
-soit par exemple pour un lien internet:
-ssh -6 alfred@2a01:e35:2431::2e57
 <note tip>
-Vous pouvez aussi appeler un ordinateur par son nom
+Pour les noms avec des espaces :
-  ssh utilisateur@nom_machine
+de distant vers local
-a partir du moment ou celui ci est résolu par votre machine.
+<code>
+$ scp utilisateur@12.345.678.90:"le\ fichier" .
+$ scp utilisateur@12.345.678.90:'"le fichier"' .
+# Notez les simples ' ET doubles " guillemets ' "
+</code>
+<code>
+$ fichier="le fichier" #ou
+$ fichier=le\ fichier
+$ scp utilisateur@12.345.678.90:"'$fichier'" .
-Cela peut se faire sur le réseau local par le fichier **/etc/hosts**, éventuellement distribué d'un serveur vers les clients locaux au travers de NIS , ou bien par un service de DNS si vous accédez à une machine distante (serveur loué) pour lequel vous avez enregistré un nom de domaine.
+$ fichier="le\ fichier"
+$ scp utilisateur@12.345.678.90:"$fichier" .
+</code>
 </note>
+<note>
+Pour les noms avec des espaces :
-==== se connecter en ssh à travers un proxy http ====
+de local vers distant c'est différent
+<code>
+$ scp  le\ fichier utilisateur@12.345.678.90:
+le fichier                          100%    0     0.0KB/s   00:00
-Il peut arriver (en entreprise, dans un cyber...) qu'il y ai un proxy http. Pour initier une connexion vers un poste de l'extérieur il est nécessaire d'utiliser l'outils connect-proxy.
+$ scp  "le fichier" utilisateur@12.345.678.90:
+le fichier                          100%    0     0.0KB/s   00:00
+</code>
+<code>
+$ fichier="le fichier"  # ou
+$ fichier=le\ fichier
+$ scp  "$fichier" utilisateur@12.345.678.90:
+le fichier                          100%    0     0.0KB/s   00:00
+</code>
+cf : https://forum.ubuntu-fr.org/viewtopic.php?pid=21768296#p21768296
+</note>
-[[tutoriel:comment_installer_un_paquet|Installer le paquet]] [[apt://connect-proxy]]
+Vous pouvez aussi le renommer en le copiant (« mon.txt ») sur le disque local (toujours dans le répertoire courant):
+<code>scp hornbeck@192.168.1.103:/home/hornbeck/urls.txt ./mon.txt</code>
-[[tutoriel:comment_modifier_un_fichier|éditer le fichier]] ~/.ssh/config pour y ajouter les adresses ip exterieur:
+Vous pouvez très bien copier un fichier d'un ordinateur vers un autre tout en étant sur un troisième ordinateur :
+<code>scp nom@ordi1:chemin/fichier nom@ordi2:chemin/fichier</code>
-  host ip_du_pc_distant
+Dans le cas où le port SSH du serveur ne serait pas le port par défaut (22), il faut indiquer le port distant à utiliser :
-  ProxyCommand /usr/local/bin/connect -H adresse.du_proxy:port %h %p
+<code>scp -P port fichier.txt hornbeck@192.168.1.103:/home/hornbeck</code>
-Remplacer ip_du_pc_distant et adresse.du_proxy:port par ce qui convient. Vous pouvez maintenant vous connecter à travers votre proxy en toute transparence, avec la commande ssh.
+<note important>Lorsque l'on copie des fichiers ou des répertoires sur d'autres machines, ne pas oublier que les fichiers ou répertoires deviendront propriété du compte avec lequel on se connecte à distance. Pour préserver les propriétaire et groupe de chaque fichier ou répertoire, il sera donc utile de recourir à un logiciel tel que [[:tar|tar]] pour enregistrer l'intégralité des informations relatives à ce que l'on transfère.</note>
+==== Transfert - synchronisation de répertoire ====
+Vous pouvez sécuriser un répertoire en le dupliquant à travers le réseau en utilisant la commande [[:rsync|rsync]].
-===== Authentification par mot de passe =====
+Exemple1: Pour transférer le home d'un utilisateur **a**  hébergé dans la machine **b** dont l'adresse IP est enregistrée dans le  fichier [[:hosts|/etc/hosts]] en excluant quelques fichiers avec un résultat  à mettre dans le répertoire /MAISON qui sera automatiquement créé.
+<code bash> sudo rsync -ahv --progress --stats --exclude={'.*','persistence.*'}  a@b:/home/a /MAISON 2>err.log
+cat err.log</code>
-L'authentification par mot de passe (transmis chiffré) est le mode d'identification par défaut.
-Suite à l'installation du paquet **openssh-server** il peut parfois être nécessaire de modifier le fichier de configuration « sshd_config » notamment si vous rencontrez le problème suivant :
+==== Monter un répertoire distant, navigation via SFTP (Secure File Transfer Protocol) ====
-  moi@maison:~$ ssh user@domain.com
+[[wpfr>SSH_file_transfer_protocol|SFTP]] est une autre méthode pour accéder à ses fichiers via SSH. Au lieu de travailler fichier par fichier, il est possible grâce à cette méthode de naviguer dans ses fichiers depuis un client SFTP. Ce type d'accès est possible grâce à des outils comme [[#Nautilus]], [[#Konqueror]], [[#Dolphin]], [[#WinSCP]], [[#Pcmanfm]]  ou [[#FileZilla]], dont la mise en œuvre est décrite dans les sections suivantes.
-  Permission denied (publickey).
-Dans ce cas, il faut très basiquement [[:tutoriel:comment_editer_un_fichier|modifier le fichier]] « /etc/ssh/sshd_config » de la manière suivante :
+=== Nautilus ===
-<file>
-# Change to yes to enable tunnelled clear text passwords
-PasswordAuthentication yes
-</file>
-Puis en cas de modifications, redémarrer le service avec la commande :
+En utilisant le [[:gestionnaire de fichiers]] **[[:Nautilus]]**, vous pouvez également accéder aux emplacements à distance par l'intermédiaire de SSH pour passer en revue, modifier et copier des fichiers.\\
+Ouvrez Nautilus, puis dans la fenêtre emplacement (Ctrl + L), entrez l'URL suivante en remplaçant ''nom_utilisateur'', ''hostname'' et ''port'' en conséquence :
+<code>ssh://nom_utilisateur@hostname:port</code>
-  sudo /etc/init.d/ssh restart
+La copie de fichier se fait avec le glisser-déposer dans la fenêtre de Nautilus comme sur votre système de fichiers local.
+Pour accéder directement à un répertoire donné (pratique avec l'utilisation des signets), il suffit de rajouter le chemin en fin d'URL :
+<code>ssh://username@hostname:port/le/chemin/voulu/</code>
-===== Authentification par un système de clés publique/privé =====
+Il est également possible d'y avoir accès dans Nautilus par  le menu //Fichiers -> Autres emplacements -> Se connecter à un serveur...// et choisir le ''Type de service'' « ssh ».
-<note importante>
+=== Dolphin ou Konqueror ===
-Au mois de Mai 2008 a été découvert une faiblesse dans la génération des clés par OpenSSL des packages Debian et dérivés tels qu'Ubuntu.
-Voir la partie "Correction vulnérabilité SSH" pour plus de détails mais en gros si vous avez généré vos clés sur Ubuntu entre 2006 et Mai 2008, il faut régénérer de nouvelles clés après avoir mis a jour le système...
-</note>
-Autrefois tout le monde employait l'authentification typique //via// identifiant-mot de passe. Cependant si quelqu'un connaît votre mot de passe, la sécurité est compromise.
+Le principe est similaire à celui utilisé par [[#Nautilus]], à l'exception du nom de protocole : ''sftp''.\\
+Dans la barre d'adresse, tapez :
+<code>sftp://<nom_utilisateur>@<hostname></code>
+Une boîte de dialogue apparaîtra et demandera le mot de passe.
-Pour être débarrassé du problème, SSH offre l'**Authentification par clé publique/privée** au lieu des mots de passe « simples ». De cette manière, il faut être en possession de non plus une mais de deux informations pour se connecter (avoir la clé privée & connaître le mot de passe de cette clé).
+**Attention:** Si vous ne mentionnez pas le nom d'utilisateur, c'est l'utilisateur courant sur la machine locale qui aura la main.
-Ceci peut permettre par exemple :
+=== Dolphin  ===
-  * à un administrateur de se connecter à des centaines de machines sans devoir connaître des centaines de mots de passe différents ;
-  * de ne pas avoir un mot de passe à saisir toutes les 2 minutes (en utilisant //ssh-agent//).
-À moins que vous n'ayez déjà un couple de clés, vous devez d'abord en créer : exemple pour une clé utilisant le protocole de cryptage DSA.
+Le nouveau navigateur de [[:KDE]] permet de faire ça très simplement.\\
-Tapez chez le client :
+Cliquez sur le raccourci ''Réseau'', puis ''Ajoutez un dossier réseau''. Remplissez ensuite les champs demandés. Pensez à mettre la racine (dossier **/**) comme dossier d'accès pour pouvoir rentrer sur l'intégralité de l'ordinateur distant.
-  ssh-keygen -t dsa
+Il est également possible de rentrer l'adresse et d'enregistrer le lien dans ses emplacements favoris :
+<code>sftp://nom_utilisateur@hostname:port</code>
-Il vous sera alors demandé où sauver la clé privée (acceptez juste l'endroit par défaut : ~/.ssh, et ne changez pas le nom) puis de choisir une //passphrase//. Bien que non obligatoire, l'utilisation d'une //passphrase// est recommandé pour protéger votre clé privée. En effet toute personne qui obtiendrait l'accès à votre clé privée (non protégée) aurait alors vos permissions sur d'autres ordinateurs. Veuillez prendre un instant et choisissez une très bonne //passphrase//.
+=== WinSCP ===
-Votre clef publique a été créée avec la nouvelle clé privée. Elles sont habituellement localisées dans le dossier caché : « ~/.ssh/id_dsa.pub » pour la clé publique et « ~/.ssh/id_dsa » pour la clé privé.
+Parce qu'il est parfois nécessaire de faire un transfert de fichier à partir d'une machine sous MS Windows, il existe un logiciel libre nommé ''WinSCP'' qui permet de faire du SFTP avec une interface semblable à celle des clients FTP.
-Il faut maintenant envoyer au serveur votre clé publique pour qu'il puisse vous crypter des messages.
+[[https://winscp.net/eng/docs/lang:fr|Site officiel du logiciel WinSCP]]
-L'utilisateur distant doit avoir cette clé (c'est une ligne de caractères en code ASCII) dans son fichier de clé d'autorisation situé à « ~/.ssh/authorized_keys » sur le système distant. Employez la commande //ssh-copy-id//.
+=== FileZilla ===
-ssh-copy-id est un script qui utilise ssh pour se connecter à une machine à distance en utilisant le mot de passe de l'utilisateur. L'authentification par mot de passe "PasswordAuthentication yes" doit donc être autorisée dans le fichier de configuration du serveur ssh (par défaut sur ubuntu). Il change également les permissions des répertoires : ~/.ssh, et ~/.ssh/authorized_keys de l'hôte distant pour enlever l'accès en écriture du groupe (qui vous empêcherait de vous connecter si le serveur distant ssh a "StrictModes yes" dans son fichier de configuration, ce qui est le cas par défaut sur ubuntu).
+Sans avoir à chercher trop loin, [[:filezilla|FileZilla]], le client FTP compatible Linux, Windows et Mac OS X, permet aussi la connexion à un serveur SFTP (SSH File Transfer Protocol) depuis la version 3.
+=== PCManFM ===
-  ssh-copy-id -i ~/.ssh/id_dsa.pub <username>@<ipaddress>
+Dans la barre d'adresse de [[:PCManFM|PCManFM]], rentrez ceci :
+<code>sftp://nom_utilisateur_distant@IPduSERVEUR/dossier/que/je/veux</code>
-ou si le port est différent du port standard 22
+==== Monter un répertoire distant de manière automatique (SFTP grâce à SSHFS) ====
-  ssh-copy-id -i ~/.ssh/id_dsa.pub "-p <num_port> <username>@<ipaddress>"
+**SSHFS** est un outil permettant d'utiliser le protocole **SSH** comme un système de fichier et ainsi monter un répertoire distant à travers le protocole SSH pour y accéder comme n'importe quel répertoire local à la manière d'un partage [[:nfs|NFS]]; mais sécurisé ! \\
+Voir la page [[:sshfs|SSH Filesystem]].
-Vous devrez alors donner le mot de passe //utilisateur// de cet ordinateur.
+===== Authentification  =====
-Après que votre clé publique ait été ajoutée, vous devenez un hôte de confiance.
-Si l'authentification par mot de passe est désactivée, alors vous aurez besoin de copier-coller votre clé suivant un autre moyen.
+<note warning>Si vous ouvrez votre serveur SSH sur Internet, par exemple pour y accéder depuis l'ordinateur d'un ami(e) ou lui permettre d'accéder à certains de vos fichiers, n'oubliez JAMAIS qu'Internet est parcouru par des robots qui scannent et testent en permanence tous les serveurs disponibles (SSH et autres) et qu'ils vont faire des tentatives pour trouver vos mots de passe de compte (on parle d'[[wpfr>attaque par force brute]]). L'usage des clés est donc très fortement recommandé.
-Voici une ligne à copier pour ajouter sa clé publique sur le serveur distant :
+Si vous ne pouvez vraiment pas faire autrement, utilisez des mots de passe longs et complexes ainsi qu'un système de protection tel que [[:fail2ban]] qui permet de bannir des adresses IP au bout d'un certain nombre de tentatives erronées.\\
+Voir aussi [[:denyhosts]] notamment en cas de:
+<code>ssh_exchange_identification: read: Connection reset by peer</code></note>
-  ssh login@serveur "echo $(cat ~/.ssh/id_dsa.pub) >> .ssh/authorized_keys"
+==== Authentification par mot de passe ====
-Lancez :
+L'authentification par mot de passe (transmis chiffré) est le mode d'identification par défaut.
-  ssh <username>@<ipaddress> -p <num_port>
-Dorénavant n'utilisez plus votre mot de passe mais votre **passphrase** pour vous connecter. Il y a une différence entre votre mot de passe et la passphrase. Le mot de passe est situé dans ''/etc/passwd'' du système distant alors que la **passphrase** sert à déchiffrer votre //clé privée// de votre système local.
+==== Authentification par un système de clés publique/privée ====
-Si ça ne marche pas, c'est à dire que le mot de passe vous est quand même demandé, essayez sur votre serveur la commande :
+=== Description ===
+Autrefois tout le monde employait l'authentification typique par le principe //identifiant - mot de passe//. Cependant si quelqu'un connaît votre mot de passe ou le découvre au moyen d'une attaque la sécurité est compromise. De plus, utiliser un mot de passe différent pour chaque serveur et le saisir à chaque connexion peut s'avérer contraignant.
-  tail -f /var/log/auth.log
+Pour se débarrasser des ces problèmes, SSH propose un système d'authentification par clé publique/privée au lieu des mots de passe « simples ».
+Ceci peut permettre par exemple :
+  * à un administrateur de se connecter à des centaines de machines sans devoir connaître des centaines de mots de passe différents ;
+  * de ne pas avoir un mot de passe à saisir toutes les 2 minutes (en utilisant //ssh-agent//).
-tandis que vous essayez de vous connecter.
+Ces clés restent des chaînes de caractères (en français courant : du texte), mais sont beaucoup plus longues et aléatoires que de simples mots de passe.
-Si on vous parle de "//vulnkey//", c'est que par malchance ssh-keygen a généré une clé vulnérable. Recommencez alors la manipulation à partir de ssh-keygen...
+La clé privée est en principe unique : chaque utilisateur possède une clé privée qu'il peut copier sur les terminaux auxquels il accède physiquement et depuis lesquels il a besoin d'un accès SSH (via le client SSH). Cette clé se trouve généralement dans un fichier ''~/.ssh/id_xxxx''. C'est un document sensible très personnel, il faut y appliquer des droits très restrictifs : ''r-x --- ---'' (500) pour le répertoire .ssh et ''r-- --- ---'' (400) pour le fichier id_xxxx.\\
+Pour un maximum de sécurité il est possible de protéger cette clé privée au moyen d'un mot de passe.
+De son côté la clé publique est envoyée à tous les serveurs auxquels on veut accéder à distance afin qu'ils nous identifient avec certitude en vérifiant que le client possède bien la clé privée associée. Côté serveur cette clé publique sera stockée dans le fichier ''~/.ssh/authorized_keys'', avec éventuellement des options et les clés publiques d'autres utilisateurs à raison d'une par ligne.
+Localement on peut stocker une clé publique par ex. dans un fichier ''id_xxxx.pub'' qui peut aussi se trouver dans le répertoire ''~/.ssh'', ou ailleurs (ce n'est pas un document sensible).
-Pour reprendre, deux choses sont nécessaires pour obtenir un accès réellement sécurisant (et sécurisé ;-) ) par authentification à clé publique par rapport à l'authentification par mot de passe classique :
+On peut générer une nouvelle clé publique depuis une clé privée mais pas l'inverse.
-  - **Votre clé privée**, chiffrée ;
-  - **Votre passphrase**, utilisée pour déchiffrer votre clé privée.
+=== Mise en place des clés ===
-Si vous choisissez de ne pas avoir de mot de passe (ce qui est possible, voyez la prochaine section), vous aurez une sécurité moindre, ainsi que si vous utilisez une authentification uniquement par mot de passe, comparé à celle que vous pouvez avoir en combinant les deux.
+À moins que vous n'ayez déjà un couple de clés, vous devez d'abord en créer.\\
+Exemple pour une clé utilisant l'algorithme de chiffrement ED25519, vous saisirez dans le [[:terminal]] du client :
+<code>ssh-keygen -t ed25519 -C "email@example.com"</code>
-<note>
+On peut également utiliser l'algorithme plus ancien, moins sûr et générant des clés plus grosses RSA :
-Vous pouvez vouloir neutraliser l'authentification par mot de passe pour des raisons de sécurité en plaçant dans le fichier de configuration « /etc/ssh/sshd_config » la ligne « PasswordAuthentication » à « no » (et ne **pas** avoir « UsePAM » à « yes » !, ou autrement dit en mettant également « UsePAM » à « no »). N'oubliez pas de relancer votre serveur **sshd** après avoir changé la configuration :
+<code>ssh-keygen -t rsa  -b 4096 -C "email@example.com"</code>
-  sudo /etc/init.d/ssh restart
-</note>
+Il vous sera alors demandé où enregistrer la clé privée (acceptez juste l'endroit par défaut : **~/.ssh**, et ne changez pas le nom du fichier généré) puis de choisir une //passphrase// (phrase de reconnaissance).
+<note warning>Bien que non obligatoire, l'utilisation d'une //passphrase// est recommandée pour protéger votre clé privée. En effet toute personne qui obtiendrait l'accès à votre clé privée (non protégée) aurait alors vos permissions sur d'autres ordinateurs. Veuillez prendre un instant et choisissez une très bonne //passphrase// c'est à dire longue et complexe.</note>
-<note>
+Votre clef publique a été créée avec la nouvelle clef privée. Elles sont habituellement localisées dans le [[:fichier_cache|dossier caché]] **~/.ssh**:
-Si après avoir suivi ce tutoriel un mot de passe est toujours demandé, il se peut que ce soit dû à un problème de droits sur votre 'home directory'.
-Sur la machine distante regardez le fichier :
-  tail /var/log/auth.log
-Plus d'indications vous seront donné dedans, et si la ligne suivante apparait :
-  Authentication refused: bad ownership or modes for directory /home/votre_login
-Alors faites :
-  chmod 755 $HOME
-Et tout devrait rentrer dans l'ordre.
-Si ce n'est toujours pas le cas, c'est que le serveur doit être configuré en mode de sécurité strict (c'est le cas par défaut sur UBUNTU), on peut avoir des problèmes à se connecter sans mot de passe.
+**~/.ssh/id_ed25519.pub** pour la clé publique et **~/.ssh/id_ed25519** pour la clé privée ou **~/.ssh/id_ras.pub** et **~/.ssh/id_rsa** si vous avez utilisé l'algorithme RSA.
-Sur le serveur dans /etc/ssh/sshd_config , la ligne "StrictModes yes" indique que le serveur va être très pointilleux sur les droits du compte sur lequel on se connecte en ssh.
-Sur le client, dans  /etc/ssh/ssh_config, rajoutez la ligne "PreferredAuthentications publickey"
-  server$ chmod go-w ~/
-  server$ chmod 700 ~/.ssh
-  server$ chmod 600 ~/.ssh/authorized_keys
-Pour plus de détails, consultez ces deux sites:
+Pour que votre ssh-agent reconnaisse cette paire de clefs, il faut utiliser la commande ssh-add :
+<code>ssh-add
-[[http://blog.huguesbernard.eu/post/2006/06/19/lecran-noir-sur-les-consoles-virtuelles-avec-ubuntu-et-nvidia-sur-un-Toshiba-tecra-m8]]
+#ou plus directement
+ssh-add /chemin-complet/vers-la-cle/nom-cle</code>
-[[http://sial.org/howto/openssh/publickey-auth/problems/]]
+Vous pouvez également vérifier la liste des paires de clefs existantes avec l'option -l (-list) :
+<code>ssh-add -l</code>
+<note tip>Si cette commande ressort : <code>The agent has no identities.</code> alors aucune clef n'est actuellement prise en compte. Il faut recommencer les étapes ci-dessus.
+Si vous avez : <code>Could not open a connection to your authentication agent.</code> alors faire <code>eval "$(ssh-agent)"</code> puis de nouveau <code>ssh-add</code>
 </note>
+<note tip>pistes pour débugger :
+  * forcer l'utilisation uniquement de clefs dans la commande ssh : <code>ssh -o PubkeyAuthentication=yes -o PreferredAuthentications=publickey</code>
+  * utiliser les options **-v** ou **-vv** ou **-vvv** dans le commande ssh
+</note>
+Il faut maintenant envoyer au serveur votre clé publique pour qu'il puisse vous chiffrer des messages.
-==== Authentification ssh avec plusieurs clés privées ====
+<note>**En résumé** (car les paragraphes ci-dessous utilisant des scripts peuvent sembler confus à certains)
+  * Coté client : Il faut que le client ait mis sa clé privée en $HOME/.ssh/ (côté client).
-Lorsque que l'on se connecte à plusieurs serveur, certains avec clé cryptée, d'autre avec clé en clair, il faut pouvoir indiquer à ssh quelle clé on veut utiliser pour la connexion.
+  * Coté client : la clé doit être connue de l'agent ssh (ssh-add)
+  * Coté client : Le répertoire $HOME/.ssh doit appartenir au propriétaire de $HOME et les clés privées ne doivent être accessibles que par leur propriétaire (mode %%rw------%% ou 600 au maximum)
-Pour indiquer au client ssh la clé qu'il doit utiliser pour chacun des serveurs il faut créer le fichier ~/.ssh/config (ou /etc/ssh/ssh_config pour tous les utilisateurs de la machine) dans lequel il faut spécifier pour chacun des serveurs la clé qui doit être utilisée :
+  * Coté serveur : La clé publique du client doit se trouver dans le fichier $HOME/.ssh/authorized_keys du serveur.
+  * Coté serveur : il vaut mieux refuser l'accès par mot de passe ("PasswordAuthentication no" dans /etc/ssh/sshd_config du serveur)
-  Host adresse-server-sans-passphrase.com
-  IdentityFile ~/.ssh/key-sans-passphrase
-  Host adresse-server-avec-passphrase.com
-  IdentityFile ~/.ssh/key-avec-passphrase
-<note tip>
-Pour plus d'options, comme l'utilisateur ou le port à utiliser par défaut, voir la commande **man ssh_config**
 </note>
-===== Restriction d'accès SSH =====
+L'utilisateur distant doit avoir cette clé (c'est une ligne de caractères en code ASCII) dans son fichier de clés d'autorisation situé à **~/.ssh/authorized_keys** sur le système distant. Employez la commande //ssh-copy-id//.
-Quand on utilise SSH avec l'authentification par clé, il y a d'autres dispositions. Le serveur distant peut limiter l'utilisation de certaines commandes permises. Si vous maintenez un dépôt CVS, vous pourriez utiliser des lignes comme ceci dans le fichier « authorized_keys2 » :
+//ssh-copy-id// est un script qui utilise ssh pour se connecter à une machine à distance en utilisant le mot de passe de l'utilisateur. L'[[#authentification par mot de passe]] doit donc être autorisée dans le fichier de configuration du serveur ssh (par défaut sur Ubuntu). Il change également les permissions des répertoires **~/.ssh** et **~/.ssh/authorized_keys** de l'hôte distant pour enlever l'accès en écriture du groupe (qui vous empêcherait de vous connecter si le serveur distant ssh a "StrictModes yes" dans son fichier de configuration, ce qui est le cas par défaut sur Ubuntu).
+<code>ssh-copy-id -i ~/.ssh/id_ed25519.pub <username>@<ipaddress></code>
+ou si le port est différent du port standard 22 ([[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=99785|notez les guillemets]]):
+<code>ssh-copy-id -i ~/.ssh/id_ed25519.pub -p <num_port> "<username>@<ipaddress>"</code>
-  command="/usr/bin/cvs server" ssh-dss AAAAB3N....
+Vous devrez alors donner le mot de passe //utilisateur// de cet ordinateur. Après l'ajout votre clé publique, vous devenez un hôte de confiance.
-Ceci permettrait que seule cette commande puisse être utilisée. Rien d'autre.
+Si l'[[#authentification par mot de passe est désactivée]]((donc PasswordAuthentication **no** dans **/etc/ssh/sshd_config** sur le serveur)) , alors vous aurez besoin de copier-coller votre clé suivant un autre moyen.\\
+Voici une ligne à copier pour ajouter sa clé publique sur le serveur distant :
+<code>ssh login@serveur "echo $(cat ~/.ssh/id_id_ed25519.pub) >> .ssh/authorized_keys"</code>
+Lancez :
+<code>ssh <username>@<ipaddress> -p <num_port></code>
+Dorénavant n'utilisez plus votre mot de passe mais votre **passphrase** pour vous connecter. Celle-ci sert à déchiffrer votre //clé privée// de votre système local.
+Si ça ne marche pas, c'est-à-dire que le mot de passe vous est quand même demandé, essayez sur votre serveur la commande :
+<code>tail -f /var/log/auth.log</code>
+tandis que vous essayez de vous connecter. Si on vous parle de "//vulnkey//", c'est que par malchance ''ssh-keygen'' a généré une clé vulnérable. Recommencez alors la procédure depuis [[#Authentification par un système de clés publique/privée|le début]]((donc à partir de ''ssh-keygen''))
-===== Accès automatique pour des scripts =====
+Pour résumer, deux choses sont nécessaires pour obtenir un accès réellement sécurisant (et sécurisé ;-)) par authentification à clé publique par rapport à l'authentification par mot de passe classique :
+  - **Votre clé privée**, chiffrée ;
+  - **Votre passphrase**, utilisée pour déchiffrer votre clé privée.
-L'authentification par clé publique (voir ci-dessus) peut également être employée pour automatiser les tâches qui exigeraient habituellement l'introduction au clavier d'un mot de passe. Imaginez vouloir copier un dossier à partir d'un ordinateur distant tous les jours à minuit. Tout ce que vous avez à faire c'est d'établir la confiance entre ces deux ordinateurs. Créez un compte de service sur un ordinateur, créez une paire de clé (''ssh-keygen -t dsa'') et quand on vous demande de rentrer la //passphrase// taper juste sur la touche « Entrée ». Ceci fera que votre clé privé ne sera pas protégée. Ajoutez la clé publique de l'autre ordinateur dans le fichier « authorized_keys » (« ssh-copy-id »). Maintenant vous pouvez utiliser SSH sur cette machine sans une //passphrase// à taper. Ajoutez une référence à SSH dans votre //crontab// et vous êtes prêt.
+Si vous choisissez de ne pas avoir de mot de passe (ce qui est possible, voyez la prochaine section), vous aurez une sécurité moindre, ainsi que si vous utilisez une authentification uniquement par mot de passe, comparé à celle que vous pouvez avoir en combinant les deux.
-<note importante>
+=== Éléments importants en lien avec l'usage des clés ===
-Avoir une clef privée non protégée peut être un trou de sécurité. Les intrus devront seulement obtenir l'accès à la clé privée et pourront accéder aux ordinateurs distants.
-</note>
+== Authentification par mot de passe et / ou par clé ==
+Vous pouvez avoir avec SSH les deux modes d'authentifications actifs en même temps, par mot de passe et par clés.
+Vous pouvez vouloir neutraliser l'authentification par mot de passe pour des raisons de sécurité, pour cela il faut modifier le fichier de configuration **/etc/ssh/sshd_config** de la manière suivante :
-===== Utiliser le ssh-agent =====
+- A la ligne ''PasswordAuthentication'' mettre ''no''
-Si vous devez fréquemment copier des fichiers avec SSH ou accéder à d'autres ordinateurs de votre réseau (ce qui est une tâche commune pour des administrateurs), vous vous demandez probablement s'il y a une manière de simplifier l'utilisation de la //passphrase//. En fait il y a **SSH agent**. Vous devez seulement entrer votre //passphrase// une fois en employant **ssh-add** et tout ce que vous commencez comme sous-processus de **SSH agent** se rappellera cette passphrase.
+<note>
+N'oubliez pas de [[#relancer]] le service ssh sur votre serveur après avoir changé la configuration.
-Trop théorique ? Bien, vous n'aurez pas besoin de vous inquiéter de l'agent. Votre session X est prête pour avoir le **ssh-agent** en session automatiquement. Tout ce que vous devez faire c'est lancer **ssh-add** et saisir votre passphrase. La prochaine fois que vous utiliserez **SSH** pour accéder à un autre ordinateur, vous n'aurez pas à entrer à nouveau votre //passphrase//. Cool, non ? :-)
-<note importante>
-  * Vous devrez bloquer votre session pendant vos absences car d'autres pourraient accéder aux ordinateurs distants à partir de votre machine sans savoir votre //passphrase//.
-  * Si vous voulez rentrer votre //passphrase// une fois juste après l'ouverture de session, vous pouvez ajouter un appel à **ssh-add** comme ceci :
-    * Cliquez sur //Système → Préferences → Sessions → Programme au démarrage//.
-    * Cliquez sur « Ajouter ».
-    * Entrez la commande « ''ssh-add'' ».
-À la prochaine ouverture de session, vous devrez taper votre //passphrase//.
 </note>
-===== Le fichier de configuration du serveur SSH =====
+== Vulnérabilité des anciennes clés ==
-Par défaut, la configuration du serveur SSH ([[:tutoriel:comment_editer_un_fichier|fichier]] « /etc/ssh/sshd_config », édition //via// [[:sudo]] comme il se doit) d'Ubuntu est suffisante :<file>PermitRootLogin yes</file>
+Au mois de mai 2008 a été découvert une faiblesse dans la génération des clés par OpenSSL des packages Debian et dérivés tels qu'Ubuntu. Pour résumer, si vous avez généré vos clés entre 2006 et mai 2008, il faut en créer de nouvelles après avoir mis à jour le système. Pensez alors à bien rediffuser vos clés.
-Si ce n'était pas sous [[http://bugzilla.ubuntu.com/show_bug.cgi?id=15927|Ubuntu]] ce serait une très grosse faille de sécurité, mais qui pourrait vouloir affecter [[:sudo|un mot de passe à root]] ? ;-)
+== Mot de passe toujours demandés avec authentification par clés ==
-<file>#Banner /etc/issue.net</file>
+Si, après avoir suivi ce tutoriel, un mot de passe est toujours demandé, il se peut que ce soit dû à un problème de [[:droits]] sur votre //Dossier Personnel//.\\
+Sur la machine distante [[:tutoriel:comment_modifier_un_fichier|regardez le fichier]] **/var/log/auth.log** pour y trouver des indications et notamment si la ligne suivante apparaît :
+<file>Authentication refused: bad ownership or modes for directory /home/votre_login</file>
+Alors faites :
+<code>chmod 755 $HOME</code>
+Et tout devrait rentrer dans l'ordre.
-Vous pouvez décommenter (c'est-à-dire enlever le « # ») cette ligne. Effet : lorsque vous essayez de vous connecter à votre serveur par SSH, le fichier « /etc/issue.net » est affiché (à vous de le personnaliser).
+Si ce n'est toujours pas le cas, c'est que le serveur doit être configuré en mode de sécurité strict (c'est le cas par défaut sur Ubuntu).\\
+Effectuez les opérations suivantes :
-<file>#MaxStartups 10:30:60</file>
+Sur le serveur : \\
+  * dans le fichier **/etc/ssh/sshd_config**, la ligne ''StrictModes yes'' indique que le serveur va être très pointilleux sur les droits du compte sur lequel on se connecte en ssh.\\
+  * saisissez ensuite les commandes suivantes
+<code>chmod go-w ~/
+chmod 700 ~/.ssh
+chmod 600 ~/.ssh/authorized_keys</code>
-Vous pouvez aussi décommenter cette ligne, effet : le 10 représente le nombre de connexions acceptées sans qu'un utilisateur ait réussi à s'identifier, si cela passe au dessus de 10, il y a 30 % de chances que les suivantes soient bloquées, et ce pourcentage augmente linéairement jusqu'à 100 % lorsque le //full// est atteint, à 60 connexions. Très utile pour éviter [[http://linuxfr.org/~dark_star/18379.html|ce genre]] de désagrément.
+  * Sur le client, dans **/etc/ssh/ssh_config**, rajoutez la ligne ''PreferredAuthentications publickey''.\\
-<file>AllowUsers alice bob</file>
+== Gestion des clés ==
-Ligne à ajouter, spécifie les //logins// des seuls utilisateurs (ici seuls Alice et Bob, pas Carole) autorisés à se connecter. Idéal pour ouvrir un compte FTP à un ami tout en restreignant l'accès au Shell //via// SSH.
+Parfois les clés de vos correspondants peuvent changer (réinstallation de machine par exemple), vous aurez alors droit à ce charmant message :
+<code>
+  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+  @    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 the RSA host key has just been changed.
+  The fingerprint for the RSA key sent by the remote host is
+  xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
+  Please contact your system administrator.
+  Add correct host key in /home/<vous>/.ssh/known_hosts to get rid of this message.
+  Offending key in /home/<vous>/.ssh/known_hosts:4
+  RSA host key for <ip> has changed and you have requested strict checking.
+  Host key verification failed.
+</code>
+Soit l'information est exacte et une machine a été corrompue, ou bien il s'agit juste d'un changement de clé (réinstallation par exemple) et dans ce cas il faut effacer les entrées dans le fichier **.ssh/known_hosts** de votre compte.\\
+Avant la chose était relativement simple, la clé était directement associée au nom ou à l'IP de la machine cible. Ce n'est plus le cas à présent où elle est associée par UUID rendant quasiment impossible l'identification visuelle de la ligne concernée. Mais ssh étant sympathique, il vous indique quelle est la ligne du fichier concernée.\\
+Pour reprendre l'exemple précédent on peut lire la ligne Offending key in /home/<vous>/.ssh/known_hosts:4 → la clé en erreur est donc située ligne 4 du fichier **.ssh/known_hosts**
-<file>PasswordAuthentication no</file>
+Il existe cependant une méthode plus subtile en employant la commande suivante :
-Passez de "yes" à "no" pour interdire l'utilisation du mot de passe et forcer l'usage de jeux de clefs public/privé (plus sûr).
+<code>ssh-keygen -R <ip></code>
+Vous pourrez ainsi effacer seulement l'adresse IP concernée et relancer un ssh.
+== Connexion à un répertoire /home chiffré ==
+Si vous souhaitez vous connecter par SSH avec une clef publique sur un compte dont le home est chiffré, il est important de faire attention à ce que sur le serveur le fichier/dossier **.ssh/authorized_keys** soit à la fois dans le home chiffré et déchiffré. En effet si le fichier authorized_keys est dans le home sous forme chiffré (.private), open_ssh ne pourra pas lire la clef publique attendue. Il faut donc créer un dossier .ssh et y mettre le fichier authorized_keys quand le home est démonté donc chiffré. Cependant, si vous ne le laissez pas aussi dans le home déchiffré et donc monté, la connexion SSH se fera avec la clef publique mais le home ne sera pas déchiffré automatiquement.
+La meilleure solution est de créer des liens virtuels vers un dossier qui n'est pas soumis au chiffrement/déchiffrement comme expliqué [[https://rohieb.wordpress.com/2010/10/09/84/|ici]]
+== Authentification SSH avec plusieurs clés privées ==
-===== Utiliser SSH pour faire du SFTP (Transfert de fichier sécurisé) =====
+En principe chaque utilisateur possède une clé privée unique qui lui est propre, et envoie sa clé publique à autant de serveurs qu'il le souhaite.
-Vous pouvez :
+Cependant il est techniquement faisable de posséder plusieurs clés privées (mais c'est moins pratique et ça n'est pas plus sécurisé).
-  * utiliser [[mysecureshell_sftp-server|MySecureShell]] (s'installe en plus de openssh-server),
-  * simplement le mode natif de openssh,
-  * Suivre ce tutorial qui limite l'utilisation du ssh au sftp pour des utilisateurs donnés [[http://penguindroppings.wordpress.com/2009/09/09/serving-up-sftp-and-apparmor/|sftp avec openssh et AppArmor (en)]].
+Lorsqu'on se connecte à plusieurs serveurs avec des clés privées différentes, il faut pouvoir indiquer à SSH quelle clé on veut utiliser pour la connexion, sinon, on rencontre par exemple l'erreur:
+<code bash>git@gitlab.com: Permission denied (publickey).</code>
-===== Tunnéliser sa connexion internet par SSH avec l'aide de Squid =====
+Pour indiquer au client SSH la clé qu'il doit utiliser pour chacun des serveurs on peut créer un fichier **~/.ssh/config** (ou **/etc/ssh/ssh_config** pour tous les utilisateurs de la machine) dans lequel il faut spécifier pour chacun des serveurs la clé qui doit être utilisée :
-Tunnéliser sa connexion web est très utile dans quelques situations :
-  * l'admin du réseau où vous êtes vous empêche d'accéder à certains sites ;
-  * votre connexion web est peu ou pas sécurisée (wifi sans //encryption// ou par //encryption// wep).
-On va donc installer le serveur de médiation Squid (serveur proxy, mandataire) sur une machine Ubuntu (qui sera le serveur) à laquelle on accèdera par une machine distante possédant un client SSH et un navigateur Web. Dans l'exemple présent, ce sera un client sous Windows.
-On obtiendra alors un accès sécurisé à un **proxy** distant (le serveur sous Ubuntu) qui se connectera aux sites web et renverra le résultat à votre navigateur.
-==== Partie serveur ====
-Premièrement, il faut installer le programme [[http://www.squid-cache.org/|Squid]]. Le [[:tutoriel:comment_installer_un_paquet|paquet à installer]] est **squid**.
-Normalement si tout se déroule bien, Squid devrait être fonctionnel. Il est probable qu'une erreur arrive car le programme de configuration n'arrivera pas à trouver le nom d'hôte de la machine. Il faut donc ouvrir le fichier de configuration de Squid et lui indiquer que la machine n'a pas de nom d'hôte. On [[:tutoriel:comment_editer_un_fichier|ouvre le fichier de configuration]] « /etc/squid/squid.conf » et on ajoute cette ligne :
-<file>visible_hostname none</file>
-Après l'enregistrement du fichier de configuration, vous pouvez normalement générer les répertoires qui contiendront le cache de Squid par la commande :
-  sudo squid -z
-Grâce à SSH, les connexions reçues par Squid seront des connexions provenant du serveur lui-même. Mais par défaut, Squid n'accepte que les connexions //loopback//. On devrait alors quand même ajouter une autorisation pour l'adresse IP non //loopback// (127.0.0.1) du serveur. Vous ouvrez donc le fichier de configuration et vous ajoutez ces deux lignes :
 <file>
-acl ordi src 192.168.1.1
+Host adresse-serveur-sans-passphrase.com
-http_access allow ordi
+User votreutilisateur
+IdentityFile ~/.ssh/key-sans-passphrase
+Host adresse-serveur-avec-passphrase.com
+User votreutilisateur
+IdentityFile ~/.ssh/key-avec-passphrase
 </file>
-Dans l'exemple, « ordi » est le nom que j'ai donné à la règle et « 192.168.1.1 » est l'adresse IP locale de mon ordinateur. Vous pouvez donc maintenant démarrer Squid par :
+Pour plus d'options, comme l'utilisateur ou le port à utiliser par défaut, voir le [[:man|manuel]] de **ssh_config**, cf. aussi [[https://gitlab.com/help/ssh/README#working-with-non-default-ssh-key-pair-paths|l'aide de gitlab (en)]]
-  sudo squid start
-ou le redémarrer par
+== Les empreintes (fingerprint) ==
-  sudo squid reload
+Retrouver l'empreinte de notre clef SSH, pour la communiquer à une personne qui veut se connecter et va utiliser notre clef publique :
+<code>ssh-keygen -l</code>
+Ensuite la commande demande le fichier de la clef publique. Sur un serveur on spécifiera **/etc/ssh/ssh_host_rsa_key.pub**.
+===== Configuration du serveur SSH =====
+La configuration par défaut du serveur SSH sous Ubuntu est suffisante pour fonctionner correctement. Le fichier de configuration à [[:tutoriel:comment_editer_un_fichier|éditer avec les droits d'administration]] est  **/etc/ssh/sshd_config**.
-Squid est normalement prêt à recevoir les connexions venant de la machine hôte.
+Tableau des principales directives à modifier le cas échéant :
+^Directive du fichier^Valeur par défaut sous Ubuntu^Valeur possible^Effet de la valeur choisie^
+|Port  | 22 | Tous les ports qui ne sont pas utilisés par un autre service  | Le changement du port par défaut , souvent conseillé, n'augmentera pas la sécurité. C'est même l'inverse si vous choisissez un port non privilégié, c'est à dire supérieur à 1024  |
+|PermitRootLogin|without-password / prohibit-password|yes no without-password forced-commands-only prohibit-password| cf [[http://manpages.ubuntu.com/manpages/lucid/man5/sshd_config.5.html| le man]] |
+|PubkeyAuthentication|yes|no|Laisser yes si vous voulez établir l'authentification par clé comme expliqué plus haut|
+|PasswordAuthentication|yes|no|On peut parfaitement conserver l'authentification par clé pour certains utilisateurs avec celle par mot de passe pour d'autres utilisateurs. Conserver cette valeur à yes tant que l'authentification par clé n'est pas pleinement fonctionnelle, sinon vous perdrez toute connexion en SSH|
+|X11Forwarding|yes|no|Laisser yes pour faire de l'affichage graphique déporté|
+|#MaxStartups 10:30:60|ligne commentée donc inactive|décommenter (enlever symbole #)|Le 10 représente le nombre de connexions acceptées sans qu'un utilisateur ait réussi à s'identifier, si cela passe au dessus de 10, il y a 30 % de probalités que les suivantes soient bloquées, et ce pourcentage augmente linéairement jusqu'à 100 % lorsque le //full// est atteint, à 60 connexions. Très utile pour éviter [[http://linuxfr.org/~dark_star/18379.html|ce genre]] de désagrément.|
+|#Banner /etc/issue.net|Ligne commentée donc inactive|Décommenter|Lorsque vous essayez de vous connecter à votre serveur par SSH, le fichier ''/etc/issue.net'' est affiché (à vous de le personnaliser pour dire bonjour ou mettre un avertissement, un guide, etc.)|
+|UsePAM|yes|no|Attention, bien lire la page de man sshd_config, ce paramètre interagit avec //ChallengeResponseAuthentication// et //PasswordAuthentication// |
+|AllowUsers|Ligne absente (autorisé à tous)|ajouter la ligne avec valeur(s) : AllowUsers Alice Bob |Spécifie les //logins// des seuls utilisateurs autorisés à se connecter. //Idéal pour ouvrir un compte FTP à un ami tout en restreignant l'accès au shell via SSH//.|
+|DenyUsers|Ligne absente (interdit à personne)|Ajouter la ligne avec valeur(s)|Interdit l'accès à SSH aux utilisateurs listés|
+|AllowGroups|Ligne absente (autorisé à tous les groupes)|ajouter la ligne avec valeur(s) : AllowGroups groupname1 groupname2|L'authentification via SSH ne sera possible que par des utilisateurs des groupes désigné par leur nom (pas par GID)|
+|DenyGroups|Ligne absente (interdit à aucun groupe)|Ajouter la ligne avec valeur(s)|Interdit l'accès à SSH aux utilisateurs des groupes listés|
+|ClientAliveInterval|Ligne absente|Ajouter la ligne avec valeur en secondes : ClientAliveInterval 300|Permet dans certains cas de maintenir une connexion sans coupures|
+Pour plus d'informations consultez ''man sshd_config''.
-===== Tunnéliser sa connexion internet par SSH (sans Squid) =====
+===== Configuration du client SSH =====
+Le client peut aussi être configuré… via le fichier **/etc/ssh/ssh_config**
-La partie précédente consiste à installer un [[http://fr.wikipedia.org/wiki/Proxy|proxy HTTP]] sur le serveur et de s'y connecter via SSH.
+Il est notamment intéressant d'ajouter
-Cependant, SSH lui-même peut jouer le rôle de proxy, ce qui évite l'installation d'un logiciel supplémentaire.
-==== Partie serveur ====
-Il n'y a en principe rien à faire. Cette fonctionnalité est activée par défaut sous Ubuntu.
-==== Partie client ====
-Cette fois, le proxy est de type //SOCKS// (à prendre en compte lors de la configuration du navigateur)
-=== Sous Windows, avec Putty ===
-La configuration est la même que dans la partie précédente, sauf qu'il faut cocher la case "dynamic".
-La case "destination" n'est pas prise en compte et peut rester vide.
-=== Sous Linux (dont Ubuntu) ===
-Utiliser la commande ''ssh'' avec l'option ''-D'' :
 <code>
-# Ouverture d'un tunnel ssh (sur le port 1234 local) vers un serveur qui autorise la connexion
+	ServerAliveInterval 240
-# le port (1234 dans cet exemple) est choisi arbitrairement, tant qu'il n'est pas utilisé pour autre chose
-ssh -D 1234 monuser@monserver.net
 </code>
-Configurer ensuite le navigateur, gestionnaire de courrier, ....,  pour utiliser un proxy type //SOCKS 5//, adresse: //localhost//, port: //1234// (selon ce que vous avez utilisé ci dessus)
+Pour que le client envoie des infos au server (ici toute les 4 minutes) et que ce dernier ne coupe pas la liaison, ce qui bloque (fige) le terminal.
+Pour voir les autres options: [[https://man.openbsd.org/ssh_config]] (en)
-La connexion fonctionnera tant que le tunnel restera ouvert (si vous fermez le terminal ayant servi à ouvrir le tunnel, vous fermerez le tunnel...)
+===== Accéder à un serveur SSH dont les ports entrants sont bloqués =====
-Pour vous assurer que le tunnel remplit son office, affichez une page telle que http://www.monip.org et constatez que l'IP affichée n'est pas la même que lorsque vous naviguez sans proxy.
+Il peut arriver que les ports des connexions entrantes sur un serveur SSH soient bloqués ((le cas peut se présenter notamment en entreprise ou derrière une box)). Cependant, il est rare que les ports sortants soient fermés. Dans ce cas, il est possible de faire appel à du << //Reverse-SSH// >> tel qu'expliqué dans **[[:tutoriel:reverse_ssh|cette page]]**
-<note>
+===== Voir aussi =====
-Vous pouvez ouvrir plusieurs tunnels utilisant des ports différents ou des utilisateurs différents. Ainsi, la navigation peut utiliser un tunnel vers un serveur, la messagerie un tunnel vers un autre serveur, etc.
+  * [[https://www.openssh.com/|site officiel]]
+  * [[:cssh]] : Cluster SSH
-Il est possible aussi d'utiliser un navigateur passant par le tunnel et un autre navigateur sortant directement.
+  * [[https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf|note ministérielle du 17 août 2015]] : Recommandations pour un usage sécurisé d'(Open)SSH
-</note>
+  * [[https://infosec.mozilla.org/guidelines/openssh|Guide de Mozilla pour la configuration d'OpenSSH]]
+  * [[https://www.it-connect.fr/cours-tutoriels/administration-systemes/linux/ssh/|Tutoriels sur l'utilisation et la configuration avancée de SSH]] sur IT-Connect
+  * [[https://www.ssh-audit.com/hardening_guides.html|Guide de ssh-audit pour blinder la configuration]]
-===== Accéder à ses ressources réseau locale depuis l'extérieur sans NAT =====
+  * [[:ssh_avance]] Fixme !
-Il est intéressant de pouvoir accéder à des ressources réseau locales (RDP, VNC, Administration périphérique réseau comme les box etc...) sans pour autant rendre ces périphérique directement accessibles depuis internet. SSH permet l'accès à ces ressources comme si on était en local (une sorte de VPN).
-Je vais prendre un exemple.
-==== Accéder à une machine Windows via RDP ====
-Donc nous avons un réseau avec une machine sous Windows (XP, Vista...) avec comme adresse locale 192.168.1.2 où TSE est activé mais accessible uniquement en local, un serveur ssh sous ubuntu avec comme IP locale 192.168.1.3, et une Livebox (où autre) dont seul le port ssh (22) est natté pour un accès au serveur ssh depuis l'extérieur.
-Nous voulons depuis l'extérieur accéder à la machine Windows via RDP.
-Nous allons pour cela utiliser la tunélisation. À partir de votre station depuis l'extérieur on va tunéliser la connexion RDP de la station Windows au travers du serveur ssh :
-<code>$ ssh -L 3389:192.168.1.2:3389 username@IP_Publique_Box</code>
-Il suffit ensuite d'ouvrir le Terminal serveur client sur votre machine et de se connecter à localhost.
-Nous pouvons de la même façon accéder à la configuration de notre Box sans pour autant devoir la rendre accessible depuis internet (attention seul root peut forwarder le port 80) :
-<code># ssh -L 80:192.168.1.1:80 username@IP_Publique_Box</code>
-Puis en ouvrant son navigateur préféré et en entrant comme adresse [[http://localhost]]
-Section éditée par : [[http://forum.ubuntu-fr.org/profile.php?id=34519|Havany]]
-===== Délai lors de la connexion =====
-Si vous avez un délai de plusieurs secondes avant que la connexion SSH ne se fasse, essayez d'ajouter ceci à votre fichier ~/.ssh/config
-  GSSAPIAuthentication no
-Ceci désactive l'identification par [[http://en.wikipedia.org/wiki/Generic_Security_Services_Application_Program_Interface|GSSAPI]]  qui engendre parfois des délais lorsqu'elle n'est pas utilisée.
-(Source : http://www.refreshinglyblue.com/2007/5/18/long-delay-before-ssh-authentication)
-===== Correction vulnérabilité SSH =====
-Le 14 mai 2008, une mise à jour de sécurité de ssh dans les dépôts signale qu'une vulnérabilité a lieu dans le générateur de nombres aléatoires pour générer les clés.
-Il faut donc regénérer ses clés après avoir fait la mise à jour et redémarré.
-Vu que la mise à jour regénère automatiquement les clés pour la machine, il ne reste plus qu'à modifier les clés persos (pour les users) après un reboot.
-Sur les pc clients :
-<code>rm ~/.ssh/known_hosts</code>
-Sur les pc serveurs :
-<code>rm ~/.ssh/authorized_keys</code>
-Puis, pour une authentification par clés, à partir du poste client :
-<code>ssh-keygen -t dsa
-scp ~/.ssh/id_dsa.pub leserveur:.ssh/authorized_keys</code>
-Pour vérifier:
-Installer [[apt://openssh-blacklist|openssh-blacklist]]** et [[apt://openssh-blacklist-extra|openssh-blacklist-extra]]**.
-<code>ssh-vulnkey</code>
-Si aucune clé n'est **COMPROMISE**, c'est ok :)
-===== Les empreintes (fingerprint) =====
-Retrouver l'empreinte de notre clef ssh, pour la communiquer à une personne qui veut se connecter et va utiliser notre clef publique :
-<code>$ ssh-keygen -l</code>
-Ensuite la commande demande le fichier de la clef publique. Sur un serveur on spécifiera ''/etc/ssh/ssh_host_rsa_key.pub''.
-===== Sécurisons ... encore plus =====
-En limitant l'accès aux personnes se connectant depuis un domaine de votre choix (déclaré via DynDNS ou autre...)
-Un peu de sécurité dans ce monde de brutes...force. :-D
-<note important>Cette partie est destinée aux utilisateurs un minimum habitués aux scripts et à l'usage des lignes de commandes...</note>
-=== Le principe ===
-En fait une fonction assez intéressante pour la sécurité de vos serveurs SSH existe, elle permet d'autoriser la connexion uniquement à des utilisateurs et/ou domaines prédéfinis.
-(J'entends certains chuchoter IP spoofing mais bon, il faut déjà savoir quelle IP est autorisée à se connecter, et de toute façons il faut encore faire du brut force ensuite... Rien n'est jamais parfait mais ça introduit tout de même un bon gain de sécurité.)
-La problématique est que seules les IP semblent être acceptées par le démon de connexion SSH, dans le  cas ou vous avez une IP dynamique ça limite un peu...
-Du coup on va utiliser un petit script pour vérifier l'adresse IP correspondante à un nom de domaine (il faut évidement que votre IP dynamique soit associée à un nom de domaine par DynDNS par exemple.)
-**Le script réalise les tâches suivantes :**
-  * Vérification de l'adresse IP correspondant au nom de domaine
-  * Comparaison avec l'adresse déjà inscrite dans /etc/ssh/sshd_config
-  * En cas de changement, modification de la dernière ligne du fichier /etc/ssh/sshd_config pour autoriser les connexions depuis la nouvelle adresse IP et depuis le réseau local et redémarrage de sshd pour rendre le changement de configuration effectif. (N'ayez crainte, les connexions déjà établies ne seront pas interrompues.)
-<note important>A titre d'exemple pour lancer le script de façon transparente toute les 5 minutes sans mot de passe j'ai utilisé la table root de [[cron]] (Pour plus de détails consulter les pages correspondantes...) :
-ATTENTION : Par défaut (sous HARDY au moins) l'éditeur est [[nano]] pour //crontab...//
-Dans la table cron de root ///var/spool/cron/crontabs/root// à éditer par <code>sudo crontab -e</code>
-ajouter
-<code>*/5 * * * * /usr/local/bin/SSH_IP_allow.sh</code>
-</note>
-Le script SSH_IP_allow.sh (à placer dans ///usr/local/bin///) :
-N'oubliez pas d'inscrire votre nom de domaine à la place de "***Votre nom de domaine ici***"
-<code=bash>#!/bin/bash
-# SSH_IP_allow.sh V0.12
-# Par Mysteroïd 12/02/2009
-# Script offert à la communauté Unbuntaise voir Linuxienne...
-# Sans aucunes garanties, à utiliser en sachant ce que vous faites et à vos risques et périls.
-# Et j'espère évidemment que ça vous rendra service à vous aussi... ;)
-mkdir /tmp &>/dev/null
-# Enregistre l'adresse IP (résultat de arp) dans getip.tmp
-sudo arp ***Votre nom de domaine ici***> /tmp/getip.tmp
-# Récupère la première ligne comme arguments $1,$2,...
-set `head -1 /tmp/getip.tmp`
-# Récupère l'IP
-IP_DISTANTE="`echo $2 | tr -d ["()"]`"
-# Dernière ligne du fichier sshd_config
-L="`tail -1 /etc/ssh/sshd_config`"
-# Nouvelle ligne (à inscrire si IP distance changée depuis fois précédente)
-L2="AllowUsers *@$IP_DISTANTE *@192.168.*"
-# Si pas de changement de ligne (par rapport à l'IP indiquée dans le ficher de configuration)
-if [ "$L" = "$L2" ]; then
-	echo "Pas de changements d'IP..."
-else
-	# Enlève la dernière ligne si elle débute par AllowUsers
-	if [ "${L:0:10}" = "AllowUsers" ] ; then
-		set `wc -l /etc/ssh/sshd_config`
-		head -$(($1-1))	/etc/ssh/sshd_config > /tmp/sshd_config
-		mv /etc/ssh/sshd_config /etc/ssh/sshd_config.old
-		cat /tmp/sshd_config > /etc/ssh/sshd_config
-	fi
-	# Ajoute les utilisateurs autorisés...
-	echo $L2 >> /etc/ssh/sshd_config
-	echo "Utilisateurs / hôtes autorisés à se connecter en SSH :"
-	echo -e "${L2:11}\n"
-	echo "Redémarrage du serveur SSH"
-	sudo /etc/init.d/ssh restart
-fi
-exit 0</code>
-<note tip>Pour tester que ça fonctionne :
-Contrôlez l'heure de la dernière vérification d'IP par le script avec
-<code>ls -l /tmp/getip.tmp</code>
-Visualisez les IP autorisées actuellement en dernière ligne de sshd_config avec
-<code>tail -1 /etc/ssh/sshd_config</code>
-</note>
-**Modifications envisageables :**
-  * Limitation des utilisateurs autorisés et pas seulement des domaines, en utilisant le format //utilisateur@domaine// dans sshd_config au lieu de //*@domaine//.
-  * Utilisation de plusieurs domaines distants autorisés avec écriture.
-  * Pour des serveurs très utilisés type entreprise avec de multiples personnes susceptible de s'en servir, possibilité de lancer le script par cron de façon très fréquente jusqu'à chaque seconde pour réduire au maximum les délais d'accès au serveur en cas de changement d'IP des clients.
-  * Récupérer l'IP sans passer par l'enregistrement du fichier //getip.tmp//, ça rend la vérification du travail du script un peu moins évidente mais ça évite les petits accès disque, surtout en cas de lancement du script à fréquence rapide type une seconde.
-  * Archivage des IP autorisées
-  * Certainement bien d'autres choses encore, à vous d'imaginer la suite...
-Concernant la **partie "Sécurisons ... encore plus" UNIQUEMENT** : Si besoin contactez moi via la page [[utilisateurs/Mysteroïd]], de même que ça me fera plaisir de savoir si le script vous rend service...
-<note tip>Si les connections SSH se cloturent par des timeout au bout de 30 secs d'inactivitées ( cas principalement chez Numéricable ):
-Plutôt que modifier coté serveur (ce qui peut etre long quand on administre plusieurs serveurs,
-Créé un fichier ~/.ssh/config
-<code>nano ~/.ssh/config</code>
-copier/ coller les deux lignes suivantes:
-<code>ServerAliveInterval 3
-ServerAliveCountMax 20
-</code>
-Fermer et enregistrer ( ctrl + x | Y )
-</note>
-Bon SSH à tous ! ;-)
-===== Liens =====
-  * [[http://www.planete2geek.fr/chrooter-un-utilisateur-en-ssh-facilement/|Tuto]]. Chrooter un utilisateur en ssh facilement.
-  * [[http://technique.arscenic.org/connexion-distante-au-serveur-ssh/|Config]]. Configuration et sécurisation de ssh.
+//Contributeurs: [[:utilisateurs:sx1]], [[:utilisateurs:krodelabestiole]], [[:utilisateurs:Zer00CooL]], [[:utilisateurs:bruno]]//