UbunBloX

Si il y a bien un domaine dans lequel j’ai encore tout à apprendre, c’est bien celui du réseau car mon expérience à ce niveau est quasi-nulle ! Malgré ce manque de compétence, je me suis mis en tête de créer mon propre serveur, une idée qui m’oblige donc à me plonger dans de nombreuses documentations.

Pour le moment, je ne fais rien de réellement passionnant, d’un point de vue matériel, le serveur n’est même pas fini : Pas de boîtier, pas de disque dur. Le seul média de stockage qui le compose est une simple clé USB de 8Go. Risible et pas très adéquat mais cela est bien assez pour débuter les hostilités !

Après avoir installer une Debian Squeeze, me voilà donc fin prêt pour tenter l’aventure du serveur personnel ! Cette aventure commence avec la mise en place l’outil SSH pour administrer les serveur à distance. Le protocole SSH est fait pour ça, il le fait de manière sécurisée et sa mise en place est relativement simple, je dis bien « relativement » car j’ai tout de même eu quelques soucis .

Important: Cet article n’est en aucun cas un tutoriel à suivre, il s’agit simplement de mon pense bête. La manière de faire est loin d’être un modèle du genre mais dans mon cas elle fonctionne, libre à vous de vous en inspirer !

Configuration client/serveur :

Coté serveur :

• Distribution : Debian Squeeze
• Adresse IP : 192.168.1.13
• Nom d’utilisateur : tom

Coté client :

• Distribution : Arch Linux
• Adresse IP : 192.168.1.10
• Nom d’utilisateur : david

Installation des composants nécessaires :

Après un premier redémarrage de la Debian fraîchement installée, il est nécessaire d’y ajouter le paquet openssh-server :

# aptitude update && aptitude upgrade

# aptitude install openssh-server

Le service étant démarré automatiquement après installation, il n’y a plus besoin d’avoir un accès physique au serveur.

Un bonne raison pour le mettre dans un coin

Passons à présent au client sur Arch Linux, en installant le nécessaire :

# pacman -S openssh

L’étape d’installation est à présent terminée !

Première connexion :

Avant de me connecter directement au serveur en SSH, je fais un ping pour savoir si l’ensemble client/serveur communique :

$ ping -c 3 192.168.1.13

Tout se passe à merveille ! Il ne reste plus qu’à tenter une connexion à distance :

$ ssh tom@192.168.1.13

Lors de cette étape, il est demandé de saisir un mot de passe d’utilisateur, en l’occurrence, c’est celui de tom. Une fois la connexion établie, il ne reste plus qu’a vous identifier en tant que root pour installer par exemple un serveur Apache .

Configuration du serveur SSH :

Voici des petites modifications que vous pouvez effectuer au fichier /etc/ssh/sshd_config :

# vim /etc/ssh/sshd_config

Désactivation de l’authentification avec le compte root :

PermitRootLogin no

On peut changer le numéro de port 22 utilisé par défaut :

Port 4205

Pas de mot de passe vide :

PermitEmptyPasswords no

Désactivation de l’authentification avec le service PAM :

UsePAM no

On vérifie que la ligne AuthorizedKeysFile ne soit pas commentée :

AuthorizedKeysFile      %h/.ssh/authorized_keys

Pour prendre en compte les modifications, il faut recharger le fichier de configuration à l’aide de la commande suivante :

# /etc/init.d/ssh reload

Bien évidement, si vous changez le port par défaut, il faudra le spécifier lors de votre connexion au serveur :

$ ssh -p 4205 tom@192.168.1.13

Utilisation des clés partagées :

Jusqu’à présent la connexion se fait à l’aide d’un simple mot de passe, d’un point de vue sécurité, ce n’est certainement pas le meilleur choix. Le protocole SSH supporte l’usage des clés privés/publiques pour se connecter au serveur distant. La première étape consiste à créer ce couple de clés en faisant bien attention d’attribuer une passphrase solide:

$ ssh-keygen -t dsa

Les clés générées se trouvent dans le répertoire ~/.ssh :

$ tree ~/.ssh
.ssh
 config
 id_dsa
 id_dsa.pub
 known_hosts

Il faut à présent transférer la clé publique du client au serveur en utilisant le script sh-copy-id, et c’est à partir de là que tout a coincé pour moi :

$ ssh-copy-id -i ~/.ssh/id_dsa.pub tom@191.168.1.13

Cette commande ne m’a renvoyé qu’un joli « time out », je ne connais pas la raison, j’ai donc cherché à transférer cette clé d’une manière plus artisanale, en utilisant la commande scp :

$ scp ~/.ssh/id_dsa.pub  tom@193.168.1.13

Pas de chance, ça ne fonctionne pas non plus !

Après m’être rendu sur différents IRC, un proposition m’a été donné :

$ scp ~/.ssh/id_dsa.pub  tom@192.168.1.13:~/

Et là, ça fonctionne ! Il ne manquait apparemment que le petit ‘:~/‘.

Il ne reste plus qu’à placer la clé dans le bon répertoire, on commence donc par se connecter :

$ ssh tom@192.168.1.13

On crée la répertoire ~/.ssh/ :

$ mkdir ~/.ssh

On copie la clé dans le ficher authorized_keys, puis on lui applique un chmod 600 :

$ cat ~/id_dsa.pub >> ~/.ssh/authorized_keys

$ chmod 600 ~/.ssh/authorized_keys

Pour finir, on supprime la clé précédemment copiée :

$ rm ~/id_dsa.pub

Ouf ! Une bonne chose de résolue ! C’est parti, pour un petit test :

$ ssh 192.168.1.13

La passphrase est bien demandée, tout fonctionne à merveille . On peut maintenant supprimer l’authentification par mot de passe dans le fichier de configuration du serveur :

# vim /etc/ssh/sshd_config

PasswordAuthentication no

Authentification avec ssh-agent :

Devoir inscrire sa passphrase à chaque connexion est une tâche relativement… Ennuyeuse. On va donc utiliser l’outil ssh-agent pour pallier à ce problème. Sur la machine cliente faite :

$ ssh-agent

$ ssh-add

La passphrase vous sera demandée une dernière fois. À présent, vous pouvez vous connecter/reconnecter au serveur distant sans être embêter durant toute la session !

Création du fichier ~ssh/config :

Histoire de rendre l’utilisation de la connexion à distance plus agréable, il est possible de remplir un petit fichier de configuration sur la machine cliente :

$ vim ~/.ssh/config

Host Serveur 
Hostname 192.168.1.13
Port 4205
User tom
IdentityFile ~/.ssh/id_dsa

Pour se connecter au serveur il suffira de faire :

$ ssh Serveur

L’article touche à sa fin et comme vous pouvez le voir, il me reste encore beaucoup à apprendre ! En ce qui concerne la configuration du fichier sshd_config, il me reste encore à définir les IP, les utilisateurs ou encore les noms de domaines pouvant avoir accès au serveur. J’ai bien tenté d’ajouter la ligne :

ListenAddress 192.168.1.10

Mais cela a eu pour simple effet de me supprimer l’accès au serveur, ce qui bien évidement n’est pas vraiment voulu ! Je dois également me pencher sur la configuration des fichiers hosts, hosts.allow et hosts.deny sans oublier la prise en main des outils fail2ban et iptables… Bref que du bonheur en perspective .

Même si cet article est loin d’être un exemple à suivre, j’espère que je ne vous ai pas trop ennuyé avec ! Pour finir voici une photographie de mon super serveur :

écrit par David Lopes Ferreira