Atelier SSH Telnet Version Final [PDF]

Zitiervorschau

DRCT ISTA NTIC Béni Mellal Atelier ssh-telnet Fedora M18-Administration des réseaux informatiques.

I. Avant de commençer : Réaliser la topologie suivante sous Virtualbox :

II. Les services à la demande : Le service inetd gère certains services réseaux dits à la demande autrement dit ne seront active que s’il y a des clients. Toute information concernant les ports à surveiller et l’application réseau à activer en conséquence est communiqué vie le fichier /etc/inetd.conf. Chaque ligne du fichier de configuration décrit une application et se compose des champs suivants : • Nom du port. inetd lit /etc/services pour déduire le numéro de port équivalent à écouter. • Type de protocole : « stream tcp » si tcp ou « dgram udp » si udp. • « wait » ou « nowait » indique respectivement si il y a un seul serveur pour l’ensemble des clients ou un serveur par client. • L’UID • Le chemin de l’exécutable. • Les arguments de l’application. Exemple de ligne d’application : ftp

stream

tcp

nowait

root

/usr/sbin/wu.ftpd

wu.ftpd –a

Le wrapper tcpd contrôle l’accès à des services en utilisant des ACLS via les services /etc/hosts.allow et /etc/hosts.deny. La ligne de ftp devient : ftp

stream

tcp

nowait

root

/usr/sbin/tcpd

wu.ftpd –a

un extrait de /etc/hosts.allow sera: wu.ftpd : LOCAL, .SOCIETE.COM.

xinetd est le « super-service » qui a remplaçé inetd en apportant de nouvelles possibilités de configuration. Ce programme est configuré via /etc/xinetd.conf, dont voici un exemple : #xinetd.conf defaults {

Page 1 sur 7

instances log_type log_on_success log_on_failure cps

= = = = =

} includedir /etc/xinetd.d

• •

• • • •

60 SYSLOG authpriv HOST PID HOST 25 30

instances — Détermine le nombre maximal de requêtes qu'un service xinetd peut gérer à un moment donné. log_type — Configure xinetd de sorte qu'il utilise la facility de journalisation authpriv qui enregistre des entrées de journalisation dans le fichier /var/log/secure. L'ajout d'un directive telle que FILE /var/log/xinetdlog entraînerait la création d'un fichier de journalisation personnalisé portant le nom xinetdlog dans le répertoire /var/log/. log_on_success — Configure xinetd de façon à ce qu'il effectue la journalisation si la connexion est établie avec succès. Par défaut sont enregistrés aussi bien l'adresse IP de l'hôte distant que l'ID de processus serveur traitant la requête. log_on_failure — Configure xinetd de façon à ce qu'il effectue la journalisation si la connexion échoue ou si elle n'est pas autorisée. cps — Configure xinetd de manière à n'autoriser que 25 connexions par seconde à un service donné. Si cette limite est atteinte, le service est retiré pendant 30 secondes. includedir /etc/xinetd.d/ — Inclut des options stipulées dans les fichiers de configuration spécifiques aux services qui se trouvent dans le répertoire /etc/xinetd.d

Le fichier /etc/xinetd.d ne contient pas directement la description des services, mais précise le répertoire qui les contient. Un exemple de fichier de configuration de service est donné ci-dessous : #telnet service telnet { flags socket_type wait user server log_on_failure disable }

• • • • • • •

= REUSE = stream = no = root = /usr/sbin/in.telnetd += USERID = yes

service — Définit le nom du service, généralement pour correspondre à un service mentionné dans le fichier /etc/services. flags — Définit une variété d'attributs pour la connexion. L'option REUSE donne l'instruction à xinetd de réutiliser le socket pour une connexion Telnet. socket_type — Spécifie le socket comme étant de type stream. wait — Détermine si le service est mono-fil (single-threaded, yes) ou multi-fils (multithreaded, no). user — Détermine l'ID d'utilisateur sous lequel le processus est exécuté. server — Définit le fichier binaire exécutable devant être lancé. log_on_failure — Détermine les paramètres de journalisation de log_on_failure en plus de ceux déjà définis dans xinetd.conf.

• disable — Détermine si le service est actif.

III.

Le service TELNET:

Le service telnet fournit une connexion à distance à un serveur. On obtient un shell distant qui permet l’exécution des commandes sur le serveur. Il utilise le port 23. Sous Linux, le serveur Telnet n’est actif par défaut. Page 2 sur 7

Le service telnet (in.telnetd) est normalement activé par inetd ou xinetd. Avant d’activer le login, il affiche le fichier /etc/issue.net. Le package d’installation de fedora 8 est : telnet-server-0.17-41.fc8.i386.rpm il est disponible sur le dvd de fedora. Application Pratique : Sur le serveur serv01fed : 1. Vérifier est ce que le package telnet est installé. rpm -qa|grep -i telnet ou rpm -q telnet-server On peut aussi effectuer une recherche du package associé à telnet yum search telnet Le package est telnet-server 2. Installer telnet yum -y install telnet-server ou rpm -ivh telnet-server.........;; Si on utilise l'installation via rpm, il faut s'assurer que le "super-serveur" xinted est installé car telnet est un service à la demande. 3. Afficher les informations de telnet rpm -qi telnet-server 4. Vérifier les fichiers de telnet rpm -ql bind les fichiers clés : /etc/xinetd.d/telnet /usr/sbin/in.telnetd 5. Activer telnet dans le fichier /etc/xinetd.d/telnet vi /etc/xinetd.d/telnet puis disabled=no 6. Démarrer le service xinetd service xinetd status netstat ntl|grep 23 si le service xinetd est en marche: service xinetd restart sinon : service xinetd start ps -ef |grep -i xinetd netstat ntl|grep 23 7. Installer le client telnet si le client telnet n'est pas installé, on peut l'installer via: rpm -ivh telnet-0.......rpm 8. Tester telnet localement créer un utilisateur, lui donner le login "tux1" et un mot de passe de votre choix. telnet localhost login : tux1 netstat -ant|grep 23 9. Ajouter un message de démarrage echo "bonjour test telnet" >> /etc/motd à partir de "serv02fed" puis pc1: Page 3 sur 7

telnet 192.168.4.10 10. vérifier telnet cd /var/log cat messages sur pc1: installer le client putty à utiliser pour accéder via telnet à serv01fed.

IV.

Le service SSH:

OpenSSH est un ensemble d'outils développés sous licence OpenBSD. Son nom est la contraction d'OpenBSD Secure SHell. OpenSSH permet d'effectuer des communications sécurisées à travers un réseau, reposant sur le protocole SSH. OpenSSH offre une solution de remplacement sécurisé pour rlogin, telnet, rcp et ftp. OpenSSH est disponible sur un grand nombre de systèmes d'exploitation dont BSD, Linux, AIX, HP-UX, Solaris, Mac OS X. SSH est un protocole de communication sécurisée reposant sur le mode client-serveur. SSH signifie Secure SHell. SSH offre la confidentialité des échanges et l'authentification des correspondants. Il existe 2 versions du protocole, la version 2 étant largement utilisée maintenant. Le protocole SSH utilise par défaut le port 22. Il utilise des clés de chiffrement entre le serveur et le client donc tous le trafic entre le client et le serveur est crypté. L'installation du serveur OpenSSH crée un dossier /etc/ssh et génère un couple de clés RSA :  ssh_host_rsa_key contenant la clé privée du serveur  ssh_host_rsa_key.pub contenant la clé publique du serveur Lorsqu'un client demande une connexion au serveur, ce dernier envoie au client sa clé publique. Le client utilise alors la clé publique reçue pour envoyer au serveur une clé secrète. Le serveur reçoit alors la clé publique et la décrypte avec sa clé privée, prouvant ainsi qu'il est bien le serveur. Pour le prouver au client, le serveur crypte un message type avec la clé publique du client et lui envoie. Si le client arrive à lire le message en le décryptant avec sa clé privé, il a la certitude de communiquer avec le véritable serveur. Le canal de communication sécurisée est alors créé. La configuration du serveur ssh se résume en un fichier : /etc/ssh/sshd_config. La configuration par défaut du serveur est suffisante pour son fonctionnement. Différentes possibilités existent concernant l'authentification pour la connexion au serveur SSH: l’authentification par mot de passe et l'authentification par échange de clés. Voici comment mettre en place ces deux techniques.

Par login/mot de passe : Cette méthode d'authentification est très simple, il suffit d'exécuter la commande de connexion SSH : Lors de la première connexion SSH au serveur avec ce login, il vous est demandé si le fingerprint de la clé publique du serveur est bon. Si le fingerprint de la clé publique du serveur est bien le même que celui affiché à votre écran, vous pouvez accepter de continuer en tapant yes. La clé publique du serveur SSH est alors copiée dans le fichier ~/.ssh/know_hosts, ceci permettant garder en mémoire l'authenticité de la clé publique du serveur pour les prochaines connexions. Ensuite, le mot de passe de l'utilisateur utilisé pour se connecter est demandé.

Par échange de clés : Cette méthode d'authentification repose sur la cryptographie asymétrique, par l'utilisation du couple clé privée/clé publique créé par l'utilisateur client, de la même façon que le fait le serveur. SSH propose de générer le couple de clés publique/privée en utilisant au choix 2 algorithmes : DSA et RSA. L’outil ssh-keygen permet de générer les clés de la manière suivante : ssh-keygen -t rsa A l'exécution de cette commande, le couple de clés est généré. Il est alors demandé le chemin où on veut stocker ces clés et leur nom. La touche "entrée" permet de valider le chemin proposé par défaut. La clé privée prend les droits 600 et la clé publique 644. Suite à cela, il est demandé d'entrer une passphrase qui permettra de protéger la clé privée. Cette passphrase peut contenir tout caractère et "méta-caractère", même des espaces. Elle sera demandée à chaque connexion par échange de clés. Page 4 sur 7

Pour permettre l'authentification par échange de clés, il est nécessaire de donner la clé publique au serveur, selon ee principe de la cryptographie asymétrique. OpenSSH permet de copier la clé publique au serveur en toute sécurité : ssh-copy-id de la manière suivante : ssh-copy-id -i chemin/clé/publique/id_rsa.pub login@serveur_ssh Le fichier known_hosts est alors lu pour voir si la machine est connue. Puis, le mot de passe session de l'utilisateur "login" est demandé et ce sera la dernière fois. Les prochaines connexions avec cet utilisateur se feront donc par échange de clé privée/clé publique et à l'aide de la passphrase entrée lors de la génération des clés de l'utilisateur. Il est possible d'effectuer cette tâche d'une autre façon, avec scp : scp /home/login/.ssh/id_rsa.pub login@serveur_SSH:/home/login/clé_publique ssh login@serveur_SSH cat clé_publique >> /home/login/.ssh/authorized_keys rm clé_publique On peut s’authentifier sans mot de passe en saisissant un passphrase null lors de la génération des clés. Application Pratique : Sur la machine serv01fed : 1. Vérifier l’existence du paquetage « openssh-server». rpm –qa | grep openssh ou rpm -q openssh-server 2. Vérifier que le service sshd est démarré service sshd status chkconfig --list sshd 3. Créer un compte utilisateur nommé user1 useradd user1 passwd user1 4. Editez le fichier /etc/ssh/sshd_config pour configurer votre serveur sur le mode d'authentification par mot de passe : ajuster votre fichier de configuration de façon à contenir les lignes suivantes: Port 22 Protocol 2 ListenAddress votre_ip ServerKeyBits 1024 PermitRootLogin no PubkeyAuthentication no IgnoreRhosts yes PasswordAuthentication yes UsePAM yes Compression yes. 5. Lancer votre serveur ssh /etc/init.d/sshd restart ou service sshd restart Sur la machine serv02fed : 6. se connecter en tant que tux1 si le compte n'existe pas le créer 7.

Lancer une session ssh sur la machine serv01fed en tant que user1 (il faut s'authetifier avec un compte utilisateur crée sur la machine serv01fed) ssh user1@nommachine ou ssh [email protected] Page 5 sur 7

donner le mot de passe lancer ls on est sur le /home/user1 on peut exécuter des commendes d'une manière sécurisé quiter la session ssh 8.

En tant que "tux1" sur la machine serv02fed lancer une commande qui affiche les information sur la machine serv01fed ssh [email protected] uname -a 9.

Copier d'une façon sécurisé le fichier file1 du /home/user1 de la machine serv01fed vers /home/tux1 de la machine serv02fed à l'aide de la commande scp. (crèer le fichier s'il n'existe pas). scp [email protected]:/home/user1/file1 /home/tux1 10.

Faire de même pour un fichier à copier de serv02fed vers serv01fed. On peut accéder au service ftp de façon sécurisé à l'aide de la commande sftp.

NB: chaque opération ssh ou scp ou sftp nécessite l'entrée du mot de passe car le mode utilisé est l'authentification par mot de passe. On va maintenant s'intéresser à l'authentification par clé publique : Sur la machine serv02fed : 1. Se connecter en tant que tux1. 2. Générer les clés de tux1.

ssh-keygen –t rsa Accepter le chemin par défaut des clés privée et publique ~/.ssh/id_rsa. Vous pouvez utiliser un mot de passe pour

protéger la clé privée. la clé publique sera stockée dans ~/.ssh/id_rsa.pub. Ne jamais donner la clé publique aux autre personnes.

3. Changer les droits du dossier .ssh

chmod 755 ~/.ssh 4. Accéder au dossier /home/tux1/.ssh cd /home/tux1/.ssh 5. Autoriser la clé publique de tux1 sur le serveur ssh «serv01fed» en le copiant sur le fichier «authorized_keys» sur le repértoire /home/user1/.ssh ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected] la clé peut aussi être transféré par ftp ou par tout autre moyen. Sur la machine serv01fed : 6. Ajuster votre fichier /etc/ssh/sshd_config de façon à contenir les lignes suivantes:

Port 22 Protocol 2 ListenAddress votre_ip Page 6 sur 7

ServerKeyBits 1024 PermitRootLogin no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys IgnoreRhosts yes 7. redémarrer le service sshd

service sshd restart Sur la machine serv02fed : 8. en tant que tux1, connectez vous sur le srveur SSH "serv01fed", aucun mot de passe ne vous sera demandé. Sur la machine pc (xp): 9. utiliser putty pour se connecter sur le serveur ssh en mode authentification par clé publique. Vous devez utiliser l'utilitaire "puttygen" pour la génération des clés. Vous pouvez utliser l'utilitaire "pscp" pour copier la clé pubique vers le serveur.

Page 7 sur 7