SSF

Principe :

On peut, entre autres, qualifier SSF/SSH de super-telnet-crypté mais il sait faire plein d'autres choses. Vous voulez , par exemple, faire du Telnet, du FTP ou tout autre application s'exécutant sur une couche TCP/IP, mais le fait que les données sensibles ,comme les mots de passe, circulent en clair sur le canal vous inquiète.(Non, ce n'est pas de la paranoïa galopante, mais des nuits plus tranquilles. C'est tout.) : Utilisez SSF !

Le beurre : SSF/SSH permet de se connecter sur un système distant en cryptant toutes les données dont, entre autres, le mot de passe.

L'argent du beurre : SSF/SSH intègre en sus, deux mécanismes facultatifs améliorant soit la sécurité soit la facilité de l'ensemble :

• Facilité accrue : Une authentification de l'hôte basée sur un fichier shosts du même type que celle de tcp_wrappers. Ce mécanisme n'est PAS DU TOUT sécurisé et donc fortement DECONSEILLEE. (Il ne sera pas traité ici.)
• Sécurité accrue :Un cryptage asymétrique de type RSA à clef publique / clé privée. Attention, on ne confond pas! Les échanges de clés se font dans tous les cas avec un mécanisme RSA, ici c'est l'authentification qui suit un mécanisme RSA. (Documentation RSA
)

En résumé, SSF possède deux mécanismes différents d'authentification :

• Une authentification simple : Un couple Nom de compte / Mot de passe.
• Une authentification forte : Le client génère un couple clé privée / clé publique. La clé publique est envoyée une première (et unique ) fois au serveur.  Puis, lors de la connexion, le serveur (à partir de la clé publique du client) génère un challenge que le client résoudra à partir de sa clé privée. Notez que la clé privée DOIT rester secrète. De plus, elle est protégée par une passphrase. Une passphrase est un mot de passe de très grande longueur qui crypte la clé secrète.
• De plus, à l'instar du mécanisme  tcp_wrappers, SSF permet de n'autoriser les connexions que depuis certaines machines ou certains domaines.

Le sourire de la crémière : SSF/SSH permet de faire passer toutes les données dans un tunnel crypté. Ainsi, une fois le tunnel chiffré entre le client et le serveur établi, on fait passer les applications  sensibles dedans.Vous n'avez qu'à utiliser vos outils de manière quasi-habituelle avec un avantage supplémentaire : vous ouvrez sur le serveur le port sensible et vous le bloquez sur le Firewall, il sera donc inutilisable sauf à passer par le tunnel. A ma connaissance, c'est un des principes du VPN (réseau privé virtuel).

Rappels sur la réglementation et conditions d'utilisation de SSF :

SSF est la version compatible avec la législation française de la version libre du protocole SSH (Secure Shell). De plus, SSF est compatible avec toutes les versions 1.5 de SSH. On parlera donc de SSF/SSH.

Site du concepteur :ccweb.in2p3.fr/

• SSF a fait l'objet d'une déclaration auprès du SCSSI.
• SSF travaille sur un espace de clefs d'une taille de 128 bits.

Donc, SSF respecte la loi française sur la cryptologie ( Decret du 17  Mars 1999).

Serveur Linux :

Installation

Téléchargez la dernière version (1.2.27.6-2)de ssf sur le site de l'in2p3. Soit au format rpm (Redhat & Mandrake), soit les sources au format .tgz.

Décompactez le rpm (rpm -ivh ssf.....rpm) ou installez les sources (tar zxvf ssf.....tgz ; ./configure; make ; make install ; make clean)

Lancez le démon ssfd. (/usr/local/sbin/ssfd). Pour l'instant la configuration du serveur est correcte, mais moyennement sécurisée.

Le serveur Linux fait tourner les démons suivants :

• ssfd sur le port 22

Et tous les démons selon l'usage:

• FTP : wu-ftp (in.ftpd)       port 21
• HTTP : Apache                port 80
• POP/SMTP : Sendmail    port 25/110

Utilisation

 Informations et aide : man ssh (et non pas man ssf- Unix)

• FTP

Le démon ftpd qui tourne par défaut sur les RedHat/Mandrake est wu-ftp (Washington University). in-ftpd n'est qu'un lien vers wu-ftpd.

Par défaut, le démon wu-ftpd n'accepte pas la redirection de port distant, il faut donc le recompiler avec les bonnes options (Si vous voulez le faire, je vous envoie la marche à suivre) ou alors utiliser celui que j'ai déjà recompilé (wu-ftpd-2.6.0-6mdk.src.rpm).

• Copiez le wu-ftpd ainsi obtenu dans /sbin/in.ftpd (Confirmez l'écrasement éventuel!)( Must be root !!)
• Vérifiez que la ligne de /etc/inetd.conf lançant le démon in.ftpd (lien vers wu-ftpd) est décommentée, puis relançez le démon (killall –HUP inetd (Must be root !!))

• HTTP

Client Linux :

Installation

Téléchargez la dernière version (1.2.27.6-2)de ssf sur le site de l'in2p3. Soit au format rpm (Redhat & Mandrake), soit les sources au format .tgz.

Décompactez le rpm (rpm -ivh ssf.....rpm) ou installez les sources (tar zxvf ssf.....tgz ; ./configure; make ; make install ; make clean)

Authentification simple :

Vous en avez fini pour l'instant. Passez à la partie blindage.

Authentification forte :

Connectez vous en tant qu'utilisateur non privilégié (PAS ROOT !).

Générez votre trousseau de clé (Publique & Privée) : /usr/local/bin/ssh-keygen ( Attention, il est possible que vous n'ayez pas la possibilité de naviguer dans l'arborescence.)

ssh-keygen vous propose alors de sauvegarder (dans votre arborescence personnelle) le trousseau de clé sous le nom par défaut : identity. Si vous devez gérer de multiples identités et/ou machines, il peut être préférable de le renommer sous un nom plus explicite.

Puis vous devez taper une passphrase (choisissez une grande longueur ainsi qu'une grande complexité, la sécurité de votre système dépend en très grande partie de la complexité de cette phrase.)

Vous obtenez donc deux fichiers identity (clé privée, NE LA DIFFUSEZ JAMAIS !! , personne n'en aura besoin sauf vous!) et identity.pub, (clé publique à diffuser!)

Vous devez maintenant diffuser votre clé publique au serveur par un moyen sûr, si quelqu'un produisait maintenant sa clé publique en lieu et place de la votre, il serait dans la place!!!

• Copie par disquette (de client:/home/vous/.ssh/identity.pub à serveur:/home/vous/.ssh/authorized_keys) Ce dernier nom est obligatoire !
• Copie par scp (Secure Copy). Depuis votre répertoire perso/.ssh :

scp identity.pub vous@serveur:~/.ssh/authorized_keys     (Notez le point . devant ssh :    .ssh)

Attention, vous n'avez pas toujours les droits de créer ce fichier à distance. Si c'est la cas, copiez le plus haut, puis en root copiez le au bon endroit.

Vérifiez la connexion : /usr/local/bin/ssf vous@serveur    Vous serez connecté par la passphrase et non par le le mot de passe. Ca y est. Blindons un peu, et ça sera tout.

La clé privée est transportable d'une machine à une autre.  (N'oubliez pas la sauvegarde:  Plus de clé, plus de connexion !!!) Elle reste protégée par la passphrase.

Blindage :

Modifions le fichier /etc/sshd_config sur le serveur pour sécuriser le tout : 

Utilisation

Authentification simple  & Authentification forte

Connexion : ssf compte@machine_distante   comme pour une adresse email.

Quelques options très utiles:

Voici les plus courantes, mais pour plus de détails, consultez les man pages de ssh : man ssh (et non pas man ssf- Unix)

-C : compression du canal (pour les réseaux à faible débit)
-n : redirection stdin /dev/null (pour les applications qui tournent en background)
-v : mode verbeux (pratique pour déceler les problèmes de sconnexion)
-f : mode background

On peut configurer chaque couple utilisateur/machine distante en créant dans le répertoire perso de la machine cliente de l'utilisateur un fichier config  . Par défaut, ce fichier n'existe pas, il faut donc le créer dans le répertoire .ssh (/home/user/.ssh). On peut y ajouter autant de machines cibles que l'on souhaite. Toutes les options que l'on peut faire figurer dans ce fichier sont décrites dans les man page de SSH.

SSF permet de faire du copier-coller écran distant / appli locale

Quelques paramètres :

Host machine-cible
User login
Compression yes/no

Exemples :

machine locale : locale, login : userlocal
machine distante : distante, login : userdistant

Fichier config dans le répertoire /home/userlocal/.ssh sur machine locale :

Host distante
User userdistant
Compression yes

Maintenant la demande de connexion par ssf se fait très simplement :

ssf distante 
au lieu de :
ssf -C userdistant@distante

Copie distante

scp est un outil sécurisé de transfert de fichier .C'est une alternative à FTP .

scp fichier user@machine-cible:Directory_cible

ou

 scp -r Directory_local user@machine-cible:Directory_cible

Exemple :

machine locale : locale, login : userlocal
machine distante : distante, login : userdistant

Copie de tous les fichiers du répertoire courant vers le répertoire sauve de la machine distante.

scp * distante:sauve

Maintenant une copie du répertoire Doc_Sauve qui est sur distante vers locale :

scp -r distante:Doc_Sauve .        (Notez le point . )

Tunnel applications

Création du tunnel :

ssf -n -f machine_cible -L   Nouveau_Port_Local:machine_cible:Port_Natif_Distant   sleep TTL

TTL : Durée de vie du tunnel en secondes
On redirige le port TCP Port_Natif_Distant vers le port TCP Nouveau_Port_Local

L'application distante est donc utilisable comme si elle tournait en local :

On remplace le nom du serveur par sa propre machine (localhost ou 127.0.0.1). et le port du serveur par le port local redirigé; Attention, on ne peut faire q'une seule redirection par port.

Exemple :

Au lieu de : 

mysql -h serveur -D base -u utilisateur -p  - e "select * from ma_table" -P 3306

On a :

ssf -n -f serveur  -L 1234:serveur:3306 sleep 600

mysql -h localhost -D base -u utilisateur -p  - e "select * from ma_table" -P 1234

Client Windows :

Installation

• Attention, la mise à disposition publique pour téléchargement à partir d'un site mirroir est expressément interdite par le concepteur de ssf (perrot@lal.in2p3.fr). Par conséquent, et pour l'instant, pas de FTP public, enfin à mon avis!
• Décompactez ssf.zip dans un repertoire temporaire.
• Lancez install.bat

Les deux outils Teratermpro + ssf sont maintenant installés dans c:\program files\ttermpro

• Décompactez lftp13.zip dans un répertoire temporaire, puis lancez l'installation.

Utilisation

SSF

Il fait tourner les programmes suivants

• TeraTermPro avec sa surcouche ssf
• Un client FTP connaissant le mode passif, ex : Leech FTP (En plus certains messages sont toujours en allemand !C'est plus rigolo.)

Tunnel applications

• Lancez ssf (C:\Program Files\TTERMPRO\ttssf.exe) puis abandon.
• Menu /Setup/SSF forwarding /Ajouter :

• Rediriger le port Local : (N'importe lequel non-privilégié ex :1234) vers la machine distante. port 21 puis OK, vous avez donc dans la liste une nouvelle redirection de port (Attention, vous ne pouvez rediriger simultanément qu'un seul et même port local). Vous avez donc, par exemple : "../ssf/ssf%20forwarding%202"local 1234 to « gauguin.ac-creteil.fr » port 21
• Menu File/New connection/Hôte (Gauguin) en SSF port 22.
• Puis la classique séance login/password se déroule , mais le tout est crypté. (NB ceci est la sécurité minimale)
• C'est bon vous y êtes !

Attention quelques limitations : Je n'ai pas encore vu où ça pouvait se faire, mais vous ne récupérez actuellement pas la variable PATH, donc toutes les commandes doivent être données par leur syntaxe complète. Dans le même ordre d'idée, ne créez pas d'utilisateur ainsi, il aura quelques difficultés avec son répertoire perso (entre autres).

Client Windows :

Le FTP, maintenant :

• Lancez LeechFTP/File/Options/Firewall : PASV Mode/Accept (Indique au logiciel de n'utiliser qu'un seul canal pour les données et pour les commandes, c'est le mode passif, car on ne peut rediriger qu'un seul port par le tunnel.)
• Connect : Host : gauguin Port : Le port redirigé !!! (ici 1234)
• User Name / Password : comme d'hab
• Onglet Queue : Décochez la bulle ZZ pour avoir queue "processing is enabled", les downloads et uploads se fera immédiatement.

Après un rapide moulinage, la bestiole doit vous annoncer qu'elle est prête à subir vos affronts.

Statut :

Cette documentation est inspirée du travail de bernard perrot. à l'in2p3.

21 Mai 2001 Philippe Schwarz