OpenSSH



Pourquoi OpenSSH ? :

La réponse est simple; regardez : 






Cette capture de trame a été effectuée lors d'une session telnet aux bornes d'un Hub reliant le serveur et le client. Le Switch, contrairement au Hub, ne diffusant pas les trames Ethernet sur tous les ports, vous protège ,un petit peu, de ce genre d'acte.Donc, plus de telnet, fini. 

OpenSSH permet :

OpenSSH ne permet pas :

Vocabulaire :

Le démon coté serveur

Client Unix

Clients Windows (PuttY, Tera Term Pro, WinSCP)

Etat de la législation.

Différentes méthodes d'authentification.

Comment faire passer ses protocoles applicatifs en texte clair dans un tunnel chiffré.

Quelques développements mathématiques :

Quelques algorithmes :

Quelques dangers liés plus ou moins directement à SSH.

Vocable :
    Le  chiffrement consiste à rendre incompréhensible un message pour toute personne non-détentrice d'une information. Contrairement au chiffrement dans lequel la sécurité repose sur la taille des clés et pas sur l'algorithme (public, sinon méfiance..), le codage fait reposer sa sécurité sur la seule non-divulgation de l'algorithme utilisé.

    Tandis que déchiffrer un message est l'apanage du destinataire légitime qui détient la clé de déchiffrement,décrypter un message est le travail de l'intercepteur, il ne possède pas la clé de déchiffrement et doit casser le code. 
    La cryptographie est la science du chiffrement, alors que la cryptanalyse est la science du décryptage (inventée par les arabes au IXè siècle déja!).

    La taille d'une clé est parfois appelée entropie de la clé ou de taille de l'espace des clefs. L'ensemble clé publique/clé privée constitue un trousseau de clés ou une  paire de clés.

Le démon sshd:

Les fichiers de configuration:

phil@Hendrix:/:$> ls -l /etc/ssh*
-rw-r--r-- 1 root wheel 1144 Mar 19 15:38 /etc/ssh_config                        Fichier de configuration du client SSH
-rw------- 1 root wheel 668 Mar 19 12:46 /etc/ssh_host_dsa_key             Clé privée DSA     ------> Regardez les droits -rw------- root.wheel
-rw-r--r-- 1 root wheel 602 Mar 19 12:46 /etc/ssh_host_dsa_key.pub       Clé publique DSA
-rw------- 1 root wheel 527 Mar 19 12:46 /etc/ssh_host_key                    
-rw-r--r-- 1 root wheel 331 Mar 19 12:46 /etc/ssh_host_key.pub                
-rw------- 1 root wheel 887 Mar 19 12:46 /etc/ssh_host_rsa_key              Clé privée RSA     ------> Regardez les droits -rw------- root.wheel
-rw-r--r-- 1 root wheel 222 Mar 19 12:46 /etc/ssh_host_rsa_key.pub        Clé publique RSA
-rw-r--r-- 1 root wheel 2222 May 16 14:30 /etc/sshd_config                      Fichier de configuration du serveur SSH

Attention, en version 3.0 et antérieures, tout ce petit monde était dans /etc/. (Mais il était, avant, déja dans /etc/ssh, mais là, on remonte à une époque que les moins de 20 ans.....)

Fichier de configuration du démon serveur sshd  : /etc/sshd_config:    
En gras, les modifs à faire, à mon avis. En italique, les commentaires.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Port 22
Port TCP par défaut

#Protocol 2,1
Protocol 2
Par défaut sshd accepte les connections de clients SSH1 et SSH2. Pour plus de sécurité, et si vous n'utilisez pas SSHv1 pour d'impératives raisons de compatibilité, il est fortement conseillé de n'utiliser que la version 2. Elle est plus sécurisée, plus performante, mais est incompatibole avec la version1;

#ListenAddress 0.0.0.0
#ListenAddress ::
Par défaut,reste à l'écoute du reste du monde (IPV4 1ère ligne, IPV6 seconde ligne). Si vous voulez réduire, jouez la dessus, même si je trouve que bloquer par pf est plus élégant et plus rapide.

# HostKey for protocol version 1
HostKey /etc/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh_host_rsa_key
HostKey /etc/ssh_host_dsa_key
Fichier des clefs SSH1
Fichier des clefs SSH2

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
Période de régénération de la clef du serveur (1 heure)

#ServerKeyBits 768
ServerKeyBits 1024
Taille de la clé du serveur (768 bits, par défaut). Cette clef n'est pas écrite sur le disque, elle reste en mémoire durant toute sa période de validité.

# Logging
SyslogFacility AUTH
LogLevel INFO
Enregistre dans les logs, par le mécanisme Syslog selon la facilité d'authentification et au niveau minimum d'information.

#obsoletes QuietMode and FascistLogging
# Authentication:
LoginGraceTime 600
Temps avant déconnexion du client en cas de login infructueux (10 minutes)

#PermitRootLogin yes
PermitRootLogin no
Permet la connexion root directe. A modifier afin d'imposer la connection sous un compte non privilégié avant de passer root avec su.

StrictModes yes
Le mode strict force sshd à vérifier la sécurité du répertoire perso (les droits) avant d'autoriser le login.

RSAAuthentication yes
Authentification RSA possible. [SSH1]. Inutile puisque vous avez désactivé la connexion en SSHv1.

PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
Authentification à clef publique possible. [SSH2]

# rhosts authentication should not be used
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
Interdit l'utilisation du fichier rhosts, méthode non sécurisée.Tant mieux.

# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
Interdit l'utilisation du fichier rhosts, méthode non sécurisée, même avec RSA.Ne pas activer! [SSH1]

# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
Idem en SSH2

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
Authentification par mot de passe en cas d'authentification RSA échouée. A mettre à no dès que le système RSA est opérationnel.(pas avant ça ne marcherait pas par scp.) ....Attention!!.. Ne vous méprenez pas sur la signification du commentaire,  les mots de passe en clair passent quand même dans un tunnel chiffré, vous n'êtes pas revenus à Telnet.Allons, allons, on se calme !

PermitEmptyPasswords no
Interdit la connexion par mot de passe vide en cas d'authentification par mot de passe. On maintient désactivé !! faut pas pousser......

# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no
# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes
S/key et Kerberos sont des systèmes d'authentification robustes et sophistiqués.S/key en OTP (One Time Password, mot de passe à usage unique) , Kerberos est un système d'authentification sur tout un réseau (on parle de royaume).

X11Forwarding no
Autorise l'export du serveur graphique. X11 dont l'éxécrable réputation en matière de sécurité se poursuit.Ne pas activer.

X11DisplayOffset 10
Décalage du display pour ne pas interférer avec les serveurs X11 existants et n'utilisant pas le tunnel SSH.

PrintMotd yes
Le Message Of The Day  vous affiche un joli message de bienvenue.

#PrintLastLog no
KeepAlive yes
Vérifie la présence du client à l'autre bout. Si à yes, vous risquez de casser la connexion au  moindre encombrement réseau .  Si à no, une session cassée restera ouverte indéfiniment, occupant des ressources et des connexions. A vous de voir .

#UseLogin no
Utilise la commande /usr/bin/login au lieu de celle fournie par le démon . Très dangereux, Ne pas activer.

#MaxStartups 10:30:60
On fixe à 10 le nombre maximum de connexion non-authentifiées. Afin de limiter les dénis de service.

#Banner /etc/issue.net
#ReverseMappingCheck yes

Subsystem sftp /usr/libexec/sftp-server
Définit le server FTP sécurisé

 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Génération ,validation d'un trousseau de clés : ssh-keygen

Génération d'un nouveau trousseau :    ssh-keygen     -t     type_de_clé     -b     taille_de_la_clé
Le type est RSA ou DSA.
La taille, en bits, est de 512 minimum, et on considère que 1024 est un bon compromis entre sécurité et performances.
Puis, il vous est demandé l'emplacement et le nom du fichier contenant cette clé. (En fait, )

Attention si pass, mini 5 car....
vous donne le fingerprint (empreinte digitale) de la clé 
fingerprint

diff enter  cle du srv et clé user......que fait -on avec un ssh-keygen????

ssh-keygen -l -f fichier    

fingerprrint

ssh-keygen -p -f fichier    chnager de pass
si il y en vait vous la redemande


Exemples :

Nous utiliserons dans tous les exemples 3 machines :
mosesley    Serveur distant

dagobah    Serveur distant

oth            Machine locale

Client Unix

    Le client SSH est installé par défaut. Son fichier de configuration /etc/ssh/ssh_config, me suffit parfaitement, je ne l'ai jamais touché. Si vraiment vous voulez modifier certains paramètres de la connexion, vous pouvez toujours passer des paramètres sur la ligne de commande.

Connexion distante (Telnet, rlogin sécurisés)
ssh utilisateur@machine     -C                           #  -C Pour la compression du flux, attention, ca mange encore du CPU en plus...
ou alors :
ssh machine                               # si vous vous connectez sur la machine distante avec le même nom que sur la machine locale.
Exemple :     Depuis oth, machine locale : ssh jarjar@mosesley

Execution distante d'une commande (rsh sécurisé)
ssh utilisateur@machine     commande_ou_script
Exemple :     Depuis oth, machine locale : ssh jarjar@mosesley uptime
Devrait renvoyer l'uptime de la machine mosesley.

Copie distante (rcp sécurisé)
scp  -C  -p  source destination                            
 -C Pour la compression du flux, attention, ca mange encore du CPU en plus..
 -p Pour la préservation des attributs de fichiers (droits, proprio, accès)
Avec : source et destination qui contiennent, si nécessaire le chemin réseau

Exemple :    Depuis oth, machine locale :  scp -r jarjar@mosesley:/etc/ssl        yoda@dagobah:/tmp/
Vous copiez, de manière sécurisée et récursive (-r) un répertoire avec tous ses fichiers d'une machine vers une autre.
Exemple 2 :    Depuis oth, machine locale :  scp -C  jarjar@mosesley:/etc/resolv.conf        /etc
Vous copiez, de manière sécurisée et en compressant le flux de données, un fichier d'une machine distante vers la votre..

 Exemple d'appli sur SSH tar (backup réseau sécurisé)
Exemple : Depuis oth, machine locale tar cvf - | ssh utilisateur@machine     "dd of=/dev/tape"

 Exemple d'appli sur SSH rsync (synchro réseau sécurisé)

Message d'avertissement lors de la première connexion :



ssh-agent est un agent d'authentification lors des authentifications par clé publique.
ssh-agent    Charge en mémoire le programme ssh-agent qui enregistrera, au fur et à mesure, par le programme ssh-add les différentes clés privées (avec entrée de la passphrase éventuelle.) pour les fournir directement lors d'une authentification ultérieure sans rien redemander à l'utilisateur. Pratique, mais dangereux

ssh-add est un intermédiaire entre l'utilisateur et le programme ssh-agent résident en mémoire. Il chargera les cléfs RSA,DSA à l'agent d'authentification.
ssh-keygen -l -f     id_dsa.....
b1::::::0f

MARCHE PAS...................................

Client Windows

Putty

WinSCP



Les différents messages d'erreurs ou d'avertissement.

A la première connexion :
Lors de la première connexion à une machine distante, et si vous avez bien compris ce qui se dit ici, vous comprendrez que votre client, ne connaissant pas la clé publique du serveur, vous signalera son incapacité de chiffrer la communication sauf à accepter la clé publique que le serveur vous propose comme étant la sienne (Quelle confiance lui accordez-vous ?).

Client Unix : 

phil@zopen:/home/phil:#> ssh root@Ma_machine
The authenticity of host 'Ma_machine (Mon_IP)' can't be established.
RSA key fingerprint is de:b7:54:93:b7:ba:77:02:1b:9c:42:5b:5a:13:ab:e1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'Ma_machine' (RSA) to the list of known hosts.
root@Ma_machine's password:

Si vous acceptez, cette clé publique est enregistrée dans le fichier ~/.ssh/known_hosts.
Si vous refusez la connexion se termine.

Client Windows : 

--------------------------------IMAGE D'UNE PRIMO CONNEXION PUTTY--------------------------------


Changement de clé publique :

    Lors des connexions ultérieures à cette machine, votre client comparera la clé publique que le serveur lui envoie à celle qu'il connait déja. Si elle coïncide, il continue le processus de connexion, sinon, il vous informe assez brutalement d'une potentielle usurpation d'identité et la suite varie selon les clients.
Un Bon client (ssh) refuse d'aller plus loin, ce qui est un comportement parfaitement sain.
Un Mauvais client (Putty), se contente de vous informer de la modification et vous donne la possibilité de cliquer un peu trop vite sur Accepter la nouvelle clé en lieu et place de l'ancienne.
Du danger d'accepter trop rapidement une nouvelle clé

Client Unix : 

phil@zopen:/home/phil:#> ssh root@Ma_machine
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
7c:79:f6:43:9f:ac:73:87:8e:9d:77:c6:c3:65:e0:45.
Please contact your system administrator.
Add correct host key in /home/phil/.ssh/known_hosts to get rid of this message.
Offending key in /home/phil/.ssh/known_hosts:2
RSA host key for Ma_machine has changed and you have requested strict checking.
Host key verification failed.
phil@zopen:/home/phil:#>          

Vous devez, SI VOUS ÊTES VRAIMENT CERTAIN DE CE QUE VOUS FAITES, supprimer la ligne fautive du fichier ~/.ssh/known_hosts, puis relancer la tentative de connexion et vous retrouver dans le cas d'une première connexion.
Par certain de ce que vous faites, j'entend que vous (ou quelqu'un en qui vous avez confiance et qui vous a prévenu directement) venez soit de changer de serveur, soit de regénérer un nouveau trousseau de clés, et que l'empreinte de la clé (fingerprint) est correcte.

Client Windows : 

root@Open:~/.ssh:#> scp id_dsa.pub phil@Ma_machine:/tmp
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Bad ownership or mode(0604) for '/root/.ssh/id_dsa'.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /root/.ssh/id_dsa
Enter passphrase for key '/root/.ssh/id_dsa':

 

 




Port Forwarding ou comment créér un tunnel chiffré

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
ssh user@IP_SERV -N -L 1234:IP_SERV:3306

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

 

Ai-je le droit d'utiliser OpenSSH en France ?
     La question peut paraitre saugrenue, elle ne l'est pas. Jusqu'en 1998, la législation française sur la cryptographie était extrêmement restrictive, en interdisant tout chiffrement dont l'entropie dépassait 40bits.;-))))
    Depuis 1998 ( Decret du 17  Mars 1999), les choses se sont améliorées et on peut atteindre 128 bits., et nous en sommes aujourd'hui (18/4/2003 sous le soleil) à attendre la loi sur l'économie numérique et ses futurs décrets d'application pour obtenir une libération (désolé, libéralisation est un mot que je goûte assez peu!) plus complète de l'usage du chiffrement.
Rappelons que l'usage du chiffrement a souvent été assimilé à une arme de guerre dont la déclaration passait par les services directs du premier ministre (SCSSI). Ca a été le cas de SSF, version française, légale en France de SSH.
Notons que d'autres pays ont (ou ont eu) des législations concernant la cryptographie, assez sévères : USA, Russie, Irak, Pakistan...bref rien que des démocraties......


Les différents modes d'authentification

Mot de passe (/etc/master.passwd) 
Clé publique
Authentification mutuelle du client et du serveur.
Kerberos
S/Key
Par fichier .rhosts ou .shosts
Ce mode étant plutôt peu ou très peu sécurisé, il ne sera pas traité ici.

Développements mathématiques :

Il existe deux principaux types d'algorithme de chiffrement; les algorithmes symétriques et ceux asymétriques.

Le tableau suivant (repris du HS Pour la science) représente, la résistance prévisible des algorithmes symétriques et asymétriques selon la taille des clés utilisées et en suivant la loi de Moore (Doublement de la vitesse de calcul des CPU tous les 18 mois.). Cette résistance est supposée à une attaque exhaustive (on essaye  toutes les solutions) et ne tient pas compte d'une découverte majeure en cryptologie.

Nombre de bits de la clé symétrique

Cassée en

40 bits (limite francaise de 1998!)

1995

56 bits (DES)

1998

128 bits (limite légale actuelle en France) Minimum souhaitable

~2100 ?

256 bits

Jamais ?

 

Nombre de bits de la clé asymétrique

Cassée en

256 bits 

1985

512 bits 

1999

1024 bits Minimum souhaitable

~2030 ?

2048 bits

~2080 ?


 Comparez la taille de clés pour une attaque réussie : ex : En 98/99 une attaque réussit sur une clé DES de 56 bits mais de 512 bits en RSA : Les algorithmes asymétriques sont dans les choux en terme de vitesse.(cent à mille fois plus lents que les algorithmes symétriques)

Notez bien que la seule donnée de la longueur de la clé pour un algorithme ne détermine pas sa robustesse. Encore faut-il que l'implémentation matérielle/logicielle soit irréprochable (Ni faille, ni Backdoor !!) et que vous n'utilisiez pas "toto" ou consort comme mot ou phrase de passe!! 

Encore une fois, la cryptographie est une science complexe et bien se sont cassés les dents devant plusieurs écueils :
- L'algorithme prétendument révolutionnaire qui n'a pas survécu à une analyse poussée. (Il y en a des légions).
- Le bon algorithme qui repose sur une implémentation déficiente (générateur de pseudo-aléa prévisible, )
- Le super méga produit du marketing dont les sources ne sont pas publiques (security through obscurity !) pour "empêcher le hacker de pirater votre système "! Sans commentaire.

En revanche, on n'est pas à l'abri d'une percée mathématique majeure mettant à terre tous ces beaux jouets algorithmiques...

Quelques algorithmes :

Dangers 

Pb d'accepter clé pub la première fois.
chhiffre -- FW

mitm lors de la phase 1

Comme il est indiqué clairement, "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!", il y a peut-être un vilain qui essaye de se faire passer pour votre

seifried

ssh-agent,.... enregistre en clair dans la mémoire la clé privée. Attention au core-dump qui contiendra la clé en clair dans un fichier core.

charge 

Plus de documentation

 

© Philippe Schwarz - Philippe.chadefaux   - 10/3/2002 - $Id: OpenSSH.htm,v 1.8 2003/10/26 20:56:07 phil Exp $ -