| | Configuration d'un accès sécurisé à une machine par SSH Il est souvent intéressant de pouvoir se connecter à distance sur une machine éloignée ou un serveur de production sans devoir aller dans la salle informatique réfrigérée à 17°C. Historiquement, l'outil telnet permettait d'offrir un shell distant qui donnait ainsi la possibilité d'effectuer des commandes à distance. Mais ce logiciel souffrait de nombreux défaut qui ont vite nécessité la création d'un nouvel outil de remplacement. D'abord, le protocole n'étant pas sécurisé, les mots de passe de connexion passaient en clair sur le réseau. Enfin, la non prise en compte de règles de sécurité dans la programmation de l'outil ont amené un nombre conséquent de failles exploitables à distance. Il a donc fallu créer un nouvel outil qui puisse fournir les mêmes services, tout en y associant des principes de sécurité forts. Ainsi est né la protocole SSH. Il existe aujourd'hui plusieurs implémentations d'SSH, libres ou non. Nous allons nous consacrer à la plus utilisée qui est OpenSSH et qui provient du projet OpenBSD. SSH offre des avantages énormes par rapport à d'autres types de shells distants comme rsh ou telnet. En voici quelques uns: - Sécurité du développement (une seule faille distante root à ce jour) - Utilisation avancée de la cryptographie - Authentification forte par clefs publiques - Chiffrement de tous les échanges - Les mots de passe utilisateurs n'ont plus à être connus et donc à se ballader - Implémentation d'une alternative à ftp à travers SFTP Et ceci n'est qu'un bref aperçu des avantages procurés par SSH ! Nous allons voir à travers sa mise en place quels sont les gains obtenus. Sommaire: 1- Préambule 2- L'installation d'OpenSSH 3- L'authentification par clefs publiques 4- Configuration du serveur 5- Mise en place du routage pour notre double connexion 6- Optimisation de l'accès 7- Tester si ca marche 8- Gestion d'une coupure d'accès (à venir) Mon fichier de configuration OpenSSH Nous allons donc tenter de configurer notre serveur SSH pour en exploiter au mieux les possibilités. Nous verrons aussi quelques outils clients qui nous permettront de nous connecter à notre serveur, aussi bien pour obtenir un shell que pour échanger des fichiers. Nous n'allons pas nous attarder sur cette partie, l'installation d'OpenSSH ayant été maintes fois expliquée sur le net, et de plus en plus automatisée sur les distributions linux, quand OpenSSH n'est pas directement intégré au système. Je précise simplement que je vais vous présenter la configuration d'OpenSSH sur un système Unix, sachant que l'installation peut-être identique sous windows à l'aide de l'outil Cygwin. Vous avez sûrement l'habitude pour vous authentifier sur votre ordinateur de fournir un login et un mot de passe. Mais ce type d'authentification est dit faible, car si vous vous faites voler votre mot de passe, il sera possible d'usurper votre identité. Il existe des mécanismes d'authentification dits "forts" qui associent à la fois un élément connu (mot de passe par exemple) à un élément possédé (clef privée par exemple) L'authentification ne pourra se faire qu'avec ces deux éléments combinés. Ainsi, si vous vous faites voler votre clef privée (vol d'ordinateur par exemple) le voleur ne pourra pas s'authentifier à votre place car il ne connait pas le mot de passe associé à la clef ! De plus, en ce qui concerne SSH, le mot de passe associé à la clef est indépendant du compte utilisateur sur lequel vous voulez vous connecter, ainsi, le vrai mot de passe du compte utilisateur n'a même pas à être connu ! L'authentification est possible grâce à des propriétés mathématiques du couple clef privée/clef publique. Quand un message est chiffré par une clef, il ne peut être déchiffré que par l'autre. On peut ainsi garantir que l'on possède l'autre clef. Prenons un exemple. Disons que vous possédez un ordinateur sur votre réseau du nom de "cactus". Vous avez un compte utilisateur "Pierre" sur cet ordinateur. Avant, pour vous connecter en telnet, votre login (Pierre) ainsi que votre mot de passe "toto1234" vous étaient demandés, et passaient en clair aux yeux de tout le monde sur le réseau ! Avec SSH, vous vous connectez à cactus et indiquez que vous voulez vous connecter en tant que Pierre. L'ordinateur cactus possède la clef publique de Pierre et peut vous envoyer un message chiffré avec cette clef. Vous seul possédez la clef privée et pouvez déchiffrer ce message, vous garantissez donc que vous possédez la clef privée. Pour accéder à la clef privée, il faut entrer un mot de passe. Ainsi, il faut à la fois connaître le mot de passe et posséder la clef privée pour s'authentifier. L'exemple donné ici est très simplifié et ne représente pas ce qui se passe réellement, car dans ce cas, un pirate interceptant notre réponse pourrait se faire passer pour nous... Ainsi, nous avons réussi à nous authentifier auprès de l'ordinateur, de façon forte, sans avoir à connaître de mot de passe utilisateur ! La configuration du serveur est relativement simple. Tout se fait en un seul fichier, le fichier de configuration sshd_config, souvent situé dans /etc/ssh/sshd.conf. Si vous ne le trouvez pas, un petit find / -name sshd_config devrait vous aider. La syntaxe au sein de ce fichier est elle aussi assez simple, il s'agit de dire si nous voulons autoriser certaines directives, ou pas. Par exemple, si nous ne voulons pas autoriser l'accès distant au compte root, nous mettrons "no" à la directive "PermitRootLogin". Voici un exemple de fichier de configuration:# $NetBSD: sshd.conf,v 1.1.1.1.2.1 2000/10/03 21:55:26 lukem Exp $## This is ssh server systemwide configuration file.Port 22#Protocol 2,1#ListenAddress 0.0.0.0#ListenAddress ::HostKey /etc/ssh_host_keyServerKeyBits 768LoginGraceTime 600KeyRegenerationInterval 3600PermitRootLogin yes## Don't read ~/.rhosts and ~/.shosts filesIgnoreRhosts yesIgnoreRootRhosts yes# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication#IgnoreUserKnownHosts yesStrictModes yesX11Forwarding noX11DisplayOffset 10PrintMotd yesKeepAlive yes# LoggingSyslogFacility AUTHLogLevel INFO#obsoletes QuietMode and FascistLoggingRhostsAuthentication no## For this to work you will also need host keys in /etc/ssh_known_hostsRhostsRSAAuthentication no#RSAAuthentication yes# To disable tunneled clear text passwords, change to no here!PasswordAuthentication yesPermitEmptyPasswords no# Uncomment to disable s/key passwords #SkeyAuthentication no# To change Kerberos options#KerberosAuthentication no#KerberosOrLocalPasswd yes#AFSTokenPassing no#KerberosTicketCleanup no# Kerberos TGT Passing does only work with the AFS kaserver#KerberosTgtPassing yes#CheckMail yes#UseLogin no#Subsystem sftp /usr/local/sbin/sftpd#MaxStartup 10:30:60This file is a little daunting. One item to take note of is that the server config does not allow X11 forwarding by default, which of course on a firewall is a good thing. To enable it the administrator must change the following lines:StrictModes noX11Forwarding yes |