Yann "Bug" Dubois

Développeur WordPress freelance à Paris
Flux RSS

Configurer un serveur dédié OVH/Kimsufi/Debian 5 pour LAMP

9 September 2009 Par : Yann Dubois Catégorie : Français, tech

logo_ovh-noirJe retranscris ici un petit memento que je me suis fait pour “remonter” rapidement une configuration opérationnelle sous Debian 5 / Apache2 / PHP5 / Mysql pour héberger des sites sur un serveur dédié GNU/Linux type OVH ou Kimsufi. Cette configuration, qui inclut également eAccelerator et des outils de supervision et d’administration de base (Munin, phpsysinfo, mtop, PhpmyAdmin, AWStats) est opérationnelle et suffisamment sécurisée pour une installation standard (à condition de faire régulièrement toutes les mises à jour des packages). En tout cas pour moi c’est bon©®™.

Le memento ci-dessous est une compilation des meilleures recommandations trouvées ailleurs sur le net, remises à jour pour une installation Debian Lenny de Septembre 2009. Il a été mis à jour en mai 2011 pour s’adapter à la nouvelle version Debian 6 Squeeze, et vous pouvez donc lire la nouvelle version ici. La présente page est devenue obsolète, et ne sert que de référence pour les systèmes qui demeurent sous Debian 5. Je ne la tiens plus à jour.

Commencer par se connecter au serveur en ssh avec le compte root avec mot de passe fourni dans l’e-mail envoyé par OVH, sur le port 22 (normal quoi…) (depuis un autre GNU/linux ce serait simplement : ssh -l root suivi du nom ou de l’ip de votre serveur)

1. Re-partitionner ou pas ?

Les serveurs dédiés livrés par OVH ne sont pas partitionnés de façon optimale pour une utilisation comme serveurs web. Suivez ce guide pas à pas pour repartitionner et réinstaller automatiquement votre serveur web OVH. C’est une étape préalable que je vous conseille, même si elle n’est pas indispensable pour des projets modestes ou si vous bénéficiez d’un serveur récent avec une très grande capacité de disques durs. Si vous n’avez pas repartitionné votre serveur vous pourrez toujours vous en sortir en “relocalisant” de nombreux fichiers dans l’arborescence du répertoire /home de votre serveur, mais cela revient à s’éloigner de l’architecture par défaut d’un serveur Debian, et risque de compliquer la maintenance de votre serveur web à long terme.

2. Changement du mot de passe root et création d’un utilisateur

Travailler en root c’est mal, encore plus quand ce root utilise un mot de passe qui a circulé par e-mail. On commence donc par créer un compte d’utilisateur non privilégié (auquel on donnera les privilèges nécessaires pour faire de l’administration à distance tout de même !), et par changer le mot de passe root.

passwd

-> changer pass root

adduser <votre login>
adduser <votre login>  root
adduser <votre login> adm

Vérifiez que vous arrivez à vous connecter avec ce nouvel utilisateur, puis quittez la session root :

exit

(la procédure pour créer les autres comptes d’administration du contenu web est décrite ici)

3. Configuration de la connexion via une clé ssh

J’explique ici dans le détail (dans un autrez article) comment créer une paire de clés ssh sous GNU/Linux. Il existe d’autres excellents tutoriaux à ce sujet ailleurs sur le web (Google est ton ami). On peut également le faire très simplement sous Windows avec Putty par exemple.

Une fois la clé générée et stockée dans un fichier texte localement, se reconnecter en ssh avec l’utilisateur non privilégié créé ci-dessus :

ssh -l <votre login> <hôte>

(toujours par défaut sur le port 22 avec mot de passe choisi pour le nouveau compte ci-dessus)

mkdir .ssh
cd .ssh
vi authorized_keys

-> coller la clé ssh (longue chaine de texte)

exit

On peut maintenant se connecter sans taper de mot de passe grâce à la clé ssh :

ssh -l <votre login> <hôte>

(toujours sur port 22, mais avec clé ssh, donc sans taper de mot de passe)

4. Sécurisation minimum du serveur

su root
rm /root/.ssh/authorized_keys2
rm /root/.p
rm /root/.email
vi /etc/hostname -> changer nom de machine (genre ksXXXXXX.<votre-domaine>.com)
invoke-rc.d hostname.sh stop
invoke-rc.d hostname.sh start
vi /etc/hosts

-> ajouter nom de machine

aptitude update

aptitude safe-upgrade

(je laisse “all” pour les histoires d’initialisation de disques RAID au démarrage)

aptitude full-upgrade

aptitude install debian-goodies
aptitude install libpam-cracklib wfrench

(utilitaire qui vérifie automatiquement  la qualité des mots de passe, avec un dictionnaire de mots français)

vi /etc/pam.d/su

-> On dé-commente la ligne : auth required pam_wheel.so

vi /etc/pam.d/common-password

-> On rajoute à la fin la ligne : password required pam_cracklib.so retry=3 minlen=8

aptitude install sudo
visudo

-> Ajout de la ligne : %root ALL=(ALL) PASSWD: ALL

apt-get install fail2ban
vi /etc/fail2ban/jail.conf

->

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6
# durée du banissement
bantime = 900
/etc/init.d/fail2ban restart

vi /etc/ssh/sshd_config

-> Port 22000 (pour déplacer l’écoute du daemon ssh sur un port “non standard”)

/etc/init.d/ssh restart
reboot

5. Désinstallation de trucs inutiles / installation de trucs utiles

Cette fois on se reconnecte en ssh sur le port 22000, toujours avec la clé ssh. Vous pouvez d’ailleurs sauvegarder ces paramètres de connexion qui seront définitifs.

ssh -l <votre login> -p 22000 <hôte>
su
aptitude purge bind9 bind9-doc \
 dhcp3-client dhcp3-common gcc \
 gcc-4.2-base libdns43 libisc44 \
 libncurses5-dev manpages-cs \
 manpages-de manpages-de-dev \
 manpages-es manpages-es-extra \
 manpages-it manpages-pl \
 manpages-pl-dev manpages-pt manpages-pt-dev \
 manpages-ru reiserfsprogs
aptitude install openntpd
aptitude install mailx

La suite (installation d’Apache,…) en page 2…

Pages : 1 2 3

A lire également...

{"code":"internal_server_error","message":"

There has been a critical error on your website.<\/p>

Learn more about debugging in WordPress.<\/a><\/p>","data":{"status":500},"additional_errors":[]}