1
One of the interesting things about the Internet is that it was not designed for security, and kind of happened almost accidentally. The early researchers, people like JCR Licklider and Vint Cerf, were mostly interested in facilitating communication between university researchers, and assumed that anyone they were in contact with was another “good guy”. It was only when the Internet started to take off in the 1980s and 1990s that anyone began to pay attention to this stuff. Technologies like Javascript and SSL were introduced by Netscape, for instance, though they have since been adopted by the whole Internet. Intro In the early days, if you wanted to log on to a remote computer to do some work, you would probably use a program called Telnet to do this. Telnet would let you log in to a remote Unix machine if you had an account on it, and, once logged in, you could do anything your account was authorized to do. And if you had root access, it could be just about anything. I recall my first introduction to this in the 1990s when I was managing the website of my university. I was given a shell account on our Red Hat server that also housed the web site, and sternly warned not to do anything to screw it up. I would Telnet into the server from my desktop to do things like chmod the CGI scripts and similar things we needed to do with websites in those days. This worked reasonably well, but the problem with Telnet is that it was never designed to create a secure connection, and since this server had our Website, it was perforce exposed to the whole Internet. If you combine an unsecure connection with a man-in-the-middle attack, or with vulnerabilities in the Telnet program that allowed an attacker to get in, and even escalate their privileges, you can see why this became an issue.
Une des choses les plus intéressantes concernant l'Internet est que ce n'était pas conçu pour la sécurité et que c'est arrivé, pour ainsi dire, presque par accident. Les chercheurs du début, des gens comme JCR Licklider et Vint Cert, voulaient surtout faciliter la communication entre des chercheurs universitaires ; ils supposaient donc que quiconque avec qui ils avaient des contacts était un autre « mec bien ». Ce n'est que quand le développement de l'Internet s'est intensifié dans les années 1980 et 1990 que certains ont commencé à prêter attention à ce genre de choses. Des technologies comme Javascript et SSL furent introduites par Netscape, par exemple, bien que, depuis, ils aient été adoptés par tout le Net.
Intro
Au début, si vous vouliez vous connecter sur un ordinateur distant pour travailler, vous pouviez sans doute utiliser un programme appelé Telnet pour le faire. Telnet vous permettait de vous connecter à une machine Unix distante si vous aviez un compte dessus ; une fois connecté, vous pouviez faire tout ce que votre compte était autorisé à faire. Et, si vous aviez un accès root, cela aurait pu être à peu près n'importe quoi. Je me souviens de la première fois où j'ai participé à une telle chose, dans les années 1990 où je gérais le site Web de mon université. On m'a attribué un compte shell sur notre serveur Red Hat qui hébergeait également le site Web ; on m'a prévenu très sérieusement qu'il ne fallait rien faire qui puisse le bousiller. À partir de mon ordinateur de bureau, j'allais sur le serveur via Telnet pour faire des trucs comme chmod les scripts CGI et ce genre de choses qu'il fallait faire avec les sites Web à cette époque. Cela fonctionnait raisonnablement bien, mais le problème avec Telnet est qu'il n'était pas conçu pour créer une connexion sûre et, puisque notre site Web était sur ce serveur, il était par la force des choses exposé au Net entier. Si vous mettez ensemble une connexion non protégée et une attaque de type « l'homme au milieu » ou des vulnérabilités dans le programme Telnet, grâce auxquelles un attaquant pouvait entrer et, qui plus est, augmenter ses droits, vous comprendrez pourquoi c'est devenu un problème.
2
In 1995 there was a password-sniffing attack on the network of the University of Helsinki in Finland, and this led a researcher there, Tatu Ylönen, to create the first SSH implementation. SSH is an acronym for Secure Shell, and expresses the idea that you can securely log in and get a shell on a remote server. This was initially released as free software, but in later versions he took it proprietary. But the developers at OpenBSD decided that a free software implementation was needed, and they created OpenSSH, which is the basis for most implementations today. And while SSH was initially intended for Unix-like environments (which came to include Linux), the OpenBSD developers created a portability branch to make it available to any OS. So, if you are running a Windows environment, you can use SSH just as easily. If you want a little more detail on this you can consult Wikipedia. Design Considerations SSH was designed to do several things: • Create secure and private communication between two different machines. This means that the connection must use encryption. • Establish the integrity of the communications to ensure that messages have not been altered en route. Again, encryption makes this possible. • Authenticate both parties to the conversation to prove their identities. Again, encryption makes this possible.
En 1995, il y a eu une attaque à la recherche de mots de passe sur le réseau de l'université d'Helsinki en Finlande et cela a amené un chercheur là-bas, Tatu Ylönen, à créer la première implémentation de SSH. SSH est un acronyme de Secure Shell et exprime l'idée que vous pouvez vous connecter de façon sûre et obtenir un shell sur un serveur distant. Au départ, ce fut publié en tant que Logiciel libre, mais, lors de versions ultérieures, il l'a rendu propriétaire. Toutefois, les développeurs chez OpenBSD ont décidé qu'un Logiciel libre devait être implémenté et ils ont créé OpenSSH, devenu aujourd'hui la base de la plupart des implémentations. Et, alors qu'au départ, SSH fut fait pour des environnements comme Unix (ce qui, à la longue, incluait Linux), les développeurs chez OpenBSD ont créé une branche pour la portabilité qui le rendait disponible sur n'importe quel système d'exploitation. Ainsi, si vous êtes sous Windows, vous pouvez utiliser SSH tout aussi facilement. Si vous voulez un peu plus de détails à ce sujet, allez voir Wikipedia.
Considérations de conception
SSH fut conçu pour faire plusieurs choses : * Créer une communication privée et sûre entre deux machines différentes. Cela veut dire que la connexion doit utiliser le chiffrement. * Établir l'intégrité des communications pour assurer que les messages n'ont pas été modifiés en chemin. Encore une fois, ceci est possible grâce au chiffrement. * Authentifier les deux participants à la conversation pour pouvoir démontrer leur identité. À nouveau, ceci se fait par le biais du chiffrement.
3
As regards authentication, SSH can be done using passwords, but that is a weaker form of authentication. If you are serious about security, you should authenticate using a key. Our old friends the public/private key pair come in at this point, and, as you might imagine, the outlines of how this is done are pretty similar to what we saw in both E-mail and in Certificates. This is not perfect, of course, but it reduces the chances of an attack very significantly. Note that even if you are using password authentication, there is encryption and key-exchanging going on. That is necessary to accomplish the first two of the above goals. Encryption and Tunneling The basic idea in SSH, just as with Virtual Private Networks, is to use encryption to create secure communications between two different systems. It has become customary to refer this type of connection as a “tunnel”. This is a metaphor, and like all metaphors it both illuminates some things and obscures others. The idea of a tunnel does help to get across the security of the connection, in that if done properly the outside world cannot see what is going on. The encryption does work if you do it right, and as Bruce Schneier famously said in the wake of the Snowden revelations, you can trust the mathematics. However, the metaphor somehow implies to people that this traffic is flowing in some other place than the rest of the Internet, and that is simply untrue. All “tunnel” traffic flows through the same routers and switches as all other Internet traffic, and is made up of the same kinds of packets. If you are on a network where someone is using SSH, you can “see” the packets using wireshark or other similar software. But you would not be able to see anything in the payload of each packet other than random noise because of the encryption. It is important to understand the mechanisms and how they work if you are going to be secure, since otherwise you might make a mistake and open yourself to an attack.
Quant à l'authentification, on peut utiliser des mots de passe avec SSH, mais cette forme d'authentification est assez faible. Si la sécurité vous préoccupe beaucoup, vous devrez vous authentifier au moyen d'une clé. Nos vieux copains la paire de clés publique/privée arrivent sur scène à ce stade et, comme vous pourriez le supposer, les grandes lignes de comment faire ressemblent assez à ce que nous avons vu dans, à la fois, les mails et les certificats. Bien entendu, ce n'est pas parfait, mais cela réduit de façon très significative les possibilités d'une attaque. Notez que, même si vous utilisez l'authentification par mot de passe, cela implique un chiffrement et un échange de clés. C'est nécessaire pour réaliser les deux premiers objectifs ci-dessus.
Chiffrement et « tunneling »
L'idée de base dans SSH, tout comme dans les réseaux privés virtuels (VPN), c'est d'utiliser le chiffrement pour créer des communications sûres entre deux systèmes différents. Nous avons pris l'habitude de parler de ce type de connexion en termes de « tunnel ». Ceci est une métaphore et, comme toutes les métaphores, elle éclaire des choses tout en en obscurcissant d'autres. L'idée d'un tunnel aide en fait à faire comprendre la sécurité de la connexion, puisque, si c'est bien fait, le monde extérieur ne peut pas voir se qui s'y passe. Le chiffrement fonctionne bien, s'il est fait comme il faut, et, pour reprendre les célèbres paroles de Bruce Schneier après les révélations de Snowden, vous pouvez faire confiance aux mathématiques. Cependant, la métaphore semble laisser entendre que ce trafic coule quelque part ailleurs que le reste du Net et cela est tout simplement faux. Tout le trafic du « tunnel » passe par les mêmes routeurs et hubs que tout le reste du trafic sur le Net et c'est composé de la même sorte de paquets. Si vous êtes sur un réseau où quelqu'un se sert de SSH, vous pouvez « voir » les paquets avec wireshark ou d'autres logiciels similaires. Mais vous ne pourriez pas rien voir dans la charge utile de chaque paquet, autre que du bruit aléatoire, à cause du chiffrement.
Si vous voulez être protégé, il est important de comprendre les mécanismes et leur fonctionnement, puisque, dans le cas contraire, vous pourriez faire une erreur et vous exposer à une attaque.
4
SSH Uses Although SSH originally was developed to simply provide a secure shell session on a remote server, it has been extended in a number of interesting ways which we will look at in upcoming tutorials. For example, SSH can be used to: • Create tunnels • Forward TCP ports • Create X11 connections • Securely transfer files (SFTP) • Securely copy files (SCP) • Securely mount a remote file system (SSHFS) Where Do You Get SSH? SSH uses the client-server model. Generally, you are coming from a desktop and want to connect to a remote server. If the server is Unix or Linux, it should have SSH installed and properly configured if the sysadmins are any good. On Windows servers, it may need to be installed, but this is not difficult. For any Windows sysadmins out there, here is an article that explains the installation on a Windows 2008 server.
Les utilisations de SSH
Bien que, à l'origine, SSH fut développé pour tout simplement fournir une session shell protégée sur un serveur distant, il a été étendu dans de nombreuses façons intéressantes que nous regarderons dans des tutoriels à venir. Par exemple, SSH peut être utilisé pour :
* Créer des tunnels. * Transférer des ports TCP. * Créer des connexions X11. * Transférer des fichiers en toute sécurité (SFTP). * Copier des fichiers en toute sécurité (SCP). * Monter un système de fichiers distant en toute sécurité (SSHFS).
Où obtenir SSH ?
SSH utilise le modèle client-serveur. En général vous venez d'un ordinateur de bureau et voulez vous connecter à un serveur distant. Si le serveur est Unix ou Linux, SSH devrait y être installé et configuré comme il faut si les administrateurs du système connaissent bien leur boulot. Sur les serveurs Windows, vous devrez éventuellement l'installer, mais ce n'est pas difficile. Pour les administrateurs de systèmes Windows, voici un article expliquant l'installation de SSH sur un serveur Windows 2008.
5
As for desktop clients, again all Unix-like systems have the SSH client installed by default. This includes Unix, Linux, MacOS, all flavors of BSD. For windows users, I recommend installing PuTTY. This is free software, is distributed under the MIT license, and complies with the Debian Free Software Guidelines. There are several PuTTY applications, since they use different applets for each of the capabilities, so one is for Secure Shell, another for SFTP, and so on. There is a useful manual for OpenSSH and for the various applications that make up all of OpenSSH which can be found at http://www.openssh.com/manual.html. From here you can see that the applications which make up all of OpenSSH include: • ssh – The basic rlogin/rsh-like client program. • ssh_config – The client configuration file. • sshd – The daemon that permits you to login. • sshd_config – The daemon configuration file. • ssh-agent – An authentication agent that can store private keys. • ssh-add – Tool which adds keys to the above agent. • sftp – FTP-like program that works over SSH1 and SSH2 protocol. • scp – File copy program that acts like rcp. • ssh-keygen – Key generation tool. • sftp-server – SFTP server subsystem (started automatically by sshd). • ssh-keyscan – Utility for gathering public host keys from a number of hosts. • ssh-keysign – Helper program for hostbased authentication.
Quant aux clients sur ordinateurs de bureau, je me répète, le client SSH est installé par défaut sur tous les systèmes de type Unix. Cela comprend Unix, Linux, MacOS et toutes les variétés de BSD. Pour les utilisateurs de Windows, je recommande l'installation de PuTTY : c'est gratuit, distribué sous licence MIT et se conforme aux « Debian Free Software Guidelines ». Puisqu'il utilise des applets différents pour chacune de ses fonctionnalités, il y a plusieurs applications PuTTY, une pour Secure Shell, une autre pour SFTP et ainsi de suite.
Un manuel très utile qui couvre Open SSH et les différentes applications qui le composent se trouve à http://www.openssh.com/manual.html. Ici, vous pouvez constater que les applications qui font partie de OpenSSH sont, notamment : • ssh – Le programme client de base, rlogin/type-rsh. • ssh_config – Le fichier de configuration client. • sshd – Le démon qui vous permet de vous connecter. • sshd_config – Le fichier de configuration du démon. • ssh-agent – Un agent d'authentification qui peut stocker des clés privées. • ssh-add – Un outil qui ajoute des clés à l'agent ci-dessus. • sftp – Programme de type FTP qui utilise les protocoles SSH1 et SSH2. • scp – Un programme de copie de fichiers qui agit comme rcp. • ssh-keygen – Outil pour générer des clés. • sftp-server – Sous-système serveur SFTP (démarré automatiquement par sshd). • ssh-keyscan – Utilitaire qui rassemble des clés publiques hôtes de nombreux hôtes. • ssh-keysign – Un programme d'assistance pour l'authentification basée sur l'hôte.
6
Basics So, as we saw in the last tutorial, SSH uses the Client-Server model. Now, technically a server is just the machine you are connecting to, and there is no reason in principle that it could not be another desktop, a laptop, or even a telephone if it has the appropriate software. So, the model really reduces to you as the client, and the other machine as the server. As with all Internet connections, there are standards and protocols involved. The original Telnet communicated over TCP through port 23. Because SSH was conceived as a replacement, it used the same TCP protocols, and was assigned the adjacent port number of 22. This is the standard, but it is not set in stone. Indeed, one of the ways you can improve security is to use a non-standard port. This requires that the server is configured for a different port. Servers monitor ports using daemons, so the server administrator would need to configure the daemon to listen to the alternate port, such as 16180, for SSH traffic, and then communicate this to the potential clients. This is a good thing to know if you are using SSH to log in to a remote server that you administer (for example, you may have a server co-located in a data center, or a Virtual Private Server that you control and administer). If a vulnerability in the SSH protocol were to be discovered, you can bet that the bad guys would immediately start to hammer on port 22 of every IP address on the Internet looking to take advantage, but if your server does this on a non-standard port it gives you that much more protection. Still, if you are connecting to a server that you do not control, you probably will connect to port 22, and chances are your client software is already configured to do that by default.
Les bases
Comme nous avons vu dans le dernier tutoriel, SSH utilise le modèle Client-Serveur. Bon, techniquement un serveur n'est que la machine à laquelle vous vous connectez et, en principe, ça pourrait être un autre ordinateur de bureau, un portable ou même un téléphone, s'il a les logiciels appropriés. Ainsi, le modèle en fait se résume à vous en tant que client et à l'autre machine en tant que serveur. Comme c'est le cas pour toutes les connexions Internet, des normes et des protocoles sont impliqués. Le Telnet d'origine communiquait sur TCP en utilisant le port 23. Puisque SSH fut conçu pour le remplacer, il utilisait les mêmes protocoles TCP et fut assigné au numéro de port adjacent, 22. C'est le standard, mais ce n'est pas gravé dans la pierre. En effet, une des façons d'améliorer la sécurité est d'utiliser un port non-standard. Pour ce faire, le serveur doit être configuré pour un port différent. Les serveurs surveillent les ports avec des démons ; ainsi, l'administrateur du serveur devrait configurer le démon pour qu'il écoute le port alternatif, comme le 16180, pour du trafic SSH, puis en informer les clients potentiels. C'est un bon truc à savoir si vous utilisez SSH pour vous connecter à un serveur distant dont vous êtes l'administrateur (par exemple, vous pourriez avoir un serveur co-implanté dans un centre de données ou un « Virtual Private Server » que vous contrôlez et administrez. Si une vulnérabilité dans le protocole était détectée, vous pouvez être certain que les méchants s'attaqueraient tout de suite au port 22 de chaque adresse IP sur le Net, cherchant à l'exploiter, mais si votre serveur le fait sur un port non-standard, votre protection se trouve nettement améliorée. Cela étant dit, si vous vous connectez à un serveur dont vous n'avez pas le contrôle, vous vous connecterez sans doute au port 22 et il est probable que le logiciel client soit déjà configuré pour ce faire par défaut.
7
How It Works To begin with, all SSH connections are initiated by the client. You, as the client, are going to the server and asking “Please, sir, may I have a shell connection?” And you will generally do this on port 22. The server will have a daemon listening to that port, and it should respond to your request. If you have the same account name on both your client and the server, you can just log in to the server. If they are different you should put in your account name. These examples assume you are using a terminal. Example one: ssh 192.168.1.24 Example two: ssh myserver.host.com Either of these would work if your account name is the same as on your local client. If they are different, you could speed things along by adding the account name: Example three: ssh phred@myserver.host.com The server should then send back to your client the protocol version, which should be SSH 2.0. If your client also supports SSH 2.0. the connection proceeds. Otherwise, the connection is dropped. All modern clients support SSH2.0, however. If you really want to dive into the details, you can start with RFC 4253, written by the previously mentioned Tatu Ylönen. If you want to see everything going on, use the -v switch with the ssh command to turn on verbose mode. This will show you all of the communication going on between your client and the server.
Comment cela fonctionne
Pour commencer, toutes les connexions SSH sont initialisées par le client. C'est vous, en tant que client, qui allez au serveur demander : « S'il vous plaît, monsieur, pourrais-je avoir une connexion shell ? » Et, en général, vous le ferez en utilisant le port 22. Sur le serveur, il y a un démon qui écoute ce port et c'est lui qui doit répondre à votre demande. Si vous avez le même nom de compte sur le client et le serveur, alors il vous suffit de vous connecter au serveur. Si le nom est différent, vous devez saisir votre nom de compte. Ces exemples supposent que vous utilisez un terminal.
Premier exemple : ssh 192.168.1.24
Deuxième exemple : ssh myserver.host.com
L'un ou l'autre fonctionnerait si votre nom de compte est le même que celui sur le client local. Si le nom est différent, vous pourriez faciliter les choses en ajoutant le nom de compte :
Troisième exemple : ssh phred@myserver.host.com
Le serveur devrait alors renvoyer au client la version du protocole, qui devrait être SSH 2.0. Si le client prend également en charge SSH 2.0, la connexion continue. Sinon, la connexion est terminée. Cependant, tous les clients modernes prennent en charge SSH 2.0. Si vous voulez vraiment approfondir les choses, vous pouvez commencer avec RFC 4253, écrit par Tatu Ylönen, mentionné ci-dessus. Si vous voulez voir tout ce qui se passe, utilisez le commutateur -v avec la commande ssh, pour activer le mode verbeux. Cela affichera toutes les communications entre votre client et le serveur.
8
Then the Binary Packet Protocol kicks in. This specifies each of the fields in the packet sent using SSH. If you need the full details on this, consult RFC 4253, but this is probably something you can skip if you are not going to be writing your own client. Next is the Server’s turn to identify itself, which it does by transmitting its public key. If this is your first time attempting to log in to this server, you will get something like this” The authenticity of host 'myserver.host.com' can't be established. RSA key fingerprint is d8:09:f4:42:…. Are you sure you want to continue connecting (yes/no)? Since this is the first time you have tried to connect, you don’t know for sure if this really is the server you want. This is where a man-in-the-middle attack could take place. If you were sitting in a coffee shop using the free wifi, for instance, someone could be at the next table intercepting the traffic and could respond with their own public key, thus hijacking your session. This should only happen the first time you connect with this particular machine, because the public key should be stored for future reference in what is called the “known_hosts” file. On a Linux machine, this is usually found at ~/.ssh/known_hosts. On Windows 7 generally you can find it at %USERPROFILE%\ssh or %USERPROFILE%\.ssh. But if you get a new laptop you have to go through this initial connection again with each of the sites you connect to.
Et après, le « Binary Packet Protocol » démarre. Il spécifie chacun des champs du paquet envoyé en utilisant SSH. Si vous voulez tous les détails, regardez RFC 4253, mais c'est sans doute quelque chose d'inutile si vous n'allez pas écrire votre propre client.
Puis c'est au tour du serveur de s'identifier en transmettant sa clé publique. Si c'est la première fois que vous essayez de vous connecter à ce serveur, vous verrez quelque chose comme ceci :
The authenticity of host 'myserver.host.com' can't be established. (Impossibilité d'établir l'authenticité du serveur hôte..)
RSA key fingerprint is d8:09:f4:42:…. (L'empreinte digitale de la clé RSA est …)
Are you sure you want to continue connecting (yes/no)? (Êtes-vous certain de vouloir continuer la connexion (oui/non) ?)
Puisque c'est la première fois que vous essayez de vous connecter, vous ne savez pas avec certitude que c'est vraiment le serveur que vous voulez. C'est ici que pourrait avoir lieu une attaque de l'homme-au-milieu. Par exemple, si vous étiez assis dans un café avec W ifi gratuit, quelqu'un à une autre table pourrait intercepter le trafic et répondre avec sa propre clé publique - autrement dit, il piraterait votre session. Cela ne devrait se passer que la première fois que vous vous connectez à cette machine précise, car la clé publique devrait être stockée à titre de référence ultérieure dans un fichier qui s'appelle « known_hosts » (hôtes connus). Sur une machine Linux, on la trouve généralement dans ~/.ssh/known_hosts. Sous Windows 7, il se trouve habituellement dans %USERPROFILE%\ssh ou %USERPROFILE%\.ssh. Mais si vous avez un nouvel ordinateur portable, vous devez passer par cette connexion initiale avec chacun des sites auxquels vous vous connectez.
9
This is definitely a weakness, so how can the server admins prevent this? Your login attempt got the fingerprint returned to you, so that is the key to this, if you will pardon the pun. You probably don’t want to post it publicly on an unsecured website, for instance, since the bad guys might figure out a way to spoof it. And email carries the same risk. In a corporate environment, you might post it on an encrypted website behind the firewall, and require the employee to use their credentials to access it. The next step depends on whether you are using SSH v.1 or SSH v.2. Since the vulnerability in SSH v.1 was found long ago in Internet time, you probably should question what is happening if you see it used today. SSH v.2 was adopted in 2006, which makes it comparatively old and stable. As Michael W. Lucas put it in his book SSH Mastery: “SSH-1 permits man-in-the-middle attacks and session hijacking, as discussed in Chapter 1. If someone insists on using SSH-1, practice saying “I told you so.” His book is excellent, and the e-book is only $10, and worth every cent. In particular, if you need to set up an SSH server, which I won’t really cover much of, this book is mandatory reading. Among the changes introduced by SSH v.2 are:
C'est, sans aucun doute, une faiblesse, alors comment les administrateurs serveurs peuvent-ils l'empêcher ? L'empreinte vous fut rendue lorsque vous avez essayé de vous connecter et c'est donc la clé du problème, si vous voulez bien excuser le double sens. Vous ne voudriez sans doute pas l'afficher publiquement sur un site Web non sécurisé, par exemple, puisque les méchants pourraient éventuellement trouver un moyen de la contrefaire. Et le courriel engendre les mêmes risques. Dans un environnement d'entreprise, vous pourriez peut-être l'afficher sur un site Web chiffré derrière un pare-feu et exiger que les employés utilisent leurs identifiants pour y accéder.
La prochaine étape diffère selon que vous utilisez SSH v.1 ou SSH v.2. Puisque la vulnérabilité dans SSH v.1 fut découverte il y a très longtemps (en temps Internet), vous devriez sans doute vous poser des questions sur ce qui se passe, si vous constatez qu'il est utilisé de nos jours. SSH v.2 fut adopté en 2006, ce qui fait qu'il est relativement ancien et stable. Comme Michael W. Lucas l'a dit dans son livre SSH Mastery : « SSH-1 permet des attaques du type homme-au-milieu et le piratage de sessions, comme présenté dans le premier chapitre. Si quelqu'un persiste à vouloir l'utiliser, vous pouvez vous entraîner à dire “Je vous l'avais bien dit.” ». Son livre est excellent ; la version électronique ne coûte que 10 $ et elle les vaut bien. En particulier, si vous avez besoin de créer un serveur SSH, ce dont je ne vais guère parler, lire ce livre est obligatoire. Parmi les modifications introduites par SSH v.2, il y a :
10
• improved encryption standards, including 3DES and AES • Public key certification for clients (we will discuss later on) • The use of sound cryptographic Message Authentication Code (MAC) algorithms for integrity checking • SSH v.1 was monolithic, meaning that all of the protocols needed for encryption, authentications, etc. were part of a single large protocol built into SSH v.1 in SSH v.2 each protocol is split out into its own and defined in a separate RFC such as •• Transport Layer Protocol •• Connection Protocol •• Authentication Protocol I don’t want to take the time to dig into how SSH v.1 works, and there are a few differences, so I will focus on only SSH v.2 here. Once you have accepted the Public Key of the server, it is up to you as the client to respond. You do this by first generating a symmetric key (called the session key) which will be used to encrypt all traffic. Remember from our previous tutorials that Asymmetric key pairs carry a very large computational overhead, so they are generally used only to set up a connection and exchange the symmetric key. The client creates this key, then using Diffie-Hellman-SHA1 key exchange sends it back to the server. NOTE: There is a provision in the protocol for a Certificate Authority to attest to the validity of the public keys used. This would help immensely in preventing the man-in-the-middle attack you are vulnerable to at your first connection since the CA would give you confidence in the validity of the server’s public key. But not all servers use this at present, in part because Certificates are expensive. We are not done yet. You should only have access to the server in accord with the rights you were given when your account was created. This means it is time to authenticate. And that is the topic for our next tutorial. Encart auteur Kevin is a geek, Linux enthusiast, a certified Project Manager by day, and in general a tech lover. His blog is at: http://www.zwilnik.com
• Des normes de chiffrement améliorées, y compris 3DES et AES. • La certification de clés publiques pour les clients (je vais en parler plus tard). • L'utilisation d'algorithmes cryptographiques « Message Authentication Code (MAC) » solides pour vérifier l'intégrité. • SSH v.1 était monolithique, ce qui veut dire que tous les protocoles nécessaires pour le chiffrement, l'authentification, etc. faisaient partie d'un seul grand protocole incorporé dans SSH v.1. Dans SSH v.2 chaque protocole est distinct et défini dans un RFC séparé, tels que : •• Transport Layer Protocol (Le protocole de couche de transport). •• Connection Protocol (Le protocole de connexion). •• Authentication Protocol (Le protocole d'authentification).
Je ne veux pas prendre le temps d'examiner le fonctionnement de SSH v.1, et, puisqu'il y quelques différences, je vais me concentrer ici sur SSH v.2 uniquement.
Une vois que vous aurez accepté la clé publique du serveur, c'est à vous, le client de répondre. Vous le faites d'abord en générant une clé symétrique (appelé la clé de la session) qui servira à chiffrer tout le trafic. Souvenez-vous des tutoriels précédents, que des paires de clé asymétriques entraînent de très grands calculs supplémentaires et ne sont donc utilisées habituellement que pour configurer une connexion et échanger la clé symétrique. Le client crée cette clé, puis, en utilisant l'échange de clé Diffie-Hellman-SHA1 la renvoie au serveur.
NOTA : Le protocole contient une disposition pour l'attestation de la validité des clés publiques utilisées par une Autorité de certification. Cela aiderait énormément à empêcher une attaque homme-au-milieu à laquelle vous êtes vulnérables lors de votre première connexion, puisque la CA vous inspirerait confiance dans la validité de la clé publique du serveur. Mais, actuellement, tous les serveurs ne l'utilisent pas, en partie parce que les certificats sont chers.
Nous n'avons pas encore terminé. Maintenant, vous devriez seulement pouvoir accéder au serveur compte tenu des droits qui vous furent donnés quand le compté fut créé. Le moment de l'authentification est venu. Et ce sera le sujet du prochain tutoriel.
Encart auteur
Kevin est un geek, un passionné de Linux, un « Project Manager » (gestionnaire de projets) certifié, dans la journée, et, à tout moment, un grand amateur de technologie. Son blog est ici : http://www.zwilnik.com