Soyez sûr d'être dans le repertoire des sources du noyau.
cd /usr/src/linux/
Cette étape peut s'appliquer dans le cas où vous avez déjà des sources compilées dans le dossier /usr/src/linux/. Elle s'utilise principalement lorsque vous avez modifier plusieurs fois votre configuration et que vous avez passé certains modules dans le kernel.
En effet, il peut être parfois utile de supprimer les fichiers compilés de l'arborescence des sources avant de commencer la procédure de compilation.
Il existe plusieurs commande pour effectuer cette étape de “nettoyage” :
make clean
et
make mrproper
make clean supprime tous les fichiers compilés.
make mrproper supprime tous les fichiers compilés ainsi que
le fichier de configuration .config qui contient les options de configuration du kernel.
Notez que la compilation durera plus longtemps, tous les fichiers devant être recompilés à nouveau. En effet, par défaut, seules les options modifiées sont recompilées.
Récupération de la configuration
Cette étape optionnelle permet de récuperer les paramètres déjà définis dans le noyau courant, ce qui est intéressant si vous avez déjà personnalisé votre noyau courant et que vous désirez l'utiliser comme base pour le nouveau noyau. Pour effectuer ceci, récutez les commandes suivantes :
zcat /proc/config.gz > .config
make oldconfig.
La configuration du noyau courant est contenu dans le fichier /proc/config.gz. La commande make oldconfig utilise le fichier /usr/src/linux/.config (issu de la commande précédente) comme modèle pour la configuration du nouveau kernel. Si le fichier .config n'existe pas, la configuration par défaut incluse dans les sources du noyau sera utilisée.
zcat /proc/config.gz si activé dans la conf du kernel.
ou dans /boot/
Mais cela peut créer une potentielle faille de sécurité : les utilisateurs ayant les droits suffisants sur le serveur (par exemple, root) pourront avoir accès à votre agent ssh, et donc utiliser vos clefs à votre insu, le temps de la session. Spécifier l’option “-c” lors de l’ajout de la clef à votre agent permet de limiter le risque, en vous demandant confirmation avant chaque utilisation de la clef.
# Utilisation de l’option "AgentForwarding" en spécifiant le flag "-A"
client> ssh -A user@62.23.55.220
# Vous pouvez désormais vous connecter sur le serveur cible : les clefs dans le SSH agent de votre client local seront utilisées.
bastion> ssh user@192.168.0.10
Bien évidemment, cela nécessite d’ajouter vos clefs publiques sur toutes les machines cibles.
Pour vous faciliter la vie, vous pouvez formaliser ces méthodes de connexion dans un fichier de configuration : celui par défaut (~/.ssh/config) ou bien un fichier qui vous spécifierez explicitement comme ceci :
client> ssh -F $FICHIER_DE_CONF_SSH
Pour notre exemple, cela donnera le fichier suivant :
Host bastion
Hostname 62.23.55.220
IdentityFile ~/.ssh/myPrivateKey
User user
Host serveurA
ProxyJump bastion
Hostname 192.168.0.10
IdentityFile ~/.ssh/myPrivateKey
User user
Vous pourrez ainsi vous connecter directement à vos machines, sans spécifier la mécanique derrière, comme suit :
client > ssh serveurA
En utilisant ProxyJump, vous n’effectuez pas de connexion depuis le bastion, car toutes vos connexions sont initiées directement depuis le client.