Chapitre 6. Applications réseau

Les services de courriel modernes sont soumis à certaines limitations afin de minimiser l'exposition aux problèmes de pourriel (courriel non désiré et non sollicité).

Cela est dû au fait que :

Certains programmes sur Debian s'attendent à accéder à la commande /usr/sbin/sendmail pour envoyer des courriels comme comportement par défaut ou personnalisé puisque le service de messagerie sur un système UNIX fonctionnait historiquement comme :

Le démon SSH OpenSSH ne prend en charge que le protocole SSH 2.

Veuillez lire « /usr/share/doc/openssh-client/README. Debian.gz », ssh(1), sshd(8), ssh-agent(1), ssh-keygen(1), ssh-add(1) et ssh-agent(1).

	Avertissement
	Il ne faut pas que « /etc/ssh/sshd_not_to_be_run » soit présent si l’on souhaite faire tourner le serveur OpenSSH. N’activez pas l’authentification basée sur rhost (HostbasedAuthentication dans /etc/ssh/sshd_config).

Ce qui suit permettra de démarrer un connexion ssh(1) depuis un client :

Si vous utilisez le même nom d'utilisateur sur l'hôte local et l'hôte distant, vous pouvez éviter de taper « nomutilisateur@ ».

Il est possible d’éviter de se rappeler les mots de passe des systèmes distants en utilisant « PubkeyAuthentication » (protocole SSH-2).

Sur le système distant, définissez les entrées respectives, « PubkeyAuthentication yes », dans « /etc/ssh/sshd_config ».

Générez ensuite localement les clés d’identification et installez la clé publique sur le système distant en faisant ce qui suit :

$ ssh-keygen -t rsa
$ cat .ssh/id_rsa.pub | ssh user1@remote "cat - >>.ssh/authorized_keys"

Vous pouvez ajouter des options aux entrées dans « ~/.ssh/authorized_keys » pour limiter les hôtes et pour exécuter des commandes spécifiques. Consulter sshd(8) « AUTHORIZED_KEYS FILE FORMAT ».

Il est plus sûr de protéger les clés secrètes de votre authentification SSH avec une phrase de passe. Si la phrase de passe n’a pas été définie, utilisez « ssh-keygen -p » pour le faire.

Placez votre clé publique SSH (par exemple « ~/.ssh/id_rsa.pub ») dans « ~/.ssh/authorized_keys » sur la machine distante en utilisant une connexion basée sur un mot de passe comme décrit ci-dessus.

$ ssh-agent bash
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/username/.ssh/id_rsa:
Identity added: /home/username/.ssh/id_rsa (/home/username/.ssh/id_rsa)

Il n’y a plus besoin de mot de passe distant, à partir de maintenant, pour la commande suivante :

$ scp foo username@remote.host:foo

Pressez ^D pour quitter la session de l’agent ssh.

Pour le serveur X, le script de démarrage normal de Debian exécute ssh-agent comme processus-père. Vous n’aurez donc à exécuter ssh-add qu’une seule fois. Pour davantage d’informations, veuillez lire ssh-agent(1) et ssh-add(1).

Si vous avez un compte d’interpréteur SSH sur un serveur avec des paramètres DNS appropriés, vous pouvez envoyer un courriel généré sur votre poste de travail sous la forme d’un courriel véritablement envoyé à partir du serveur distant.

$ ssh username@example.org /usr/sbin/sendmail -bm -ti -f "username@example.org" < mail_data.txt

Pour mettre en place un tube pour se connecter au port 25 du serveur-distant depuis le port 4025 de localhost, et au port 110 du serveur-distant depuis le port 4110 de localhost au travers de ssh, exécutez ce qui suit sur la machine locale :

# ssh -q -L 4025:remote-server:25 4110:remote-server:110 username@remote-server

C’est une manière sécurisée d’effectuer une connexion à des serveurs SMTP / POP3 par Internet. Définissez l’entrée « AllowTcpForwarding » à « yes » dans « /etc/ssh/sshd_config » sur la machine distante.

Si vous rencontrez des problèmes, vérifiez les permissions des fichiers de configuration et lancez ssh avec l’option « -v ».

Utilisez l’option « -p » si vous êtes administrateur et que vous rencontrez des problèmes avec un pare-feu. Cela évite l’utilisation des ports 1 — 1023 du serveur.

Si les connexions ssh vers un site distant s’arrêtent subitement de fonctionner, cela peut être suite à des bidouilles de l’administrateur, le plus probablement un changement de « host_key » pendant une maintenance du système. Après s’être assuré que c’est bien le cas et que personne n’essaie de se faire passer pour la machine distante par une habile bidouille, on peut se reconnecter en supprimant sur la machine locale l’entrée « host_key » de « ~/.ssh/known_hosts ».