vendredi 03 juillet
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

: UUCP à travers SSH: la meilleure configuration mail

Posté par Fabien Penso (Jabber id, page perso, ). Modéré le 08 avril 2001.
0
Voici un petit document qui vous explique comment configurer UUCP à travers une connexion SSH. C'est la configuration idéale pour le mail, que ce soit pour quelqu'un qui se connecte à travers un modem, que quelqu'un qui se connecte en ADSL/Câble. Si vous avez un portable et que vous êtes nomade, c'est *la configuration* que vous devez utiliser. Cependant il vous faudra avoir la main sur votre serveur de mail, si ce n'est pas le cas vous pouvez toujours utiliser UUCP sans SSH en prenant un fournisseur d'accès tel que FRMUG ou FDN.
Commentaires bienvenues.

> Lire la suite (31 commentaires, moyenne: 0,4).   [dépêche : 9392 caractères]

UUCP+SSH: La manière idéale de récupérer vos mails!

Fabien Penso mailto:penso@linuxfr.org

07 Avril 2001

Un bref article sur la configuration d'une connexion UUCP à travers SSH (sur IP) pour le rapatriement de ses mails chez soi.

1. Introduction

Voici un bref document qui explique comment utiliser UUCP à travers SSH sur IP.

Je pars du principe que vous avez la main sur le serveur, et que les machines sont installées sous Debian (Woody) avec les packages UUCP, openssh et postfix. Cependant il ne devrait pas être difficile de le faire marcher sur d'autres type de machines.

2. Avantages et inconvénients par rapport à d'autres systèmes

Les avantages de ce type de connexion sont multiples. En plus d'être très efficace pour les personnes qui se connectent par modem, il est aussi très intéressant pour ceux qui ont la chance, comme moi, d'utiliser une connexion permanente type ADSL ou Câble.

En effet, beaucoup se posent la question sur la manière la plus rapide et pratique pour récupérer leurs mails à travers une connexion cryptée (POP ne l'est pas) tout en ayant ses mails sur sa machine (IMAP laisse les mails sur le serveur). Il n'existe que peu de solutions performantes, UUCP m'a semblé la meilleure.

L'autre solution qui parait possible est l'installation du logiciel postfix-tls (encryption et authentification) cependant il faudra alors que les deux postfix soient configurés avec l'extension tls. On pourra alors faire en sorte que lorsque le serveur reçoit un mail pour user@domain.fr il renvoie automatiquement sur user@posteclient.domain.fr (en partant du principe que votre machine est connectée en permanence, et dans le cas ou elle a une IP adressée dynamiquement qu'elle utilise un service type dyndns pour avoir un domaine fixe). Cependant dans le cas ou votre machine ne serait pas accessible pendant plus de 5 jours (vacances, problème de connexion, etc) les mails seraient alors renvoyés à l'expediteur avec un message d'erreur. Fâcheux ...

L'avantage de la solution UUCP est qu'elle ne vous oblige pas à avoir une connexion permanente, ni un domaine associé à votre machine, ce qui évite l'utilisation des services de DNS dynamiques. Cependant je conseille pour votre confort de les utiliser quand même si vous êtes câblé :-)

Il reste cependant un inconvénient, vous ne recevrez pas vos mails en temps réel dès leur arrivé sur le serveur de mail, mais seulement quand vous, poste client, lancerez votre commande UUCP. Chez moi mon crontab est configuré pour le lancer toutes les 10 minutes, ce qui est largement suffisant.

Résumons donc quelques avantages/inconvénients d'un système UUCP+SSH:

  1. Vous récupérez vos mails à travers une connexion cryptée
  2. Vous avez la certitude du poste client (grâce aux clefs RSA)
  3. Vous pouvez récupérer tous les mails pour votre machine, et avez donc la possibilité d'héberger plusieurs comptes (papa, maman, La femme, le chien, etc) dont vous recevez les mails en une seule fois.
  4. Vous pouvez ne pas être là pendant un long moment, les mails seront mis de côté pour vous sur le serveur.
  5. Vous pouvez taper vos mails sur le poste client, et ne vous connecter que plusieurs semaines après pour les envoyer, vous n'aurez pas de message d'erreur de votre postfix local.
  6. Un temps équivalent au maximum à l'intervalle de temps que vous avez configuré dans crontab est nécessaire pour que vous récupériez vos mails.

Bref, que des avantages ! :-)

3. Explication sur l'architecture réseau de l'exemple

Voici des détails sur l'architecture réseau utilisée dans l'exemple que j'utilise dans cet article.

Nous avons deux machines:

  1. Le serveur connecté en permanence sur Internet. On l'appellera « serveur » et on considère que son domaine est machin.fr. Son nom complet est donc serveur.machin.fr. Cette machine tourne sous Debian, avec les packages UUCP, postfix, et openssh installés.
  2. La station de travail qui se trouve chez vous. On l'appellera « station », qui est le résultat de la commande hostname. Cette machine peut être connectée en permanence (Câble, ADSL) ou bien être derrière une connexion PPP par l'intermédiaire d'un fournisseur d'accès.

4. Configuration du client

Je considère donc que vous avez installé UUCP, postfix, openssh et que postfix accepte les mails pour @station.machin.fr (attention: ceci est important sinon le système bouclera!).

Éditez le fichier /etc/uucp/sys et ajoutez à la fin: 

              system serveur (serveur est donc à remplacer par le nom de votre machine serveur)
              alias serveur-ssh
              call-login *
              call-password *
              time any
              address serveur.machin.fr
              port SSH
              protocol t
              remote-send /
              remote-receive ~

Éditez le fichier /etc/uucp/port et ajoutez à la fin: 


              port SSH
              type pipe
              command /usr/bin/ssh -C -x -o batchmode=yes uucp@serveur.machin.fr

Éditez le fichier /etc/uucp/call et ajoutez à la fin: 

              serveur   votrelogin   votremotdepasse
Vous pouvez utiliser ce que vous voulez à la place de votrelogin et votremotdepasse sachant qu'il suffira de mettre les mêmes du côté du serveur, tout simplement.

Passez en utilisateur uucp (su - uucp) et lancez ssh-keygen. On vous demandera un mot de passe, n'en tapez pas ! Il n'y a pas de problème de sécurité si votre utilisateur UUCP n'a pas d'accès par mot de passe dans /etc/passwd. Cette étape permet de générer une clef RSA qui se trouve dans uucp/.ssh/identity.pub, nous en aurons besoin plus tard.

5. Configuration du serveur

Je considère que vous avez installé UUCP, postfix et openssh.

Éditez le fichier /etc/uucp/sys et configurez de la manière suivante: 

            protocol gvG
            protocol-parameter G packet-size 1024
            protocol-parameter G short-packets
            
            # Client 1
            system station (station est donc à remplacer par le nom du client)
            time any
            port TCP
            protocol t
            remote-send ~
            remote-receive /

            # ... Autre clients (mêmes lignes)

Éditez le fichier /etc/uucp/passwd et rajoutez à la fin: 

            votrelogin votremotdepasse

Éditez le fichier /etc/postfix/transport et rajoutez: 

            station.machin.fr uucp:station

Éditez /etc/aliases et rajoutez: 

            votrelogin: votrelogin@station.machin.fr

Lancez postmap /etc/postfix/transport, postalias /etc/aliases et relancez postfix. Désormais les mails qui sont envoyés à votrelogin@machin.fr devrait être renvoyés à votrelogin@station.machin.fr et mis dans le spool UUCP pour la machine station dans /var/spool/uucp/station/ (voir /var/log/mail.log). Si ce n'est pas le cas, alors quelque chose ne va pas dans votre configuration postfix.

Ensuite allez dans /var/spool/uucp/ et créez un répertoire .ssh puis un fichier authorized_keys (le répertoire et le fichier doivent n'être en lecture que pour l'utilisateur uucp. chmod -R og-rxw .ssh devrait faire l'affaire).

Dans le fichier authorized_keys, rajoutez la clef RSA de votre poste client précédée de command="/usr/sbin/uucico -D -l", ce qui devrait donner: 

                command="/usr/sbin/uucico -D -l" 1024 35  12006592125270333...

Attention, ça doit être sur une seule ligne !

6. On termine...

A partir de votre poste client, lancez la commande ssh uucp@serveur.machin.fr -v et répondez oui à la demande de sauvegarde de la clef RSA du serveur. Vous devrez ensuite avoir le prompt UUCP, si vous ne l'avez pas, quelque chose ne va pas.

En tant qu'utilisateur uucp, lancez /usr/sbin/uucico -f -sserver et vous devriez voir des mails arriver dans vos logs UUCP.

Si ça fonctionne alors vous avez gagné ! Mettez "default_transport = uucp" dans /etc/postfix/main.cf sur la station de travail pour que les mails sortants passent aussi par UUCP, et rajoutez l'appel à uucico dans le cron de l'utilisateur uucp avec: 

       0-50/10 *       *       *       *       /usr/sbin/uucico -f -sserveur

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

fetchmail par tunnel ssh ca marche aussi

Posté par Anonyme () le 08/04/2001 à 12:25. (lien). Évalué à 0.

man fetchmail

Que demande le peuple...

Posté par Yann Kerhervé (page perso, ) le 08/04/2001 à 14:37. (lien). Évalué à 1.

Depuis le temps que j'attends cette configuration :)

je matte ca dés que possible :)

Et si j'ai pas de Debian?

Posté par Anonyme () le 08/04/2001 à 15:40. (lien). Évalué à 0.

Autrement dit, ca donnerait quoi la meme chose pour une distrib Linux quelconque?

IBM Public License et consorts, le truc de la linuxexpo

Posté par Anonyme () le 08/04/2001 à 21:30. (lien). Évalué à 0.

>Je considère que vous avez installé UUCP, postfix et openssh.

Pourquoi oublier de rappeler que postfix est sous la licence IBM Public License ? Donc à banir !!

http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLice(...)

IBM Public License, Version 1.0
This is a free software license but it is incompatible with the GPL.

The IBM Public License is incompatible with the GPL because it has various specific requirements that are not in the GPL.

For example, it requires certain patent licenses be given that the GPL does not require. (We don't think those patent license requirements are
inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.)

Donc ce tutoriel doit être remanier.
Est-ce que Exim peut être une solution ?

philou

Merci

Posté par Arthur Accroc () le 09/04/2001 à 01:18. (lien). Évalué à 1.

Tous mes remerciements pour cet article. Ça faisait un bout de temps que je pensais mettre en place une telle solution, mais jusque là, je n'avais pas eu le temps ou le courage de me pencher d'assez près sur UUCP pour ça...

Il y a juste une ou deux questions que je me pose, au niveau du comportement d'une telle solution dans des cas "hostiles" :
- Que se passe-t-il si la connexion se coupe au milieu du transfert ?
- Si on a 50 Mo de mailbombs dans la boîte, y a-t-il moyen de les supprimer avant de charger le mail ?

--
« L'Homme n'est pas une marchandise comme les autres. » Nicolas S. (esclavagiste ?)

Re: UUCP à travers SSH: la meilleure configuration mail

Posté par Benjamin BAYART (page perso, ) le 29/10/2002 à 18:00. (lien). Évalué à 1.

Juste pour information, il y a (au moins) une association qui fournit
ce type de service pour le mail et pour les news. Pour ceux qui sont
sur Internet depuis longtemps, ca evoquera sans doute des souvenir: FDN.

Ca doit bien faire... heu... 10 ans que FDN fournit UUCP (a l'epoque c'etait
le moyen d'acces "normal" au mail), et ca doit faire un an ou deux que
l'acces UUCP/ssh est en place.

Pour ceux que ca interesse de voir comment ca peut se configurer sur des
exemple reels:
http://www.fdn.fr/supp.conn.html(...)

--
FDN - Fournisseur d'accès Internet depuis 1992.
ADSL depuis septembre 2005.

Alternative + simple

Posté par Moby-Dik () le 30/10/2002 à 11:48. (lien). Évalué à 1.

Pour ceux qui n'ont pas envie de jouer les barbus, y a no-log qui fournit POP crypté, IMAP crypté et SMTP crypté.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1324s (dont 0.0123 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !