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
Mise en garde
Pour des raisons de pédagogies on utilise l'email mail2sh@yourdomain.tld, notamment pour GPG, et le terme "mail2sh". Dans un environnement de production il est vivement conseillé de remplacer ces informations par d'autres plus discrète. Ceci afin de ne pas attirer l'attention de personnes malveillantes !
Prérequis
Si vous utilisez un gestionnaire de paquet Debian, lancer l'installation du paquet Mail2shell va gérer l'installation des dépendances.
Autrement voici la listes des paquets utile :
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)
Pour commencer, connectons-nous au compte :
sudo -u mail2sh bash
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
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 !
Divers
J'ai écris 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
Voici une phrase qui nécessite une source.[1]
- ↑ Nom de l'auteur, Titre du livre, Éditeur, Année, p.123.
- ↑ Auteur, Livre, 2020, p.45.
- ↑ Article pertinent, Site Example, consulté le 10/01/2023.