Archives de catégorie : Linux

Installation d’un serveur web sous Debian

Publié le par
Répondre

J’avais lors d’un précédent post, expliqué comment installer WordPress sur son serveur Web mais je n’avais pas expliqué comment installer ce serveur.

On partira donc du principe que l’on a besoin de mettre en place un serveur HTTP, un interpréteur PHP, un SGBD (Système de Gestion de Base de Données) et un serveur FTP. De plus pour le contrôler facilement à distance on utilisera le protocole SSH.

Tout d’abord le choix de la distribution. Ayant toujours utilisé des distributions basées sur Debian et Debian étant réputé pour sa stabilité, il m’a semblé évident de prendre cette distribution comme base. De plus les installations sont facilitées grâce à des dépôts bien remplis (pas toujours à jour, mais fournis).

Ainsi, après une installation standard de cette distribution, enfin, en tout cas sans gestionnaire de fenêtre vu que c’est pour un serveur, nous allons passer à la phase d’installation.

Les logiciels que j’ai choisis d’utiliser pour combler tous nos besoins sont :

  • Serveur HTTP : Apache
  • Serveur FTP : vsFTPd
  • Serveur SSH : openSSH
  • interpréteur PHP : PHP5
  • SGBD : MySQL

Nous allons commencer par installer openSSH afin de pouvoir administrer le serveur à distance par la suite à l’aide de la commande :

apt-get install ssh

Nous verrons les configurations à apporter à chaque logiciel par la suite. Installons maintenant le serveur Apache à l’aide de la commande :

apt-get install apache2

Puis PHP et son module pour apache en tapant :

apt-get install php5 libapache2-mod-php5

Pour MySQL, Debian se charge normalement tout seul de récupérer les paquets qui permettent les interactions avec PHP. Dans le cas contraire il faudra les rajouter en plus (paquet php5-mysql). On tapera donc :

apt-get install mysql-server

Un mot de passe root est demandé à ce moment là. Bien penser à en mettre un fort.

Nous allons enfin installer vsFTPd en tapant :

apt-get install vsftpd

Maintenant que tous les logiciels dont nous avons besoin sont installés, il va nous falloir les configurer. Toujours garder en tête cependant que les configurations sont la partie la plus personnelle de ce genre de mise en place car elles dépendent principalement de ce que l’on désire faire. Je ne détaillerais pas les configurations d’SSH car j’ai déjà mis un exemple détaillé dans ce post ci.

Commençons donc avec la configuration d’Apache. Un fichier de configuration extrêmement important est le fichier /etc/apache2/conf.d/security. C’est ce fichier qui déterminera le niveau de détail des messages d’erreur. Pour un serveur en production, afin d’éviter toute fuite d’information sensible en cas de faille, on mettra les lignes :

ServerTokens Prod
ServerSignature Off
TraceEnable Off

Pour un serveur de développement, le but étant d’obtenir un maximum d’informations, on mettra :

ServerTokens Full
ServerSignature On
TraceEnable Extended

La configuration de base d’Apache donne le dossier /var/www/ comme dossier du site principal. On peut héberger plusieurs sites sur un seul serveur en rajoutant des fichiers de configuration dans le dossier /etc/apache2/sites-available/ (De manière globale, tout fichier présent dans ce dossier est inclus dans le fichier de configuration au lancement d’Apache). Une configuration minimale de site possible est :

<VirtualHost <ADRESSE_DU_SERVEUR>:<PORT_DE_CONNEXION>>
ServerName <NOM_DU_SERVEUR>
ServerAdmin <ADRESSE_DU_WEBMASTER>

DocumentRoot <DOSSIER_DU_SITE>
<Directory <DOSSIER_DU_SITE>>
Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

CustomLog <URI_DU_FICHIER_DE_LOG> combined
LogLevel warn
</VirtualHost>

Pour plus de détail on peut aller sur la documentation officielle d’Apache sans oublier les conseils sur la sécurité. On pourra, selon la distinction que l’on voudra faire entre les différents sites web (différentes adresses IP, différents ports de connexion), utiliser cette page de documentation ou celle ci pour choisir ses options.
Vous remarquerez le -Indexes qui permet de ne pas lister le contenu d’un dossier lorsque le fichier index.html ou index.php n’existe pas. Pour d’autres options de sécurités on peut aller voir par là.

Il ne reste alors plus qu’à activer le site nouvellement configuré à l’aide de la commande

a2ensite <NOM_DU_FICHIER_DE_CONFIGURATION>

et à redémarrer apache (nous ferons ceci à la fin).

En ce qui concerne PHP, je ne rentrerais pas dans les détails de la configuration car ils sont beaucoup trop dépendants de ce que l’on souhaite mettre en place. De plus, ceux de base conviendront la plupart du temps.

La configuration de MySQL étant plus une configuration par base de données que dans sa globalité, les paramètres originaux feront largement l’affaire. Cependant, il ne faudra pas oublier de créer un nouvel utilisateur pour chaque base afin d’améliorer la sécurité et de ne pas laisser traîner le mot de passe root quelque part. J’avais détaillé le script de création dans mon post sur la mise en place de mon blog.

Il nous reste enfin à configurer vsFTPd. Mon choix s’est porté sur ce logiciel plutôt que sur ProFTP, qui est le plus souvent cité lorsque l’on cherche un serveur FTP, car, notamment, il a été conçu en étant orienté sécurité. Le fichier de configuration est /etc/vsftpd.conf. Il est bien détaillé et facile à paramétrer. On peut choisir de chrooter les utilisateurs, utiliser le serveur en IPv4/IPv6, autoriser l’accès anonyme, etc … J’ai détaillé une des configuration que j’utilise sur l’un de mes serveurs dans ce post.

Il suffit ensuite soit de redémarrer la machine (le plus simple), soit de redémarrer tous les services, après configuration. On peut les relancer un par un à l’aide des commandes :

/etc/init.d/apache restart
/etc/init.d/ssh restart
/etc/init.d/vsftpd restart

On a alors un serveur HTTP/FTP/MySQL/SSH prêt à être utilisé.

Configuration de subversion et lancement automatique

Publié le par
Répondre

Depuis quelques temps, j’ai pris l’habitude de gérer mes projets de développement à l’aide d’un gestionnaire de versions, en l’occurrence, subversion. Je n’ai encore jamais eu l’occasion de tester git donc ce choix est simplement basé sur mes préférences actuelles et elles peuvent être amenées à changer. J’utilise subversion car il est libre, facile à mettre en place, agréable à utiliser et surtout, je sais m’en servir.

On peut installer subversion assez simplement soit en passant par les dépôts de paquets des différentes distributions, soit en le compilant soit même (ayant eu besoin de la version 1.7.4 récemment et vu que la version disponible sous xubuntu était la 1.6.17, j’ai été amené à le faire sur mon poste client et cela se fait sans encombre) en installant préalablement ses dépendances (pour ma part zlib, apr et sqlite).

La première chose à faire lorsque subversion est installé est de créer le dépôt qui accueillera le projet. Pour ma part, j’ai créé un dossier /home/SVN dans lequel je créé chacun de mes dépôts à l’aide de la commande :

svnadmin create <nom_du_depot>

Nous allons maintenant configurer le dépôt pour rajouter des utilisateurs et gérer les droits sur les différents dépôts. Pour ce faire, nous allons nous rendre dans le dossier du dépôt, puis dans conf. Dans ce dossier, il y a 3 fichiers qui sont authz, passwd et svnserve.conf. Nous allons tout d’abord modifier le fichier passwd pour rajouter à la fin de nouveaux utilisateurs en suivant ce format :

login = motdepasse

Une fois les utilisateurs et leurs mots de passes ajoutés, nous allons modifier le fichier svnserve.conf. A part lorsque je ne souhaite pas que qui que ce soit puisse lire mon code source si il n’est pas authentifié, je dé-commente les lignes

anon-access = read
auth-access = write
password-db = passwd

Ceci a pour effet d’autoriser la lecture lors d’un accès anonyme et l’écriture pour les utilisateurs authentifiés dont les identifiants sont inscrits dans passwd.

Afin de ne pas laisser ces mots de passes qui sont en clair à la vue de tout le monde, je met les droits des 3 fichiers à 0600.

Il ne reste plus qu’à lancer le serveur à l’aide de la commande suivante :

svnserve -d -r <dossier_contenant_les_depots>

Ici, <dossier_contenant_les_depots> est /home/SVN/.

L’un des problèmes de subversion est que cette action est à répéter à chaque démarrage de la machine. Afin de pallier à ce problème, on peut créer un script de lancement et l’exécuter au démarrage de la machine. Voici le script que j’ai créé (ATTENTION : ce script est adapté à la position de mon dossier subversion mais est à adapter en fonction de la localisation de ce dernier) :

#!/bin/sh
#
### BEGIN INIT INFO
# Provides: svnserve
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start and stop svnserve daemon at boot time
# Description: Controls the main subversion server \svnserve\ with /home/svn
### END INIT INFO

ECHO_BIN=/bin/echo

usage()
{
	$ECHO_BIN "Usage : $0 (stop|start|restart)"
}

SVN_stop()
{
	/sbin/start-stop-daemon --stop --exec /usr/local/bin/svnserve
	$ECHO_BIN "[+] Server stopped"
}

SVN_start()
{
	/usr/local/bin/svnserve -d -r /home/svn
	$ECHO_BIN "[+] Server launched on /home/svn"
}

if [ -x /usr/local/bin/svnserve ]
then
	if [ -z $1 ]
	then
		usage
	else
		case $1 in
			stop)
				SVN_stop
			;;
			start)
				SVN_start
			;;
			restart)
				SVN_stop
				SVN_start
			;;
			*)
				usage
				exit 1
		esac
	fi
else
	$ECHO_BIN "Svnserve not installed."
	exit 1
fi

exit 0

Il faut placer ce script dans /etc/init.d/ et bien penser à lui donner les droits 0755. Une fois à sa place, il ne reste plus qu’à l’activer au lancement de la machine en l’ajoutant aux différents /etc/rcx.d/ à l’aide la commande :

update-rc.d <nom du script> defaults

On peut vérifier à ce moment, après un redémarrage de la machine à l’aide de la commande

ps -e | grep svnserve

que tout est fonctionnel. On pourra alors accéder aux dépots en se connectant à :

svn://<nom_de_domaine_ou_IP>/<nom_du_depot>

Bloquer les documents récents sous Linux

Publié le par
5

Un des problème récurent que je retrouve sur presque toutes les distributions que j’ai pu tester est le stockage des documents récents. Sous Windows, il est possible d’empêcher le stockage des derniers fichiers/documents utilisés en quelques clics depuis le menu de configuration du menu démarrer, alors que sous Linux la configuration est plus compliquée.

Le fichier qui est chargé de stocker la liste des documents récents peut être le fichier

~/.recently-used.xbel
ou
~/.local/share/recently-used.xbel

en fonction de la distribution.

La solution la plus simple et qui a fonctionné sur toutes les distributions que j’ai testé est de supprimer ce fichier puis de le recréer à l’aide de la commande :

touch .recently-used.xbel

On va ensuite changer ses attributs grâce à la commande :

chattr +i <nom_du_fichier>

Ceci va avoir pour effet d’ajouter l’attribut i au fichier recently-used.xbel. Selon la propre documentation de chattr,

A file with the ‘i’ attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Ainsi, aucun logiciel ne sera capable d’écrire les derniers fichiers qui ont été utilisés avec lui et le gestionnaire de fichier ne pourra pas les afficher.

En attendant une solution plus propre et surtout prévue par le gestionnaire de fenêtre, cette solution fait son office.

Activer le wifi sur Xubuntu, sur un PC avec une touche de blocage physique

Publié le par
9

J’ai récupéré un vieux PC portable avec 512Mo de RAM et j’ai décidé d’en faire un PC d’appoint pour les invités qui auraient besoin d’un accès à internet à la maison et qui n’auraient pas amené leur propre ordinateur. J’ai donc installé une distribution Xubuntu dessus, pour divers avantages que je lui trouve, avec tous les logiciels qui vont bien pour une utilisation d’appoint (firefox, vlc, gimp, libreoffice, …). Ce PC est un HP Compaq nx6110 et possède un bouton d’activation/désactivation du Wifi.

Une fois l’installation, avec une connexion câblée, terminée, un problème restait. Le wifi n’était pas activé avec comme source d’erreur un blocage physique. Une petite recherche sur internet m’a permis de trouver comment vérifier cela grâce à la commande :

rfkill list

Celle ci énumère les blocages existant sur les différentes cartes. En effet, ma carte wifi était bloquée physiquement. Un appuie sur le bouton du wifi et le statut avait changé. Je n’ai pas essayé de redémarrer à ce moment là pour savoir si ceci suffisait mais il est fortement possible que oui. J’ai cependant rajouté une étape qui consistait à taper :

rfkill unblock all

Celle ci me permettait de m’assurer qu’aucun blocage n’était maintenu. Après un redémarrage, ma carte était bien reconnue et débloquée mais le pilote n’était pas installé. Afin de savoir lequel installer, j’ai utilisé la commande :

lspci

qui permet de lister tout le matériel disponible dans l’ordinateur dont la carte wifi et ainsi de connaître la marque de celle ci. J’ai pu alors voir que je possédait une broadcom. Il m’a suffit d’installer les pilotes correspondant en l’occurrence :

apt-get install firmware-b43-installer

pour que ma carte wifi soit enfin fonctionnelle.

Une autre solution que j’avais trouvée sur internet mais que je n’ai pas du tout testée consistait à supprimer purement et simplement le fichier /dev/rfkill.

Enlever les memtests de grub

Publié le par
Répondre

Utilisant Xubuntu comme distribution principale, je me retrouve, comme avec Ubuntu d’ailleurs, avec memtest86+ d’installé par défaut. Or cette option me surcharge inutilement mon menu de boot grub alors que je ne suis amené à l’utiliser qu’une fois de temps en temps ou lors d’un gros crash de la machine dans lequel je soupçonne une défaillance matérielle (autant dire rarement).

Jusqu’ici, je supprimais purement et simplement memtest86+ de ma machine sans plus me poser de question puis j’actualisais mon menu avec grub-mkconfig.

Depuis ma dernière mise à jour de Xubuntu qui m’a réinstallé ce délicieux paquet, j’y ai réfléchis à deux fois et je me suis dit que je pouvais être amené à l’utiliser autrement qu’avec un liveCD (en vacances par exemple) et que ce n’était finalement pas une mauvaise chose de le conserver. Je ne voulais cependant toujorus pa qu’il figure dans mon menu de boot.

La solution s’est révélée simple puisqu’il m’a suffit de créer un dossier dans /etc/grub.d/, que j’ai nommé deactivate, mais le nom importe peu, et d’y mettre tous les scripts de /etc/grub.d/ que l’on ne souhaite plus voir exécuté. En l’occurence 20_memtest86+. Une fois ce petit déplacement fait, il suffit de regénérer son fichier /boot/grub/grub.cfg avec la commande :

grub-mkconfig -o /boot/grub/grub.cfg

pour ne plus voir apparaître cet énervant memtest au démarrage. Pour le réactiver, il me suffit de remettre 20_memtest86+ à sa place d’origine et à refaire la commande si dessus.

Installer les drivers de Canon MP490 à partir de paquets théoriquement incompatibles

Publié le par
Répondre

L’autre jour, j’ai voulu installer mon imprimante Canon MP490. Je me suis donc rendu sur le site du constructeur et j’ai récupéré les drivers Linux. Malheureusement, les drivers qui sont disponibles sont compatibles i386 et aucun n’est disponible pour architecture amd64. Deuxième point problématique, ces drivers requièrent des dépendances qui ne sont pas satisfaites sur ma distribution.

Plutôt que de mettre à jour toutes les librairies une à une, j’ai choisi une solution, certes hasardeuse et pas des plus propres, mais qui en l’occurrence a fait ses preuves.

J’ai commencé par décompresser l’archive cnijfilter-mp490series-3.20-1-i386-deb.tar.gz puis je me suis rendu dans le dossier packages que l’on vient d’extraire.

Je me suis basé sur ce post que j’ai trouvé et j’ai appliqué les commandes suivantes à chacun des deux paquets :

dpkg -x [package].deb common
dpkg --control [package].deb
nano DEBIAN/control
#On enlève purement et simplement la ligne "Dependencies"
cp -a DEBIAN/ common/
dpkb -b common [package].deb
rm -rf DEBIAN/ common/

Une fois cette étape faite, il m’a resté à exécuter le script install.sh en temps que root pour installer les pilotes.

Un problème restait cependant après l’installation de l’imprimante. L’imprimante me marquait une erreur de cups insecure filter. Le problème était juste un problème de propriété et il suffisait de faire un chown et un chgrp à root des fichiers qui ne l’étaient pas dans les dossiers :

/usr/lib/cups/filter/
/usr/lib/cups/backend/

Certes ce n’est pas la méthode la plus propre mais elle a l’avantage de marcher. L’imprimante est maintenant reconnue tant pour imprimer que pour scanner.

ACPI, récupération des codes touche

Publié le par
Répondre

Dans mon article précédent, traitant de la création d’un .deb, je parle du script que j’avais créé nommé Asus KBBL Control. Le but était de l’utiliser à travers les raccourcis clavier gérés par l’acpi. Pour savoir quel code correspond à une touche pressée (ou à une combinaison de touches) on utilise la commande suivante :

acpi_listen

Il ne faut pas utiliser la dernière partie du code retourné qui ne correspond pas au code de la touche. Cependant, on peut utiliser le reste pour identifier la touche lors de la création de son event.

Asus Keyboard Backlight Control et paquet .deb

Publié le par
Répondre

Mon ordinateur portable est un Asus G73J. Il est muni d’un rétro-éclairage clavier des plus pratiques. Cependant, les raccourcis de contrôle au clavier ne sont pas fonctionnels sur la plupart des distributions Linux. J’ai donc créé un script qui me permet, à l’aide d’acpi, d’activer ces raccourcis et de contrôler l’intensité du rétro-éclairage et que j’ai nommé Asus KBBL Control (Asus KeyBoard BackLight Control). [EDIT] Il n’est actuellement pas disponible mais reviendra sous peu [/EDIT]

Pour l’installer et le désinstaller plus facilement, j’ai décidé de créer un paquet .deb. Après un peu de recherche, ceci n’est pas difficile et facilite grandement la tâche de maintient d’applications.

Pour ce faire, il suffit de créer un dossier (le nom importe peu). A l’intérieur de ce dossier, il faut créer un paquet nommé DEBIAN. A l’intérieur de ce dossier, on peut mettre plusieurs fichiers dont :

  • preinst : script exécuté avant l’installation
  • postinst : script exécuté après l’installation
  • prerm : script exécuté avant la suppression
  • postrm : script exécuté après la suppression
  • control : Détails du paquet

Un de ces fichiers est obligatoire cependant, c’est le fichier control. C’est à partir de lui que le paquet final est construit (notamment le nom). Pour plus de détail sur sa construction, il suffit de regarder la manpage :

man deb-control

Cette page étant largement détaillée, je n’entrerais pas dans les détails.

Le logiciel que l’on souhaite empaqueter se met à côté du dossier DEBIAN. On va le placer dans le dossier dans lequel il sera installé en considérant ce dossier comme la racine du disque dur. Ainsi, si mon programme doit être installé dans /etc/acpi, je vais créer à côté de DEBIAN un dossier etc dans lequel je créerais un dossier acpi et dans lequel enfin je mettrais mon programme à installer.

Une fois cette petite cuisine effectuée, il ne reste plus qu’à compiler le paquet. Pour cela, on se place un dossier au dessus du dossier qui contient DEBIAN et le logiciel et on tapera la commande :

dpkg-deb --build <NOM DU DOSSIER>

On a un magnifique fichier .deb qui se créé juste à côté de notre dossier source et qu’il ne restera plus qu’à installer avec un :

dpkg -i <NOM DU PAQUET>

Configuration de mes connexions SSH

Publié le par
Répondre

J’administre tous mes serveurs (tous sous Linux) en ligne de commande. L’interface graphique consomme en effet beaucoup de ressources inutilement et n’est pas nécessaire pour seulement quelques accès par mois. De plus, la ligne de commande est plus puissante.

Pour me connecter simplement et en toute sécurité j’utilise le protocole SSH qui est parfaitement adapté à la situation. Voici les quelques configurations que j’applique systématiquement.

Je commence tout d’abord par me générer une paire de clés qui me serviront à me connecter par la suite. Cette étape peut n’être faite qu’une fois, puisqu’il suffira d’utiliser la même clé pour tous ses serveurs après. La commande est :

ssh-keygen -t rsa -b 2048

Ceci générera une paire de clés RSA de 2048 bits. Il suffit de suivre les instructions lors de la génération des clés pour mettre un mot de passe à ces clés. Je copie ensuite la clé publique générée dans <HOME>/.ssh/authorized_keys sur le serveur.

Je modifie ensuite le fichier /etc/ssh/sshd_config de la manière suivante pour appliquer mes réglages de sécurité (ATTENTION : sans accès physique à la machine, laisser le paramètre PasswordAuthentication à yes jusqu’à ce que la connexion soit réussie avec la clé, autrement il sera très contraignant d’arriver à se reconnecter) :

# Numéro du port en écoute sur lequel on se connecte
Port <NUMERO DE PORT>

# Vérifier que la version est bien la 2 car la version 1 avait une faille critique
Protocol 2

# Bannière affichée avant l’autorisation de connexion (Je le met rarement mais ça égaye un peu la console à la connexion)
#Banner /etc/issue.net

# Empêche la connexion directe en root
# N’empêche pas de se connecter en root depuis un autre utilisateur
PermitRootLogin no

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Temps en seconde pendant laquelle une connexion est ouverte sans être loggué
LoginGraceTime 10

# Nombre maximum d’essais d’authentification autorisés
MaxAuthTries 1

#Types d’authentifications autorisés
PubkeyAuthentication yes
RSAAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM no
PasswordAuthentication no

# Fichier contenant les clés autorisées
AuthorizedKeysFile %h/.ssh/authorized_keys

#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Logging
SyslogFacility AUTH
LogLevel INFO

# check file modes and ownership of the user’s files and home directory before accepting login
StrictModes yes

# Don’t read the user’s ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to ‘yes’ to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of « PermitRootLogin without-password ».
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to ‘no’.

# La plupart du temps je n’autorise que mon compte à se connecter
AllowUsers <NOM_DES_UTILISATEURS_AUTORISES>

# Si il faut mettre plusieurs comptes, mieux vaut utiliser ceci
#AllowGroups <NOM_DU_GROUPE_AUQUEL_APPARTIENNENT_TOUS_LES_COMPTES_AUTORISES>

# On peut aussi choisir de refuser juste certains utilisateurs/groupes
#DenyUsers <NOM_DES_UTILISATEURS_REFUSES>
# DenyGroups <NOM_DU_GROUPE_AUQUEL_APPARTIENNENT_TOUS_LES_COMPTES_REFUSES>

Une fois ce fichier modifié, je relance ssh à l’aide de :

/etc/init.d/ssh restart

et me voilà avec un serveur disposant d’une connexion SSH correctement sécurisée.

Configuration de grub

Publié le par
Répondre

Installant toujours plusieurs systèmes d’exploitations sur mon ordinateur portable, j’ai besoin d’un bootloader me permettant de switcher facilement entre eux. Je détaillerais dans un prochain article les différents systèmes d’exploitation que j’utilise.

La version de grub que j’utilise est la version Grub 2 aussi connue sous le nom de grub-pc  (à l’opposé de la version 1, aussi nommée, grub-legacy).

Le fichier de configuration qui sera lu à chaque démarrage est le fichier /boot/grub/grub.cfg. Ce fichier est reconstruit à chaque fois qu’une nouvelle version du noyau est installée, ou, plus globalement à chaque fois que la commande grub-mkconfig est exécutée. Elle se sert des scripts situés dans /etc/grub.d/ pour générer le fichier de boot, ainsi que de /etc/default/grub.

Mes besoins de personnalisation de grub se limitent à l’édition de /etc/default/grub que je modifie comme ceci :

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=5
GRUB_GFXMODE=1920×1080
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT= »quiet splash »
GRUB_CMDLINE_LINUX= » »

Je boot ainsi sur le premier élément de ma liste par défaut après 5 secondes si aucune touche n’est pressée.

Pour avoir plus de détail sur les options de ce fichier, on peut lancer la commande :

info -f grub -n 'Simple configuration'

Je rajoute depuis peu une image de fond à grub. Contrairement à grub-legacy, ceci est d’une simplicité déconcertante puisqu’il suffit de copier une image dans /boot/grub pour qu’elle soit automatiquement détectée et ajoutée à grub.cfg lors de sa génération. La première image rencontrée par ordre alphabétique est utilisée. Les formats jpg, png et tga sont supportés. Si l’on souhaite le faire manuellement, il est possible de spécifier le chemin de l’image avec l’option « GRUB_BACKGROUND=« .

Enfin, je supprime toujours memtest86+ dans /boot/ pour ne pas avoir une entrée dans le menu alors que je ne fais des tests mémoires que quand je rencontre des problèmes matériels (autant dire presque jamais).

Je compte rajouter un mot de passe sous peu pour bloquer l’accès à l’édition des commandes de boot. Ceci permet en effet de pallier à une faille de sécurité importante, conservée pour permettre le changement du mot de passe root en cas d’oublie, et qui permet de lancer un shell en super utilisateur, sans demander de mot de passe.