Mail2sh/FR/Tutoriel
Tutoriel
Mail2shell
version 1.9-1
anciennement mail2sh 1.5-1
Créé en 2001 et rendu publique en 2002 jusqu’à aujourd’hui.
Auteur
José Mans
Administrateur système et réseaux.
Introduction
Public et Cas d'Usage
Sécurité et Contexte
Table des matières
Petit rappel de base
Variable d'environnement
Mise en garde
Par souci pédagogique, les termes "mail2sh" et "mail2sh@yourdomain.tld" vont être utilisés tout au long de ce document, notamment concernant la création des clés privées/publiques de Mail2shell.
Cependant, si vous devez utiliser ce programme dans un environnement de production, il est fortement conseillé d'utiliser d'autres termes que ceux cités précédemment.
Ceci afin de rester le plus discret possible des bots et personnes malveillantes qui scrutent le trafic réseau ;)
Prérequis
Si vous utilisez un gestionnaire de paquet Debian, les dépendances de Mail2shell seront automatiquement ajoutées à votre OS.
Autrement voici la listes des paquets utilisés :
Debian / Ubuntu
apt-get install perl-base libemail-mime-perl libemail-sender-perl libgnupg-interface-perl libio-all-perl liblocale-gettext-perl adduser util-linux sudo coreutils
D'autre part il est nécessaire d'avoir un Mail Transport Agent (MTA) fonctionnel comme Postfix pouvant gérer la directive .forward.
Un exemple de configuration est proposé plus bas.
Autre distribution
Liste des modules et outils à installer avec votre distribution :
Perl 5.22
* Email::MIME
* Email::Sender
* GnuPG::Interface
* IO::All
* Locale::gettext
Operating System
* adduser / addgroup
* util-linux, pour sulogin
* sudoers
Mail-Transport-Agent (MTA)
* postfix, exim, sendmail, ... # Prenant en charge la gestion du .forward
Installation de mail2shell
Automatique
Cette méthode ne prends en charge que la configuration et installation qui concerne Mail2shell. Celle qui concerne votre MTA n'est donc pas traitée.
Pour une installation automatique trois paquets sont disponibles :
- Debian / Ubuntu / à base de .deb
- Testé sur Ubuntu LTS18, LTS20, LTS22 et LTS24 !
sudo dpkg -i mail2shell_1.9.0-1_all.deb
- Redhat .RPM (non testé!)
sudo rpm -vih mail2shell-1.9.0-1.noarch.rpm
- Tout autre distribution non rpm/deb.
sudo tar xvfz mail2shell-1.9.0.tgz -C/
sudo bash /usr/share/doc/mail2sh/install.sh configure'''
Cette méthode crée un compte unix nommé « mail2sh » et ajoute l'autorisation à suoder pour qu'il soit exécuté en tant root.
Mails2shell peut fonctionner sans les droits de root, voir Précision sur la sécurité
Le HOMEDIR contient l’exécutable « mail2shell» et le fichier destiné à le lancer, à chaque réception de courrier, soit ici /var/llib/mail2sh/.forward.
Cependant ce programme d’automatisation ne prend pas en charge la gestion des emails pour les serveurs de messagerie (MTA) configurés pour la virtualisation des emails/domaines. Vous devrez l’effectuer manuellement, voir la partie : Serveur de messagerie ci-dessous.
Manuelle
Pour permettre un usage rapide pour des tests, un programme d’installation est livré depuis 2001 avec mail2sh, il permet d’automatiser toutes les étapes essentielles pour son fonctionnement.
Cependant je préfère vous montrer la méthode manuelle afin de donner un aperçu du fonctionnement de mail2shell.
Il est nécessaire d’avoir 3 fichiers,
- la configuration
- l’exécutable
- une procédure d’élévation de droit comme sudoer
Compte mail2sh
On créait le compte avant le déploiement du paquet, ceci afin que 'tar' garde les bons droits
sudo addgroup mail2sh
sudo adduser –system –home /var/lib/mail2sh –ingroup mail2sh –shell /bin/bash
Déploiement
Commençons à déployer l’archive de l’application :
wget https://mans.gyptis.org/ce_que_je_fais/logiciels_softs/mail2sh/mail2shell-current.tgz
sudo tar xvfz mail2shell-current.tgz -C/
cd /etc/mail2sh
edit Mail2shell.conf
<!> changer les accès cités en exemple par ceux de votre choix,
voir Gestion des utilisateurs ci-dessous.
Il ne reste plus qu’à gérer :
- les droits d’exécutions
- Voir section : sudoers
- d’activer le routage des emails vers l’exécutable de mail2shell.
- Voir section : Serveur de messagerie.
- Les droits des utilisateurs :
- par import les clefs publiques
- si vous utilisez GnuPG
- par saisi d’un identifiant et mot de passe en clair
- voir « Gestion des utilisateurs »
- par import les clefs publiques
Sudoers
Si vous utilisez cette version de sudo vous devrez ajouter les droits d’exécution de root à Mail2shell en ajoutant ces lignes :
sudo cat - <<EOF > /etc/sudoers.d/mail2sh
#-- MAIL2SH begin
mail2sh ALL = (root) NOPASSWD: /var/lib/mail2sh/mail2shell
#-- MAIL2SH end
EOF
< !> Sans sudoer, mail2shell pourra traiter vos emails de commande avec les droits par défaut qui sont ‘mail2sh’. Pour davantage de détail sur la sécurité voir Précision sur la sécurité.
Serveur de messagerie
Pour ma part j’utilise Postfix avec une virtualisation des domaines.
Si c’est votre cas, il est important de comprendre une chose essentielle :
Postfix
Pour ce faire vous devez configurer le « transport » en précisant quel email doit-être exécuté en local pour mail2sh@yourdomain.dtl.
sudo postconf transport_maps
transport_maps = hash:/etc/postfix/transport
[mailto:mail2sh@YourDomain.dtl mail2sh@YourDomain.dtl] local
sudo postmap /etc/postfix/transport
sudo postfix reload
GnuPG installation des clefs
Cette partie est la plus sensible de la nouvelle version de Mail2shell. Je vous recommande donc la plus grand vigilance et d’utiliser un tutoriel de qualité sur l’usage de GnuPG, voire d’utiliser ChatGPT 4o qui connaît « Mail2shell » est davantage à jour par rapport à Claude, DeepSeek, Gémini 2.0 (date des essais 2025 03 10)
Ajouter des clefs publiques dans le trousseau du compte qui gère mail2shell
se rendre dans le HOMEDIR de mail2shell :
cd ~mail2sh/
AVANT TOUT
Il est impératif de créer la clef privée pour le compte qui reçoit les emails :
gpg --full-generate-key
Importer une clef publique d'un utilisateur
gpg --keyserver keys.openpgp.org --search-keys user1@yourdomain.tld
choisir 1, la clef sera importée.
OU
gpg --receive-keys keyIDs
clef automatiquement importée.
Valider et attribuer sa confiance à une clef publique
gpg --edit-key user1@yourdomain.tld
sign
trust (choisir 5)
Fonctionnement
Réception des commandes
Une fois l’installation de Mail2shell effectuée, vous pourrez commencer à lui envoyer des ordres par simple email à l’adresse que vous avez choisi dans la configuration de votre MTA. Par exemple l’email mail2sh@YourDomain.dtl sera utilisé.
Toutefois si vous souhaitez joindre des pièces attachées il vous faudra un MUA compatible MIME tel que Thunderbird, Mutt ou Outlook.
Une fois vos ordres rédigés dans votre email, il reste plus qu’à l’envoyer à mail2sh@YourDomain.dtl !
Votre MTA se chargera d’exécuter le script /var/lib/mail2sh/mail2shell via procmail. La procédure se trouve dans /var/lib/mail2sh/.forward
Si Mail2shell reconnaît l’identité de l’expéditeur, ce dernier recevra une réponse avec le résultat de l’exécution de ses ordres (sortie standard stdout et stderr incluses)
Précision sur la sécurité
Par défaut, mail2shell est exécuté avec les droits de root via sudo depuis le .forward…
Cependant, vous pouvez limiter son exécution à un seul utilisateur non-administrateur.
Vous devez juste ajouter dans Mail2shell.conf :
single_user on
user_default mail2sh
supprimer tout les mot clef «bless» et «login» de que chaque section <site> existante.
Pour finir, remplacer le contenu du ~mail2sh/.forward par :
Le mode multi-utilisateur et préservé, mais tous les ordres seront exécutés avec un seul compte local.
Exemple d’ordres, corps du message :
Email à envoyer à mail2sh@YourDomain.dtl
site marc 111
id
date
pwd
echo $IP1 est l’ip du host expéditeur
quit
--
signature!
Discrétion de Mail2shell
Si tout se passe bien, vous recevrez une réponse de mail2sh@YourDomain.dtl ressemblant à :
mail2sh: echo
mail2sh: id
uid=147(mail2sh) gid=1007(mail2sh) groups=1007(mail2sh),0(root)
mail2sh: date
Fri Apr 18 17:13:44 CEST 2025
mail2sh: pwd
/var/lib/mail2sh
mail2sh: echo $IP1 est l’ip du host expéditeur
1.2.3.4 est l’ip du host expéditeur
-- /tmp/mail2sh.tmp.682992.stdout.txt ---------------------------------------------------------------------
<log id="shell" type="shell" txt="Command execution report, return code='0'">
<stdout id="shell">
mail2sh: echo
mail2sh: id
uid=147(mail2sh) gid=1007(mail2sh) groups=1007(mail2sh),0(root)
mail2sh: date
Fri Apr 18 17:13:44 CEST 2025
mail2sh: pwd
/var/lib/mail2sh
mail2sh: echo $IP1 est l’ip du host expéditeur
1.2.3.4 est l’ip du host expéditeur
</stdout>
<stderr id="shell">
</stderr>
</log>
En revanche, si l’identification à échouée Mail2shell ne donnera aucune réponse. Ceci afin de ne pas valider l’existence de mail2shell sur votre OS et ainsi réduire les risques d'attaque DoS, en autre...
Cependant cette restriction peut-être levée dans Mail2shell.conf via l’option :
response_unknown 1
Identification
GnuPG
Depuis la version 1.9, il est possible de valider l’identification de vos utilisateurs avec leurs clefs publique générée par GnuPG.
Chaque expéditeur devra simplement être ajouté dans le trousseau de clef de GnuPG du dossier (HOMEDIR) de mail2shell.
Par défaut c’est /var/lib/mail2sh/.gnupg.
Pour ajouter ces utilisateurs il faudra utiliser les commandes d’import, signature et validation du niveau de confiance pour chaque clef. Voir GnuPG installation.
Identification à l’ancienne !
Si vous n’avez pas la possibilité d’envoyer vos commandes avec un email crypté par GnuPG il reste l’ancienne méthode de 2002 !
Elle peut vous dépanner si vous n’avez pas vos clef là où vous vous trouvez !
Vous devrez simplement ajouter en début du corps du message la ligne suivante :
site login password
Exemple :
site marc 111
Commande propre à Mail2shell
Les commandes qui suivent peuvent être placées dans le corps de votre message avec vos ordres.
site User Password
verbose 0 à 128
timeout_exec time_in_second
Par défaut il vaut 3 seconds.L’expéditeur pourrait avoir besoin de davantage de temps pour un ordre gourmand en temps, un scan de virus ou de port !
time_in_second peut être sous forme :digit :[smhdMy]
soit une des valeurs : 10, 10s, 3m, 1d, 1M, 1y, ...
‘s’ pour second, ‘m’ minutes, ‘h’ heure,, ‘d’ jour, ‘M’ mois, ‘y’ annéequit
Gestion des utilisateurs
La gestion des droits d’utilisation s’effectue dans /etc/mail2sh/Mail2sh.conf.
La partie qui gère vos utilisateurs est représentée par la section <site><user1>...</user1></site>
Exemple fournit dans l’archive :
...
<site>
<user1>
password 111
reply-to mans@YourDomain.dtl
bless
</user1>
<guest>
password 111
reply-to guest@YourDomain.dtl
</guest>
<marc>
password 111
reply-to marc@YourDomain.dtl
login guest
</marc>
</site>
Explication
La section <site> indique la liste des utilisateurs pouvant utiliser mail2shell.
Chaque utilisateur est renseigné dans une sous section portant le nom de l’identifiant local du compte utilisateur.
Ici user1 est un compte local déclaré dans /etc/password à l’aide de adduser… Idem pour « guest ».
Le mot de pass, représenté par password, est stocké en clair – Il ne doit pas être celui qui donne accès au compte local via ssh ou login !!!!!
Exception
Le compte « marc » n’a pas d’existence sur le système des comptes de Linux. On peut considéré qu’il soit virtuel.
Sa déclaration est faite afin que « marc@YourDomain.dtl » puisse utiliser mail2shell avec sa clef GnuPG.
Donc si « marc » envoi des commandes à mail2shell, il le fera en cryptant son email.
L’utilisateur local qui va exécuter les commandes de Marc est représenté par « login », ici il vaut « guest ».
Bien entendu si <marc> envoi un email non crypté par gpg, il devra utiliser la commande « site marc 111 » en début de son courrier.
Évidement il est fortement conseillé d’utiliser GnuPG pour tout envoi de commande par email à mail2shell !
Petit rappel de base
Concernant les emails au format MIME : Le "corps du message" représente la partie qui est adressée à l'expéditeur. En ce qui nous concerne, il s'agit de celle contenant les ordres à envoyer à Mail2shell. Quand un email est organisé avec MIME, "ce corps du message" est considéré comme la première pièce attachée. Elle est codée comme un message texte (text/plain 7bit flowed). Par défaut, et navré de ne pas entrer dans les détails, Thunderbird et Outlook (tous deux MUA) ajoutent une deuxième pièce attachée. Il s'agit du même message que le premier, mais au format HTML (text/html).
Mail2shell est programmé pour gérer ce genre d'email. Cependant, en ce qui concerne les variables d'environnement, vous devez garder à l'esprit que le N° de pièces attachées peut changer. Dans cet exemple, le 1er message aura le N°0 et le 2e le N°1.
Or, selon vos réglages ou la détection par votre MUA, la 2e pièce attachée pourrait ne pas être présente dans l'email envoyé ! Vous devez donc correctement régler votre MUA pour qu'il soit cohérent. Chez moi, Thunderbird est réglé pour envoyer mes emails aux deux formats Text et HTML quoi qu'il arrive. J'ai donc désactivé le mode "automatique" pour ne pas avoir de surprises...
Variable d'environnement
Depuis sa version 1.9.0, Mail2shell transmet au Shell des informations contenues dans l'email reçu sous forme de variable.
À savoir :
- Le nom des fichiers attachés
- La route empruntée par l'email.
<!> Conseil : lire Petit rappel de base
Fichiers attachés
Si vous souhaitez faire exécuter un script spécifique, il suffit simplement de l'attacher à l'email envoyé à Mail2shell. Une fois vos ordres reçus, le shell pourra utiliser ces fichiers grâce au tableau `FILES()` ou aux variables `FILEn`.
Imaginons qu'on veuille traiter 2 fichiers par le shell distant, on joint ces fichiers au corps du message. À la réception, Mail2shell se charge de référencer les pièces jointes dans un tableau (ARRAY) nommé "FILES" et une suite de variables FILEn ; vous pourrez utiliser une de ces deux formes au choix.
Utiliser ces données avec /bin/bash :
Tableau (ARRAY)
`FILES` est un tableau (ARRAY) déclaré ainsi : `FILES=()` Les pièces jointes à l'email sont ajoutées de cette façon :
`FILES+=(Corps_du_message_au_format_Text...)`
`FILES+=(Corps_du_message_au_format_Html...)`
`FILES+=(1er_fichier_attaché)`
`FILES+=(2e_fichier_attaché)`
Accès au contenu avec 'for'
count=0; for attach in "${FILES[@]}"; do echo "file name attach N°$count : $attach"; ((count+=1)); done
Accès direct au contenu
echo "${FILES[0]}" est le corps du message au format Text, soit 1er fichier attaché
echo "${FILES[1]}" est le corps du message au format Html, soit 2e fichier attaché
echo "${FILES[2]}" est le 3e fichier attaché
echo "${FILES[3]}" est le 4e fichier attaché
FILEn
`FILEn` représente chaque fichier attaché, "n" est le numéro de la pièce attachée. Dans notre exemple, n est compris entre 0 et 3.
echo "$FILES0" est le corps du message au format Text, soit 1er fichier attaché
echo "$FILES1" est le corps du message au format Html, soit 2e fichier attaché
echo "$FILES2" est le 3e fichier attaché
echo "$FILES3" est le 4e fichier attaché
IP de l'expéditeur
Fonctionne de la même manière que `FILES` et `FILEn`.
Ici, il s'agit donc de `${IPS[@]}` et `IPn`.
`IPS=()`
`IPn`, n variable numérique.
Divers
J'ai écrit ce tuto assez rapidement pendant ma semaine de vacances, aussi je suis conscient qu'il n'est pas parfait.
SVP, n'hésitez pas à m'envoyer vos questions à Formulaire de contact afin d'aider la communauté à faire progresser ce tutoriel !
Vous pouvez aussi utiliser le forum sur SourceForge : Tickets
Références
FR – Tutoriel GnuPG : https://linuxfr.org/news/bien-demarrer-avec-gnupg
EN – Tutorial GnuPG : https://help.ubuntu.com/community/GnuPrivacyGuardHowto
Licence
Disponible à https://mans.gyptis.org/w/Mail2shell_licence