SSH: Secure Shell Login Stéphane Salès s.sales@tuxz.org dérnières modifications : 10 nov. 2003 Table des matières 1.Introduction...2 2.Pourquoi remplacer TELNET, FTP, «R*»...2 2.1.Exemples de sniff depuis la machine C de différentes communications...2 2.1.1.Communications non chiffrées...2 Récupération de mail via POP...2 Affichage du fichier /etc/shadow par TELNET :...3 2.1.2.Communications chiffrées:...4 Récupération de mail par IMAP via un tunnel SSH:...4 3.Différentes versions du protocole SSH :...6 4.Fonctionnalités :...7 5. Point de vue de la loi :...8 6. Chiffrement et authentification:...8 6.1.Chiffrement:...8 6.2.Authentification...8 7.Résumé:...9 chiffrement:...9 authentification:...9 8.Pratique...10 8.1.Paire clé privée/clé publique :...10 8.2.Configuration client/serveur ssh:...10 8.3.Les commandes scp/sftp :...13 9.sources :...14 Page 1 / 20
1.Introduction SSH ou Secure Shell est un protocole voué à, être utilisé en lieu et place du protocole TELNET ainsi qu'à, éradiquer l'utilisation des commandes «R*» telle que RLOGIN,RCP,RSH. 2.Pourquoi remplacer TELNET, FTP, «R*» Parceque TELNET,FTP et les commandes «R*» communiquent en «clair»(voir 3.1), c'est à dire que toutes les communications entre le serveur et le client ne sont pas chiffrées et peuvent donc etre lus par n'importe quel curieux s'en donnant un peu la peine(notons qu'un grand nombre de protocoles utilisés courament en font de meme : POP, SMTP, HTTP...). Imaginons que depuis une machine A et via TELNET j'affiche le fichier contenant les mots de passe des utilisateurs de ma machine B : Si une personne se place sur la machine C et arrive à «sniffer» la communication il pourra lire le fichier exactement comme moi. 2.1.Exemples de sniff depuis la machine C de différentes communications 2.1.1.Communications non chiffrées Récupération de mail via POP 23:04:57.882084 192.168.1.32.1210 > 213.228.0.165.pop3: P 1:16(15) ack 40 win 5840 <nop,nop,timestamp 1120884 123247917> (DF) Page 2 / 20
0x0000 4500 0043 276e 4000 4006 7af5 c0a8 0120 E..C'n@.@.z... 0x0010 c0a8 01fe 04b7 0050 b35a 7bd2 b37c 5836...n..=... 0x0020...t 0x0030 0758 9d2d 5553 4552 206c 696e 7573 7175.X.- USER.login 0x0040 650d 0a 23:04:57.953994 192.168.1.32.1210 > 213.228.0.165.pop3: P 16:31(15) ack 46 win 5840 <nop,nop,timestamp 1120891 123247924> (DF) 0x0000 4500 0043 276e 4000 4006 7af5 c0a8 0120 E..C'o@.@.z... 0x0010 6f64 792e 310d 0a41 6363 6570 743a 2074...n..=... 0x0020 7465 2c20 636f 6d70 7265 7373 3b71 3d30... 0x0030 469 6f6e 3a20 6b65 6570 2d61 6c69 7665.X.4 PASS.motdepasse 0x0040 0d0a 0a... Ici on voit en clair le login et le mot de passe de l'utilisateur Affichage du fichier /etc/shadow par TELNET : 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 10......E. 0010 00 47 73 4e 40 00 40 06 43 c2 c0 a8 01 20 c0 a8.gsn@.@. CÂÀ. À 0020 01 20 00 17 11 35 d7 a4 b3 5b d8 79 a2 2a 80 18....5 ³[Øy *.. 0030 7f ff 05 cf 00 00 01 01 08 0a 00 f2 ed f2 00 f2.ÿ.ï......òíò.ò 0040 ed f2 73 75 64 6f 20 76 69 20 2f 65 74 63 2f 73 íò cat /etc/s 0050 68 61 64 6f 77 hadow 0300 3a 3a 3a 0d 0a 64 65 6d 6f 3a 24 31 24 49 36 51 :::.. demo:$1$i6q 0310 2e 67 73 61 30 24 55 32 7a 79 6a 71 77 6a Page 3 / 20
50 56. gsa0$u2 zyjqwjpv 0320 6f 44 47 6b 48 48 4d 74 73 7a 44 30 3a 31 32 31 odgkhhmt szd0:121 0330 33 34 3a 30 3a 39 39 39 39 39 3a 37 3a 3a 3a 0d 34:0:999 99:7:::. Ici le fichier /etc/shadow est chiffré en md5 et n'est donc pas lisible directement, mais rien ne dit qu'en y passant du temps il ne serait pas possible de découvrir certain mot de passe. Imaginez ce que cela aurait donné si on avait affiché un fichier contenant son code de carte bleue par exemple. 2.1.2.Communications chiffrées: Récupération de mail par IMAP via un tunnel SSH: 22:56:23.709109 192.168.1.32.1194 > 192.168.1.254.imaps: P 1841164884:1841164958(74) ack 1836020021 win 22525 <nop,nop,timestamp 1069466 321259006> (DF) 0x0000 4500 007e 337c 4000 4006 828f c0a8 0120 E..~3 @.@... 0x0010 c0a8 01fe 04aa 03e1 6dbd f254 6d6f 7135...m..Tmoq5 0x0020 8018 57fd 5be9 0000 0101 080a 0010 519a..W.[...Q. 0x0030 1326 05fe 1703 0100 18fb 7332 7cc5 155b.&...s2..[ 0x0040 3854 631f 8dd7 b8e9 9d33 a137 1c09 2f0d 8Tc...3.7../. 0x0050 e517 0301 0028 31c1 202e 8a0f 35ef c288...(1...5... Page 4 / 20
0x0060 5e85 88f4 c4bd 58df 26e7 374d 94ed e5a6 ^...X.&.7M... 0x0070 fb03 6d95 62bf bfe4 6873 3cc9 1eec..m.b...hs<... 22:56:23.711808 192.168.1.254.imaps > 192.168.1.32.1194: P 1:246(245) ack 74 win 6432 <nop,nop,timestamp 321259819 1069466> (DF) 0x0000 4500 0129 8a2b 4000 4006 2b35 c0a8 01fe E..).+@.@.+5... 0x0010 c0a8 0120 03e1 04aa 6d6f 7135 6dbd f29e...moq5m... 0x0020 8018 1920 aaf5 0000 0101 080a 1326 092b...&.+ 0x0030 0010 519a 1703 0100 f092 4cc0 d5c3 589a..Q...L...X. 0x0040 250d 723e 0df0 4d5a 65d5 f8d1 813a 4aa5 %.r>..mze...:j. 0x0050 94c6 d11d 3d15 096b 1ad6 667f 2571 5795...=..k..f.%qW. 0 x 0 0 6 0 c 6 a 8 a a 9 e 5 0 6 5 f b a 7 f f 3 d e 4 7 d 6 1 d 7 e 8 6 c... P e... =.a..l 0x0070 5180 3aad a613 6cfa 13e6 3036 0452 746a Q.:...l...06.Rtj 0x0080 2a89 9a9d 9c1f 7c73 eef9 d8ec 58a6 ec5d *... s...x..] 0x0090 6d60 55ee 7a00 a88c b12d 1724 9ef5 7295 m`u.z...-.$..r. 0x00a0 6e74 6e27 773c 24be 9c12 70a1 92a2 e612 ntn'w<$...p... 0x00b0 d563 23ba 70a7 88c8 8084 0467 76d6 7262.c#.p...gv.rb 0 x 0 0 c 0 7 a 3 1 a 0 0 b 4 a 3 a 5 5 b f 0 6 7 d f 7 a 1 3 3 8 b 9 0 6 d z 1.. J: U....3..m Page 5 / 20
On s'aperçoit ici que les communications entre A et B ne sont pas lisibles par C, ni d'ailleurs par n'importe quelle entité ne se trouvant pas à un des 2 bouts du tunnel: Il est donc fortement conseillé d'utiliser SSH notamment lorsque les communications peuvent faire transiter des informations qui ne doivent pas être lues par un tiers et d'autant plus quand elles sont voués à "traverser" un réseau publique tel qu'internet. 3.Différentes versions du protocole SSH : Il existe 2 versions majeures de SSH, la version 1 qui se décompose en 2 versions mineures 1.5 et 1.99, la version 2 qui est une refonte totale du protocole SSH. Quand il le sera possible nous utiliserons uniquement la version 2 car elle est plus sécurisée, le système de contrôle d'intégrité des données de SSH1, un simple CRC, étant dépassé est remplacé par un algorithme nommé HMAC dans SSH2. (Du coté client comme du coté serveur, il est possible d'utiliser les 2 protocoles en spécifiant un ordre de préférence). Page 6 / 20
OpenSSH : 4.Fonctionnalités : OpenSSH est une implémentation Libre[1] d'ssh(distribué sous une licence BSD[2])qui implémente les fonctions suivantes : Chiffrement fort(3des, BLOWFISH) Transfert X11(X11 forwarding,transférez l'affichage d'un serveur X situé sur une machine A vers une machine B à travers un tunnel SSH) Transfert de port(port forwarding, "transférez un port" d'une machine vers une autre via un tunnel SSH) Authentification forte(clé publique, mot de passe à usage unique avec s/key, Kerberos) A partir de la version 2.5 un démon SFTPD supporte totalement SFTPD(la Page 7 / 20
version sécurisée de FTP). Compression des données(bien utile en cas de connexion lente, via un modem par exemple) 5. Point de vue de la loi : OpenSSH peut utilisé des algorithmes de chiffrement dit "fort", par le biais d'openssl, qui n'était pas explicitement autorisée jusqu'au "15 juillet 2002" où grâce à l'élaboration du dossier[3] pour la DCSSI faite par Loic Dachary, l'utilisation d'openssl est permise pour les versions 0.9.6d et suivantes. 6. Chiffrement et authentification: 6.1.Chiffrement: Le choix de la méthode de chiffrement peut avoir une influence notable sur : la sécurité des communications : certaines méthodes sont considérés comme plus sur que d'autre la vitesse de transmission : certaines méthodes réclament un temps supérieur de chiffrement par rapport à d'autres Les différentes méthodes de chiffrement utilisable par OpenSSH sont : DES: Data Encryption Standard basé sur des permutations de blocs de 64 bits, il n'est utilisable qu'avec la version 1 de SSH car il n'est plus considéré comme sur de nos jours. 3DES: basé sur le chiffrement DES, il effectue 3 permutations quand le DES n'en effectue qu'une. Il est utilisable par les 2 versions de SSH. BLOWFISH: méthode utilisant des blocs de 64 bits. Cette méthode est considérée comme sur, plus rapide que 3DES et est utilisable par les 2 versions de SSH La version 2 de SSH accepte d'autres algorithmes tel que AES, ARCFOUR et CAST.(SSH 1 proposait aussi l'algorithme IDEA mais celui ci à été enlevé car d'une part un brevet existe sur cet algorithme dans certains pays et d'autre part une faille non corrigée à été publiée sur ce dernier mi-janvier 2001 [4]) 6.2.Authentification Pour considérer qu'une communication est sécurisée, il va falloir s'assurer que les 2 machines sont bien celles qui veulent communiquer et qu'une autre Page 8 / 20
machine ne pourra pas se faire passer pour l'une ou l'autre. Pour cela SSH met à disposition plusieurs méthodes : mot de passe : le client s'authentifie via un login et un mot de passe paire clé privée/clé publique : le client et le serveur échange leur paire de clés ce qui permet de certifier, qui est le client et qui est le serveur. La version 1 de SSH permet l'utilisation de clés RSA uniquement alors que la version 2 permet en plus l'utilisation de clés DSA. one-time-password : utilisation d'un mot de passe à usage unique via s/key La version 1 de SSH permet aussi l'authentification basé sur Kerberos. À Ces 2 méthodes permettant d'authentifier l'utilisateur ont peut ajouter une méthode d'authentification des machines, basé sur le même principe d'échange de clés RSA/DSA, appelé HostBased. 7.Résumé: chiffrement: Cipher SSH1 SSH2 DES oui non 3DES oui oui IDEA oui non Blowfish oui oui Arcfour non oui Cast128 non oui AES128 non oui AES192 non oui AES256 non oui authentification: Cipher SSH1 SSH2 RSA oui oui DSA non oui Page 9 / 20
8.Pratique 8.1.Paire clé privée/clé publique : Génération de la paire de clés demo@hote_local:~$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/demo/.ssh/id_dsa): demo_dsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in / home/demo/.ssh/demo_dsa. Your public key has been saved in / home/demo/.ssh/demo_dsa.pub. The key fingerprint is: xx:xx:xx:xx:xx:xx:xx:6c:d7:36:6c:17:83:a3:77:bb demo@hote_local La clé privée doit n'être lisible/visible que par le propriétaire demo@hote_local:~$ ls -l.ssh/ total 8 -rw------- 1 demo demo 668 Jan 28 16:16 id_dsa -rw-r--r-- 1 demo demo 607 Jan 28 16:16 id_dsa.pub Sur l'hôte distant on autorise le user demo à se connecter : demo@hote_distant:~$ cat demo_dsa.pub >> ~/.ssh/demo_authorized_keys2 8.2.Configuration client/serveur ssh: root@hote_distant:~#vi /etc/ssh/sshd_config # Package generated configuration file # See the sshd(8) manpage for defails # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: Page 10 / 20
Protocol 2,1 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_rsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes #...but breaks Pam auth via kbdint, so we have to turn it off # Use PAM authentication via keyboard-interactive so PAM modules can # properly interface with the user (off due to PrivSep) PAMAuthenticationViaKbdInt no # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 600 AllowUsers demo DenyUsers root ftp ssh nobody #normalement on autorise JAMAIS le root à se connecter à un démon PermitRootLogin no StrictModes no RSAAuthentication no PubkeyAuthentication yes #%h variable représentant le home du user AuthorizedKeysFile %h/.ssh/authorized_keys2 AuthorizedKeysFile % h/.ssh/demo_authorized_keys2 # rhosts authentication should not be used RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes Page 11 / 20
# For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication yes # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Uncomment to disable s/key passwords #ChallengeResponseAuthentication no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication 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 X11Forwarding no X11DisplayOffset 10 PrintMotd no #PrintLastLog no KeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net #ReverseMappingCheck yes Subsystem sftp /usr/lib/sftp-server La configuration globale du client ssh est situé dans le fichier / etc/ssh/ssh_config, la configuration par utilisateur est elle dans le fichier ~/.ssh/config (on peut tout redéfinir,à la volée en ligne de commande ). Page 12 / 20
L'ordre de prise en compte des paramètres coté client est le suivant : options par défaut -> /etc/ssh/ssh_config -> ~/.ssh/config -> paramètres passés en ligne de commande Si par exemple ForwardX11 est à no dans /etc/ssh/ssh_config ET dans ~/.ssh/config mais qu'on passe -X en ligne de commande à la connexion(et que le serveur accepte le X11forwarding) on pourra forwarder le X. 8.3.Les commandes scp/sftp : Ces commandes permettent de tranférez des fichiers. Par exemple : demo@hote_local$scp / repertoire/fichier_a_transferez hote_distant:/home/demo2/ Cette commande tranfère le fichier fichier_a_transferez vers l'hôte distant et dans le répertoire home de l'utilisateur demo2(bien entendu si l'utilisateur demo n'a pas les droit d'écriture dans le répertoire de destination le transfert ne fonctionnera pas) Notons qu'il est possible de s'identifier comme étant un autre utilisateur auprès de l'hôte distant grâce au paramètre -l utilisateur ou grâce à la notation utilisateur@hote_distant : demo@hote_local$ scp -l demo2 / repertoire/fichier_a_transferez hote_distant:/home/demo2/ demo@hote_local$ scp / repertoire/fichier_a_transferez demo2@hote_distant:/home/demo2/ Si mon compte est authorisé (par mot de passe, par échange de clés etc) On aurait pu aussi tranferez le répertoire entier ainsi : demo@hote_local$ scp -r /repertoire/ hote_distant:/home/demo2/ La commande sftp lance le client sftp qui permet de se connecter au serveur sftpd distant(l'utilisation est ensuite très semblable à celle d'un client ftp classique). Ci dessous la liste des commandes supportées par ce dernier sftp> help Available commands: cd path Change remote directory to 'path' lcd path Change local Page 13 / 20
directory to 'path' chgrp grp path Change group of file 'path' to 'grp' chmod mode path Change permissions of file 'path' to 'mode' chown own path Change owner of file 'path' to 'own' help Display this help text get remote-path [local-path] Download file lls [ls-options [path]] Display local directory listing ln oldpath newpath Symlink remote file lmkdir path Create local directory lpwd Print local working directory ls [path] Display remote directory listing lumask umask Set local umask to 'umask' mkdir path Create remote directory put local-path [remote-path] Upload file pwd Display remote working directory exit Quit sftp quit Quit sftp rename oldpath newpath Rename remote file rmdir path Remove remote directory rm path Delete remote file symlink oldpath newpath Symlink remote file version Show SFTP version!command Execute 'command' in local shell! Escape to local shell? Synonym for help 9.sources : http://openssh.org Page 14 / 20
http://openssl.org http://www.ietf.org/ids.by.wg/secsh.html [1] http://www.gnu.org/philosophy/free-sw.fr.html [2] http://www.openbsd.org/cgibin/cvsweb/src/usr.bin/ssh/licence?rev=head [3] http://france.fsfeurope.org/dcssi/dcssi.fr.html [4] http://www.kb.cert.org/vuls/id/315308 Page 15 / 20
TP : Pour répondre aux questions ci-dessous vous fournirez des copié/collé de terminaux, d'écrans, de sniff, de fichiers de configuration...(toute information vous semblant pertinente). Installer les outils nécessaires à la mise en place de communication SSH : $apt-get install ssh Installer ngrep/tcpdump : $ apt-get install ngrep tcpdump 1 Configurer votre serveur SSH pour qu'on puisse s'y connecter via une authentification par mot de passe et tester. 2 Lancer ngrep, ouvrer une connexion FTP, ou pop par exemple, qu'observer vous? 3 Lancer ngrep, ouvrer une connexion SSH et vérifier que la communication est bien chiffrée. 4 Faites de même avec une authentification par échange de clés dsa. 5 Faites écouter votre serveur sur le port 2222 et connecter vous y. 6 Trouver le moyen de vous y connecter sans avoir à préciser le port en ligne de commande. 7 Faites de même mais pour que cette fois le serveur ssh n'écoute que sur l'interface lo, pour vérifier vous lancerez les commandes : ssh localhost ssh nom_de_machine 8 Activer la fonctionnalité de transfert de l'affichage(transfert du serveur x). 9 Connecter vous sur une machine distante et tester cette fonctionnalité. 10 Donnez la syntaxe pour transférer le fichier / home/crespa/essai0.scp de votre machine vers le fichier / home/crespa/essai01.scp d'une machine distante via scp. 11 Donnez la syntaxe pour transférer un fichier / home/crespa/essai1.scp d'une machine distante vers la sienne dans le 'home' de l'utilisateur crespa via scp. 12 Donnez la syntaxe pour transférer le fichier / Page 16 / 20
home/crespa/essai0.scp de votre machine vers le fichier / home/demo-xxx/essai01.scp d'une machine distante via scp. 13 Donnez la syntaxe pour transférer un fichier /home/demoxxx/essai1.scp d'une machine distante vers la sienne dans le 'home' de l'utilisateur demo via scp. 14 Faites de même avec sftp. 15 Tester un transfert via sftp ou scp en testant les différents algorithmes, vérifier grâce à la commande time quels sont les algorithmes les plus rapides(faites des tests avec différentes taille de fichier). 16 Forwarder le port local 2223 vers le port 22 d'une machine distante, et maintenant lancer une connexion SSH vers le port local 2223 : Qu'observez vous? 17 Donnez la commande à lancer sur votre machine pour que la machine distante se connecte à votre port serveur SSH, en se connectant à son port local 2224 Soit une machine A et une machine B, un user demoa(sur la machine A) veut se connecter sur la machine B via le compte demob les comptes sur les 2 machines viennent d'être "fraîchement" crées: On suppose que le client ssh est installé sur la machine A et que le serveur ssh est installé sur la machine B... configuration coté serveur : root@hote_distant:~#vi /etc/ssh/sshd_config # Package generated configuration file # See the sshd(8) manpage for defails # What ports, IPs and protocols we listen for #Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: ListenAddress localhost:2222 Protocol 2,1 # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes #...but breaks Pam auth via kbdint, so we have to turn it off Page 17 / 20
# Use PAM authentication via keyboard-interactive so PAM modules can # properly interface with the user (off due to PrivSep) PAMAuthenticationViaKbdInt no # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 600 AllowUsers demo DenyUsers root ftp ssh nobody #normalement on autorise JAMAIS le root à se connecter à un démon PermitRootLogin no StrictModes no RSAAuthentication no PubkeyAuthentication yes #%h variable représentant le home du user AuthorizedKeysFile %h/.ssh/authorized_keys2 AuthorizedKeysFile % h/.ssh/demo_authorized_keys2 # rhosts authentication should not be used RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication yes # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication IgnoreUserKnownHosts yes Page 18 / 20
# To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Uncomment to disable s/key passwords #ChallengeResponseAuthentication no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication 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 X11Forwarding no X11DisplayOffset 10 PrintMotd no #PrintLastLog no KeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net #ReverseMappingCheck yes Subsystem sftp /usr/lib/sftp-server 18 Pourquoi est il impossible de se connecter interactivement avec un mot de passe? 19 L'authentification par échange de clés ne fonctionne pas, pourquoi? 20 Pourquoi ssh localhost:22 ne marche pas? 21 Pourquoi ne peut on pas se connecter depuis un hôte distant? 22 Solutions? 23 Comment "automatiser" sans avoir à spécifier le port en Page 19 / 20
ligne de commande? Page 20 / 20