SSH: Secure Shell Login

Transcription

1 SSH: Secure Shell Login Stéphane Salès dérnières modifications : 10 nov Table des matières 1.Introduction Pourquoi remplacer TELNET, FTP, «R*» Exemples de sniff depuis la machine C de différentes communications Communications non chiffrées...2 Récupération de mail via POP...2 Affichage du fichier /etc/shadow par TELNET : Communications chiffrées:...4 Récupération de mail par IMAP via un tunnel SSH: Différentes versions du protocole SSH : Fonctionnalités : Point de vue de la loi : Chiffrement et authentification: Chiffrement: Authentification Résumé:...9 chiffrement:...9 authentification: Pratique Paire clé privée/clé publique : Configuration client/serveur ssh: Les commandes scp/sftp : sources :...14 Page 1 / 20

2 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 Communications non chiffrées Récupération de mail via POP 23:04: > pop3: P 1:16(15) ack 40 win 5840 <nop,nop,timestamp > (DF) Page 2 / 20

3 0x e af5 c0a x0010 c0a8 01fe 04b b35a 7bd2 b37c n..=... 0x t 0x d2d c 696e X.- USER.login 0x d 0a 23:04: > pop3: P 16:31(15) ack 46 win 5840 <nop,nop,timestamp > (DF) 0x e af5 c0a E..C'o@.@.z... 0x0010 6f64 792e 310d 0a a n..=... 0x c20 636f 6d b71 3d x f6e 3a20 6b d61 6c 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 : E e c2 c0 a c0 a8.gsn@.@. CÂÀ. À d7 a4 b3 5b d8 79 a2 2a ³[Øy * f ff 05 cf a 00 f2 ed f2 00 f2.ÿ.ï......òíò.ò 0040 ed f f f f 73 íò cat /etc/s f 77 hadow a 3a 3a 0d 0a d 6f 3a :::.. demo:$1$i6q e a 79 6a a Page 3 / 20

4 gsa0$u2 zyjqwjpv f b d a a odgkhhmt szd0: a 30 3a a 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 Communications chiffrées: Récupération de mail par IMAP via un tunnel SSH: 22:56: > imaps: P : (74) ack win <nop,nop,timestamp > (DF) 0x e 337c f c0a x0010 c0a8 01fe 04aa 03e1 6dbd f254 6d6f m..Tmoq5 0x fd 5be a a..W.[...Q. 0x fe fb cc5 155b.&...s2..[ 0x f 8dd7 b8e9 9d33 a137 1c09 2f0d 8Tc /. 0x0050 e c1 202e 8a0f 35ef c288...( Page 4 / 20

5 0x0060 5e85 88f4 c4bd 58df 26e7 374d 94ed e5a6 ^...X.&.7M... 0x0070 fb03 6d95 62bf bfe cc9 1eec..m.b...hs<... 22:56: imaps > : P 1:246(245) ack 74 win 6432 <nop,nop,timestamp > (DF) 0x a2b b35 c0a8 01fe E..).+@.@ x0010 c0a e1 04aa 6d6f dbd f29e...moq5m... 0x aaf a b...&.+ 0x a f092 4cc0 d5c3 589a..Q...L...X. 0x d 723e 0df0 4d5a 65d5 f8d1 813a 4aa5 %.r>..mze...:j. 0x c6 d11d 3d15 096b 1ad6 667f =..k..f.%qW. 0 x c 6 a 8 a a 9 e f b a 7 f f 3 d e 4 7 d 6 1 d 7 e 8 6 c... P e... =.a..l 0x aad a613 6cfa 13e a Q.:...l...06.Rtj 0x0080 2a89 9a9d 9c1f 7c73 eef9 d8ec 58a6 ec5d *... s...x..] 0x0090 6d60 55ee 7a00 a88c b12d ef m`u.z...-.$..r. 0x00a0 6e74 6e27 773c 24be 9c12 70a1 92a2 e612 ntn'w<$...p... 0x00b0 d563 23ba 70a7 88c d 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 d f 7 a b d z 1.. J: U m Page 5 / 20

6 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

7 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

8 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

9 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

10 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 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

11 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

12 # 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

13 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

14 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 : Page 14 / 20

15 [1] [2] [3] [4] Page 15 / 20

16 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

17 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

18 # 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

19 # 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

20 ligne de commande? Page 20 / 20