Dernière modification 18 janvier 2017
Avant d'aller plus loin, je vous invite à consulter ma
page sur la cryptographie en guise d'introduction
Cette page est en téléchargement au format pdf dans la section download.
SSH1
Il y a quatre manières de s'authentifier.
Si l'utilisateur olivier possède un fichier ~/.shosts ou~/.rhosts contenant:
asterix veronique
veronique pourra se connecter sur le compte d'olivier avec
ssh (en donnant néanmoins le mot de passe d'olivier).
Ces deux formes d'authentification ne sont absolument pas
sécurisées, Le problème avec cette méthode est que n'importe quelle
machine peut se faire passer pour asterix (spoofing).
La deuxième méthode est l'authentification toujours sur les fameux fichiers rhosts et hosts.equiv mais combinée avec une authentification en utilisant les clés RSA des machines. C'est à dire qu'on vérifie d'abord /etc/hosts.equiv,/etc/shosts.equiv,~/.rhosts et ~/.shosts puis ensuite on vérifie si la clé publique de la machine qui cherche à se connecter se trouve dans le fichier /etc/ssh_known_hosts ou ~/.ssh/known_hosts. Cette méthode est plus sécurisée car elle évite qu'une machine se fasse passer pour une autre, car à la connexion il va y avoir vérification de la clé publique par rapport à la clé privée de la machine cliente.
La troisième méthode est basée sur l'échange des clés utilisateurs en utilisant le protocole de gestion des clés RSA,veronique donne sa clé publique à olivier , quand elle essaye de se connecter sur le compte d'olivier, SSH vérifie que la clé publique que détient olivier correspond bien à la clé privée de véronique. Plus précisément du côté d'olivier le serveur SSH crypte un nombre aléatoire (un "challenge" dans la doc en anglais) en utilisant la clé publique de véronique détenue par olivier, seule la clé privée de veronique pourra décrypter ce "challenge", celui-ci est envoyé au client SSH qui va le décrypter avec la clé privée de véronique ce qui va authentifier cette dernière complètement.
Et la dernière méthode consiste à donner le mot de passe du compte sur lequel on se connecte, le mot de passe circule crypté sur le réseau.
Voyons le fonctionnement en détail de l'établissement d'une connexion:
Chaque machine possède un couple de clé (publique et privée par défaut de 1024 bits) de type RSA, quand le daemon se lance il génére une clé serveur (server key) de type RSA (par défaut 768bits). Cette clé serveur est normalement détruite et reconstruite à intervalle régulier (toutes les heures par défaut) et n'est jamais stockée sur le disque.
SSH2
Avec SSH2 on utilise aussi
l'authentification par clé privée-publique au niveau utilisateur, mais
cette fois-ci en utilisant l'algorithme de gestion des clés ECDSA
ou ED25519 plutôt que RSA ou
DSA.
Avec ces protocoles on a en plus des moyens supplémentaires pour assurer
la confidentialité des données, on peut chiffrer les données qui
transitent en utilisant, entre autres, le tripleDES, Blowfish,
AES ou Arcfour et l'intégrité avec des algorithmes de
hachage comme SHA1 ou MD5 ce que ne possède pas la version
1 de SSH.
Fonctionnement en détail:
C'est similaire à SSH1, chaque machine possède un couple de clé (publique et privée) de type DSA. Quand le serveur se lance, aucune clé serveur n'est générée, on utilise une gestion de clé de type Diffie-Hellman. Cette gestion débouche sur la création d'une clé de session spécifique à la session de connexion qui servira à chiffrer les données qui vont transiter.
En pratique
Si vous n'avez toujours pas compris, voici les différentes étapes pour établir une connexion via SSH entre les utilisateurs veronique sous asterix et olivier sous obelix.
veronique génère ses clés publique et privée sur asterix
olivier génère ses clés publique et privée sur obelix
veronique donne sa clé publique à olivier
veronique veut se connecter sous le compte d'olivier sous obelix
en lançant un client SSH sous asterix
Le daemon SSH sous obelix et le client SSH sous
asterix rentrent en communication pour savoir si la clé publique de
veronique que possède olivier correspond bien à la clé
privée de veronique
veronique doit rentrer la phrase password (passphrase) rattaché à
sa clé publique pour s'identifier auprès du client SSH tournant
sur asterix
veronique doit maintenant rentrer le mot de passe d'olivier (éventuellement)
Ca y est veronique est connectée sous le compte d'olivier après être passée par quatre phases d'identification.
Dans cette page on présentera OpenSSH pour un fonctionnement uniquement en utilisant SSH2, on passera sous silence tout ce qui concerne SSH1, notamment pour l'authentification en utilisant les fichiers .rhosts, .shosts, hosts.equiv et shosts.equiv.
rpm -qa | grep -i openssl
Vous pouvez éventuellement supprimer les packages obtenus pour installer la version tarball généralement plus récente, avec la commande (rpm -e nom-du-package).
S'il y a une tonne de dépendances, ce n'est pas grave vous n'êtes pas obligé de supprimer le package, ça marchera très bien en faisant cohabiter la version mdk et la version tarball. Par contre pour pouvoir utilisé la dernière version d'OpenSSH vous devez utiliser aussi la dernière version d'OpenSSL qu'on peut récupérer à l 'URL www.openssl.org sous la forme d'une archive tarball openssl-1.1.0c.tar.gz, qu'on va décompresser en tapant:
tar xvfz openssl-1.1.0c.tar.gz
Attention la dernière version ne compile pas avec un certain d'autres outils, il est encore préférable d'utiliser une ancienne version (comme la 1.0.2d). Cela va nous créer un répertoire openssl-1.1.0c dans lequel vous taperez
./config
A noter que pour une version 1.0.2d, sur une configuration 64 bits,
on modifiera le fichier Makefile
au niveau du paramètre CFLAG en
rajoutant un -fPIC comme ceci
Ce n'est pas nécessaire pour une version 1.1.0c. Puis on tape
make
Il est nécessaire avant d'aller plus loin de tester la biblio, pour cela préalablement si vous ne l'avez pas vous devez installer la commande bc (calculatrice en ligne), contenue dans une mandrake dans le package bc.
Tapons à présent:
make test
Vous ne devriez pas avoir d'erreur. Et enfin, en tant que root
make install
Cela va installer les fichiers (librairies, binaires, man, doc, ...) de SSL
dans le répertoire /usr/local/ssl. On rajoutera maintenant dans le
fichier /etc/ld.so.conf la ligne
suivante
rpm -qa | grep -i openssh
Vous supprimez avec la commande rpm -e
nomdupackage.
Vous pouvez récuperer la dernière version de OpenSSH sur le site www.openssh.com. C'est une archive tarball openssh-7.4p1.tar.gz . La décompression de l'archive se fait dans un répertoire de travail en tapant:
tar xvfz openssh-7.4p1.tar.gz
Cela va créer le répertoire openssh-7.4p1. Vous devez maintenant installer le package lib64x11-devel pour pouvoir exporter X, ainsi que les packages policycoreutils et zlib1-devel. Maintenant dans le répertoire d'OpenSSH, vous devez maintenant taper:
./configure --with-ssl-dir=/usr/local/linux/securite/openssl-1.0.2d
Vous devez indiquer le chemin des sources openssl
conforme à votre système. Attention la version 7.4p1 ne compile pas avec
la version 1.1.0c d'OpenSSL d'où
l'emploi de la version 1.0.2d. Dans le cas où vous utilisez le package openssl
de la Mageia il faudra installer le package openssl-devel et tapez
simplement ./configure
On obtient en fin de commande un récapitulatif des options de compilation
make
On doit maintenant créer un utilisateur sshd, on tapera les commandes suivantes en tant que root
mkdir /var/empty
chown root:sys /var/empty
chmod 755 /var/empty
groupadd sshd
useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd
/var/empty ne doit contenir aucun fichier. Ceci permet de réaliser certaines opérations sans être root.
make install
A la fin des commandes les clés de votre machine sont générées dans le
cas où celles ci n'existent pas sous /usr/local/etc
Generating public/private rsa1 key pair.
Saving key "/usr/local/etc/ssh_host_key" failed: unknown or unsupported
key type
Generating public/private dsa key pair.
Your identification has been saved in /usr/local/etc/ssh_host_dsa_key.
Your public key has been saved in /usr/local/etc/ssh_host_dsa_key.pub.
The key fingerprint is:
SHA256:+4AlELhvZA4mBUvrU/+WO4WV1BlFNAvnkUbAg3eQw0Q root@obelix.kervao.fr
The key's randomart image is:
+---[DSA 1024]----+
|.o .. BE@O. |
|..+ . o X+++ |
|.o o. . o =o |
|o = +. o |
| = * .. S |
| . + .=.o |
| . .++ |
| ...o
|
| .. .
|
+----[SHA256]-----+
Generating public/private rsa key pair.
Your identification has been saved in /usr/local/etc/ssh_host_rsa_key.
Your public key has been saved in /usr/local/etc/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:qGBnrwQXbfQK8/o092bCiQGU8ygc7NI65AzFYWxwelQ root@obelix.kervao.fr
The key's randomart image is:
+---[RSA 2048]----+
|.==oE.. |
| =B +o . |
|.*.o++o . |
|oo= o*.o |
|=o+.+.+ S |
|o+ * +. |
| . + ++.. |
| . +.o+.o |
| . . +. |
+----[SHA256]-----+
Generating public/private ed25519 key pair.
Your identification has been saved in
/usr/local/etc/ssh_host_ed25519_key.
Your public key has been saved in
/usr/local/etc/ssh_host_ed25519_key.pub.
The key fingerprint is:
SHA256:hzpRRV+XrggYbmwdw2lbmG1HTVuss4cSRLgAJ1fAazk root@obelix.kervao.fr
The key's randomart image is:
+--[ED25519 256]--+
| oo=+Ooo.+o+|
| =oX.=.o ++|
| o *+*oo .o |
| BE=. . o. |
| +.S.o ...+ |
| o . ...o .|
| o . . |
|
. |
|
|
+----[SHA256]-----+
Generating public/private ecdsa key pair.
Your identification has been saved in /usr/local/etc/ssh_host_ecdsa_key.
Your public key has been saved in /usr/local/etc/ssh_host_ecdsa_key.pub.
The key fingerprint is:
SHA256:2S/VH7hJz7YEgYwH/ZfkTYPxsWZiXHH4mvIAxcIEX2I root@obelix.kervao.fr
The key's randomart image is:
+---[ECDSA 256]---+
| .=E...o=o|
| o*+=.+o=|
| ..*.=oB+|
| oo .o*+o|
| S ...+o+ |
| o+ O..|
| . .* =.|
| . +
.|
|
. |
+----[SHA256]-----+
/usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config
Cela va créer les clés publiques et privées de la machine qui seront
placées par défaut dans /usr/local/etc . Plus précisément 4 types
de clés différentes sont créées on trouve la clé privée ssh_host_rsa_key
si on utilise la gestion de clés type RSA (SSH1) et la
publique associée ssh_host_rsa_key.pub et de même les paires
de clé DSA, ECDSA
et ed25519 pour le SSH2.
NOTES - En cas d'upgrade les clés de la machine ne seront pas
écrasées de même que les fichiers de conf.
-
Dans le cas où les clés de la machine sont réinitialisées, pensez à
supprimer les fichiers ~/.ssh/known_hosts
qui contiennent les identifiants des anciennes versions, sous peine
d'obtenir le warning suivant
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 DSA host
key has just been changed.
The fingerprint for the DSA key sent by
the remote host is
0e:6f:19:83:12:96:a6:d1:4d:2b:d6:40:93:39:05:98.
Please contact your system
administrator.
Add correct host key in
/home/olivier/.ssh/known_hosts to get rid of this message.
Offending key in
/home/olivier/.ssh/known_hosts:1
Password authentication is disabled to
avoid man-in-the-middle attacks.
Keyboard-interactive authentication is
disabled to avoid man-in-the-middle attacks.
X11 forwarding is disabled to avoid
man-in-the-middle attacks.
L'installation va installer les binaires utilisateurs sous /usr/local/bin, le daemon sous /usr/local/sbin et le serveur ftp sécurisé sous /usr/local/libexec
Les fichiers de config sont sous /usr/local/etc (ssh_config pour le client sshd_config pour le serveur). Si ces chemins ne vous plaisent pas, lancer configure avec les arguments qui vont bien donnés par:
configure --help
A présent si vous utilisez PAM vous devez prendre le fichier sshd.pam se trouvant sous ./openssh-7.4p1/contrib/redhat et le placer sous /etc/pam.d en le renommant sshd tout court. En vous plaçant donc dans le répertoire de travail d'OpenSSH:
cp ./contrib/redhat/sshd.pam /etc/pam.d/sshd
NOTE Comment savoir si vous utilisez PAM,
tapez journalctl -f
si vous voyez des mentions à PAM (PAM_pwdb par exemple
quand vous vous loguez ou faites un su), c'est qu'il est actif sur
votre système.
Pour la variable Host vous pouvez spécifier des paramètres différents suivant le serveur, exemple avec le serveur tetepa (utilise SSH2) et atopa (utilise SSH1).
Host tetepa
port 22
Protocol 2
Pubkeyauthentication yes
PasswordAuthentication yes
Host atopa
port 22
Protocol 1
RSAAuthentication yes
PasswordAuthentication yes
ssh-keygen -t ecdsa
voilà le résultat
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/olivier/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/olivier/.ssh/id_ecdsa.
Your public key has been saved in /home/olivier/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:diY6BD8vKyM2C3LCODNcwd7YK0fcTI9EfTglM6YBLSM
olivier@asterix.kervao.fr
The key's randomart image is:
+---[ECDSA 256]---+
| .oo.=o. |
| .E o..+++. |
| oo o+ o |
| . *o= o |
| + =++S.o |
|+ . ...= + |
|Oo.. o+ . |
|.B+ = + |
| ..+ o. |
+----[SHA256]-----+
Les clés sera sauvegardée par défaut dans ~/.ssh , la clé privée a pour nom id_ecdsa et la clé publique id_ecdsa.pub
Il est nécessaire de rentrer un mot de passe (passphrase), à noter que ce mot de passe peut être une phrase avec des blancs.
Maintenant veronique doit faire de même sous asterix , elle doit ensuite par un moyen ou un autre faire parvenir sa clé publique (id_ecdsa.pub) à olivier, ce dernier va mettre le contenu de ce fichier dans le fichier (éventuellement à créer) ~/.ssh/authorized_keys.
ATTENTION il est primordial que la clé publique de veronique tienne sur UNE seule ligne dans le fichier authorized_keys, il ne doit pas y avoir de retour chariot. Le fichier doit également avoir les droits 600 !!
NOTE Si olivier autorise plusieurs personnes à se connecter sur son compte par ssh, la syntaxe de authorized_keys deviendra:
# utilisateur veronique
contenu de id_ecdsa.pub de veronique sur une seule ligne
# utilisateur lambda
contenu de id_ecdsa.pub de lamba sur une seule ligne
# ainsi de suite
# est le début de commentaires, et les lignes vides ne sont pas prises en compte.
NOTE Pour changer de pass-phrase au niveau de ssh-keygen , il suffit de taper:
ssh-keygen -p
[veronique@asterix .ssh]$ ssh -l olivier obelix
The authenticity of host 'obelix (192.168.13.11)' can't be established.
DSA key fingerprint is bb:aa:0a:92:66:a8:6c:08:ab:6b:35:18:4d:ab:19:13.
Are you sure you want to continue connecting (yes/no)?yes
Warning: Permanently added 'obelix,192.168.13.11' (DSA) to the list of
known hosts.
Enter passphrase for key '/home/veronique/.ssh/id_dsa':
Last login: Sat Jun 22 14:11:43 2002
[olivier@obelix olivier]$
à noter que veronique doit saisir le mot de passe rattaché à sa clé. C'est bon on est connecté, à noter:
Warning: Permanently added 'obelix,192.168.13.11' (DSA) to the list of known hosts.
La machine obelix va être rajoutée à la liste des machines connues, y aura plus ce message par la suite, si vous voulez que la machine obelix ne soit pas rajoutée de manière permanente mettez le paramètre StrictHostKeyChecking à yes dans ssh_config mais dans ce cas il faudra récupérer la clé publique d'obelix pour la mettre manuellement dans le fichier ~/.ssh/known_hosts
A noter aussi que la prochaine fois que vous essayerez de vous connecter sur obelix, il ne sera plus nécessaire de rajouter -l olivier , ça sera ajouté automatiquement par défaut. Pour terminer on rajoute l'option -p 4321 pour indiquer un port différent.
en version debug cela donne quelque chose comme cela
info sur le client
OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul
2015
debug1: Reading configuration data /usr/local/etc/ssh_config
le serveur
debug1: Connecting to obelix
[192.168.13.11] port 4321.
debug1: Connection established.
vérification des clés
debug1: identity file
/home/olivier/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/olivier/.ssh/id_rsa-cert type -1
debug1: identity file /home/olivier/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/olivier/.ssh/id_dsa-cert type -1
debug1: identity file /home/olivier/.ssh/id_ecdsa type 3
debug1: key_load_public: No such file or directory
debug1: identity file /home/olivier/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/olivier/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/olivier/.ssh/id_ed25519-cert type -1
mise en place du protocole d'échange entre le client asterix et serveur obelix
debug1: Enabling compatibility mode for
protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to obelix:4321 as 'olivier'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305@openssh.com
<implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com
<implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
le serveur obelix est déjà connu
debug1: Server host key:
ecdsa-sha2-nistp256 SHA256:2S/VH7hJz7YEgYwH/ZfkTYPxsWZiXHH4mvIAxcIEX2I
debug1: checking without port identifier
debug1: Host 'obelix' is known and matches the ECDSA host key.
debug1: Found key in /home/olivier/.ssh/known_hosts:6
debug1: found matching key w/out port
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
on passe à l'authentification par clé
debug1: Authentications that can
continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/olivier/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Skipping ssh-dss key /home/olivier/.ssh/id_dsa for not in
PubkeyAcceptedKeyTypes
debug1: Offering ECDSA public key: /home/olivier/.ssh/id_ecdsa
debug1: Server accepts key: pkalg ecdsa-sha2-nistp256 blen 104
Enter passphrase for key '/home/olivier/.ssh/id_ecdsa':
debug1: Authentication succeeded (publickey).
on a trouvé la bonne clé, on passe à la connexion effective
Authenticated to obelix
([192.168.13.11]:4321).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: client_input_global_request: rtype hostkeys-00@openssh.com
want_reply 0
debug1: Requesting X11 forwarding with authentication spoofing.
pas de X forwarding qui a été désactivé sur le serveur
X11 forwarding request failed on
channel 0
Last login: Wed Jan 18 15:44:27 2017 from 80.215.110.197
NOTES
- Les infos sur la machine seront sauvegardées dans le fichier ~/.ssh/known_hosts
-
Pour ne pas avoir à saisir à chaque fois le passpharase, il faut utiliser
un agent
[veronique@asterix .ssh]$ ssh obelix df
Enter passphrase for key '/home/veronique/.ssh/id_dsa':
Filesystem
1k-blocks Used Available Use% Mounted on
/dev/sdb1
149712
75053 66929 53% /
/dev/sda1
991995
806267 134478 86% /alphonse
/dev/sdb3
239979
77414 150175 34% /roger
/dev/sdb4
99136
42591 51425 45% /home
/dev/sdc5
938296
497756 392876 56% /usr
/dev/sdb5
496627
334344 136633 71% /usr/local
[veronique@asterix .ssh]$
Après exécution de la commande, la connexion est automatiquement coupée.
Remarquer bien que sur le client SSH, DISPLAY est
positionné à localhost qui correspond au serveur c'est tout à fait
normal, et là si vous lancez une commande X elle
s'affichera bien à l'écran d'asterix et non pas d'obelix.
xauth permet d'ajouter, éditer les autorisations pour se connecter
à un serveur X, concrètement sshd va appeler xauth pour
que les commandes X puissent s'afficher sur le client.
Bon par contre, si vous avez l'erreur suivante
[olivier@obelix olivier]$ xmms &
[1] 1036
[olivier@obelix olivier]$ Gdk-ERROR **: X connection to
obelix.armoric.bz:10.0 broken (explicit kill or server shutdown).
[1]+ Exit 1 xmms
Il faudra modifier le fichier .bashrc de l'utilisateur olivier au lieu de:
export XAUTHORITY=$HOME/.Xauthority
On mettra
[ -z $XAUTHORITY ] && export XAUTHORITY=$HOME/.Xauthority
Et là magique ça marche !!
[veronique@asterix veronique]$ scp toto obelix:/tmp
Enter passphrase for DSA key '/home/veronique/.ssh/id_dsa':
toto
100%
|****************************************|
27 00:00
Maintenant on veut récupérer le fichier titi se trouvant dans la home directory d'olivier, pour le mettre sous le /tmp d'asterix
[veronique@asterix veronique]$ scp obelix:/home/olivier/titi /tmp
Enter passphrase for DSA key '/home/veronique/.ssh/id_dsa':
olivier@obelix's password:
titi
100%
|****************************************|
15 00:00
Maintenant on va récupérer tout le répertoire php d'olivier pour le placer dans le répertoire courant (.)
[veronique@asterix veronique]$ scp -r obelix:/home/olivier/php .
Enter passphrase for DSA key '/home/veronique/.ssh/id_dsa':
fichier1
100%
|****************************************|
5 00:00
repertoire1 100%
|****************************************|
5 00:00
fichier2
100%
|****************************************|
5 00:00
Autres options intéressantes de scp:
-v verbose pour avoir un max de commentaires, notamment pour
l'établissement de la connexion et l'identification.
-p pour préserver les droits (conseillé)
-c pour changer le type de cryptage
-B mode batch pour mettre scp dans un script (plus besoin
de rentrer le passphrase et le mot de passe)
-C pour compresser
| [Retour page d'accueil ] | [Retour haut de la page ] |