Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== 1 ======

**The ssh command has a number of options, and I don’t plan to cover all of them. Even the SSH documentation warns against the use of some of them, suggesting they are only for real experts. But I want to mention the ones that I think you will find important. These options take the form of switches in the command:

-1 : Forces the connection to use SSH v.1 protocol only. The question here is why would you want to do that if you have SSH v.2 available. It is a real improvement, after all.
-2 : Forces the connection to use SSH v.2 protocol only.
-4 : Forces ssh to use IPv4 addresses only.
-6 : Forces ssh to use IPv6 addresses only.
-b : Bind address. Useful for machines that have two IP addresses, such as systems with two NICs. This tells SSH which IP address on the local machine to use for the connection.
-L : Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address.
-p : Port to connect to on the remote host. This can be specified on a per-host basis in the configuration file.
-R : Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to port on the remote side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the local machine.
-v : Verbose mode. This shows all commands and replies, and is useful for debugging.
-W : Requests that standard input and output on the client be forwarded to host on port over the secure channel. Works with v.2 only.
-X : Enables X11 forwarding. But note that this can open a vulnerability.**

La commande ssh possède pas mal d'options et je ne prévois pas de les traiter toutes. Même la documentation SSH avertit contre l'utilisation de certaines, suggérant qu'elles sont réservées aux vrais experts. Mais je tiens à mentionner celles que vous trouverez importantes selon moi. Ces options prennent la forme de commutateurs à la commande :

-1 : Force la connexion à utiliser seulement le protocole SSH v.1. La question ici est pourquoi voudriez-vous faire cela si vous avez SSH v.2 disponible ? Cette dernière est une réelle amélioration, après tout.
-2 : Force la connexion à utiliser seulement le protocole SSH v.2.
-4 : Force ssh à utiliser seulement des adresses IPv4.
-6 : Force ssh à utiliser seulement des adresses IPv6.
-b : Adresse de liaison. Utile pour les machines qui ont deux adresses IP, deux cartes réseau. Indique à SSH quelle adresse IP utiliser sur la machine locale pour la connexion.
-L : Indique que le port donné sur l'hôte local (client) doit être translaté sur l'hôte et le port spécifiés de l'autre côté. Cela fonctionne par l'attribution d'un « socket » pour écouter sur le port du côté local, éventuellement lié à l'adresse de liaison spécifiée.
-p : Port sur lequel se connecter à l'hôte distant. Cela peut être spécifié selon l'hôte dans le fichier de configuration.
-R : Indique que le port donné sur l'hôte distant (serveur) doit être transféré sur l'hôte et le port spécifiés du côté local. Cela fonctionne par l'attribution d'un « socket » pour écouter sur le port du côté opposé, et chaque fois qu'une connexion est faite sur ce port, la connexion est transmise sur le canal sécurisé et une connexion est établie sur l'hôte et le port depuis la machine locale.
-v : Mode verbeux. Affiche toutes les commandes et les réponses ; utile pour le débogage.
-W : Demande que l'entrée et la sortie standard sur le client soient transmises à l'hôte sur le port via le canal sécurisé. Fonctionne en v.2 seulement.
-X : Permet la translation X11. Mais notez que cela peut ouvrir une vulnérabilité.

====== 2 ======

**Port Forwarding

One of the handy things you can do, and something useful for tunneling. is port forwarding over SSH. The basic idea is to connect via ssh to a remote machine, and ask it to send something to a specific port other than the default port. The basic way you do this is to use the SSH command with the appropriate flags, -L and -R, which, not surprisingly, stand for Local and Remote. You need to specify the port you want to use, and what will be forwarded to it.
• Local Port Forwarding – This takes a port on your local machine and forwards it to a specified port on the server. So you can make a request on a local port like 7280 on address 127.0.0.1, and your SSH client would intercept that call and send it to port 119 on the server. Then you would have a secure connection to get whatever port 119 is configured to serve (typically Usenet traffic, but this is just an example). So you use this to configure your newsgroup client to securely grab messages from a public server, assuming it allows SSH connections.
• Remote Port Forwarding – This is the reverse of Local Port Forwarding. Here, the idea is to specify a port on the remote server and have it forwarded to your local server. This is not very common, and you may never need to do this. Essentially, all traffic coming in to the server on the specified port would then be forwarded to your local machine.
• Dynamic Port Forwarding – This creates a SOCKS proxy and is not restricted to one port or one type of traffic.**

Translation de port

Une des choses pratiques que vous pouvez faire, et quelque chose d'utile pour le « tunneling », est le transfert de port sur SSH. L'idée de base est de se connecter via ssh sur une machine distante et lui demander d'envoyer quelque chose sur un port spécifique autre que le port par défaut. La méthode de base pour faire cela est d'utiliser la commande SSH avec les indicateurs appropriés, -L et -R, qui, sans surprise, signifient Local et Remote ([Ndt : distant]). Vous devez spécifier le port que vous souhaitez utiliser, et ce qui lui sera translaté.
• Translation de port local - Ceci prend un port sur votre machine locale et le transfère vers un port spécifié sur le serveur. Ainsi, vous pouvez faire une requête sur un port local comme 7280 sur l'adresse 127.0.0.1, et votre client SSH interceptera cet appel et l'enverra au port 119 sur le serveur. Ensuite, vous aurez une connexion sécurisée pour obtenir ce que le port 119 est configuré pour envoyer (généralement le trafic Usenet, mais cela est juste un exemple). Donc, vous pouvez utiliser ceci pour configurer votre client de « newsgroup » afin qu'il récupère en toute sécurité des messages à partir d'un serveur public, en supposant qu'il permette les connexions SSH.
• Translation de port distant - Ceci est l'inverse de la section précédente. Ici, l'idée est de spécifier un port sur le serveur distant et qu'il soit transféré vers votre serveur local. Ce n'est pas très fréquent, et vous n'en aurez peut-être jamais besoin. Essentiellement, tout le trafic entrant sur le port spécifié du serveur sera ensuite transmis à votre machine locale.
• Translation de port dynamique - Ceci crée un proxy SOCKS et ne se limite pas à un port ou un type de trafic.

====== 3 ======

**Local Port Forwarding

Suppose you are at work (or school), and you just cannot bear to miss out on your Facebook stream. But there’s a filter stopping you from accessing the site. However, for the sake of argument, you could create an SSH connection to a server outside the network (which could be your computer at home). You could then do something clever using Local Port Forwarding. Create a connection as follows:

ssh -L 7280:facebook.com:80 address of home machine

Now, your home machine does need to have a public IP address, or you would need to set up your router to forward the traffic, for this to get through.

Once you have done this, you would open your browser and set it to go to http://localhost:7280, and traffic would then flow to your home machine, and from there to Facebook. You can now browse to your heart’s content on your Facebook stream. Of course, this also illustrates why network admins might want to shut down SSH traffic, which they might do by blocking any outbound traffic going to port 22 (the default SSH port). And you could then try changing the default port on your home SSH server to something other than port 22, and then the admins could do deep packet inspection, and so on.

But SSH Port Forwarding is not just a matter of a security breach in the making, it can be used very legitimately in a number of situations. For example, you have a company with a number of geographically dispersed locations. In that case, SSH Port Forwarding would be a very useful way to connect sites to exchange data. You might have a database server that employees might need to connect to, and don’t want that traffic flowing through the Internet unsecured. Or perhaps you have set up a server for yourself, such as OwnCloud, and it is in a remote hosting center. Creating an SSH connection and using Port Forwarding might make your data a lot more secure.**

Translation de port local

Supposons que vous êtes au travail (ou à l'école) et que vous ne pouvez pas supporter d'être privé de votre page Facebook. Mais il y a un filtre qui vous empêche d'accéder au site. Alors, pour les besoins du raisonnement, vous pouvez créer une connexion SSH à un serveur en dehors du réseau (par exemple votre ordinateur à la maison). Vous pouvez ensuite faire quelque chose d'intelligent avec la translation de port local. Créer une connexion comme suit :

ssh -L 7280:facebook.com:80 adresse_de_la_machine_à_la_maison

Attention, votre machine à domicile doit avoir une adresse IP publique, ou vous aurez besoin de configurer votre routeur pour rediriger le trafic, pour que ceci arrive à bon port.

Une fois cela fait, vous ouvrez votre navigateur et le réglez pour aller sur http://localhost:7280, et le trafic circulera alors vers votre machine à la maison et, de là, vers Facebook. Vous pouvez maintenant parcourir votre page Facebook comme bon vous semble. Bien sûr, cela illustre aussi pourquoi les administrateurs réseau peuvent vouloir arrêter le trafic SSH, ce qu'ils pourraient faire en bloquant tout trafic sortant vers le port 22 (le port SSH par défaut). Et vous pourriez alors essayer de changer le port par défaut sur votre serveur SSH maison en quelque chose d'autre que le port 22, et alors les admins pourraient inspecter en détail les paquets, et ainsi de suite.

Mais le transfort de port SSH n'est pas qu'une question de contournement de la sécurité, elle peut être utilisée très légitimement dans un certain nombre de situations. Par exemple, vous avez une entreprise avec un certain nombre de sites géographiquement dispersés. Dans ce cas, la translation de port SSH serait un moyen très utile pour connecter des sites et échanger des données. Vous pourriez avoir un serveur de base de données sur lequel les employés pourraient avoir besoin de se connecter, et ne pas vouloir que le trafic circule sur l'Internet non sécurisé. Ou vous avez peut-être mis en place un serveur pour vous-même, comme OwnCloud, situé dans un centre d'hébergement distant. La création d'une connexion SSH utilisant la translation de port pourrait sécuriser grandement vos données.

====== 4 ======

**Limitations

There are a few things you need to watch out for. One is that not all ports may be available to you. If you are in a Unix-like environment, for instance, port 1024 and all ports below that can only be used by root. But any port above 1024 should be usable by a user with normal privileges as long as no one else is already using it.

The other thing you need to remember is that if the connection is dropped the port forwarding is gone. And, in general, TCP connections are configured to close after a period of inactivity, and on some firewalls that can be as little as 300 seconds (5 minutes). This can be controlled by a rule (or perhaps more than one) in your iptables, or directly by /proc/sys/net/ipv4/tcp_keepalive_time. But, if you want a persistent connection, you need to use a Keep Alive.**

Limites

Il faut quand même faire attention à certaines choses. La première est que tous les ports ne sont peut-être pas disponibles pour vous. Si vous êtes dans un environnement Unix, par exemple, le port 1024 et tous les ports en-dessous ne peuvent être utilisés que par l'utilisateur root. Mais tout port au-dessus de 1024 devrait être utilisable par un utilisateur avec des privilèges normaux tant que personne d'autre ne l'utilise déjà.

L'autre chose que vous devez retenir est que, si la connexion est interrompue, la redirection de port disparaît. Et, en général, les connexions TCP sont configurées pour se fermer après une période d'inactivité et, sur certains pare-feux, cela peut être au bout de seulement 300 secondes (5 minutes). Ceci peut être contrôlé par une règle (ou peut-être plus d'une) dans vos iptables ou directement par /proc/sys/net/ipv4/tcp_keepalive_time. Mais, si vous voulez une connexion persistante, vous devrez utiliser un « Keep Alive ».

====== 5 ======

**Keep Alives

There are two, basically. One is the TCP Keep Alive, which is simple but spoofable, and the other is the SSH keepalive, also called serveralive. Serveralive messages travel through the encrypted connection between you and the server, and thus cannot be spoofed. Assuming security is your reason for creating SSH connections, then it would be more secure to use serveralive messages, though I expect using TCP keepalives is far from the worst thing that could happen. In Linux, you can set this up either for everyone (if you have root privileges), or just for yourself, by editing the appropriate config file.

For everyone – edit /etc/ssh/ssh_config and insert:
Host *
ServerAliveInterval 300
ServerAliveCountMax 2**

Keep Alives

Il y a en a deux principaux. L'un est le TCP Keep Alive ([Ndt : garder vivant]), qui est simple, mais qui peut être usurpé, et l'autre est SSH keepalive, aussi appelé serveralive. Les messages serveralive voyagent à travers la connexion cryptée entre vous et le serveur, et ne peuvent donc pas être falsifiés. En supposant que la sécurité est la raison de l'utilisation de connexions SSH, alors il serait plus sûr d'utiliser des messages serveralive, même si je pense qu'utiliser des keepalives TCP est loin d'être la pire chose qui pourrait arriver. Sous Linux, vous pouvez régler cela soit pour tout le monde (si vous avez les privilèges root), soit tout simplement pour vous-même, en éditant le fichier de configuration approprié.

Pour tout le monde, modifiez /etc/ssh/ssh_config et insérez :
Host *
ServerAliveInterval 300
ServerAliveCountMax 2

====== 6 ======

**For just you, edit ~/.ssh/config, and add the above code to it.

ServerAliveInterval, specifies how often a null packet should be sent to the server to keep the connection alive. However, sometimes the server may go off or drop the connection, so the second line specifies how many times you should send a packet without getting a response. The setting I have shown will send a packet, and if no response is received, it will send a second packet 300 seconds later. If no response is received to the second consecutive packet the connection will be dropped by your client.

On Windows,  using PuTTY, there is a good explanation at http://blog.hazaveh.net/2013/10/keep-ssh-session-alive-in-putty/, but essentially you go to Connection, and then on the right under Sending of null packets to keep session active, you can set Seconds between keepalives (0 to turn off) to 300 seconds to get a similar result.

Once you understand Port Forwarding and Keepalives, you are most of the way to tunneling.**

Pour vous seulement, éditez ~/.ssh/config en y ajoutant le code ci-dessus.

ServerAliveInterval spécifie combien de fois un paquet vide doit être envoyé au serveur pour maintenir la connexion. Cependant, parfois, le serveur peut être coupé ou abandonner la connexion, de sorte que la deuxième ligne spécifie combien de fois vous devez envoyer un paquet sans obtenir une réponse. Le réglage que j'ai montré enverra un paquet et, si aucune réponse n'est reçue, il enverra un deuxième paquet 300 secondes plus tard. Si aucune réponse n'est reçue au deuxième paquet consécutif, la connexion sera abandonnée par votre client.

Sous Windows, en utilisant PuTTY, il y a une bonne explication sur http://blog.hazaveh.net/2013/10/keep-ssh-session-alive-in-putty/, mais essentiellement, vous allez dans Connexion, puis sur la droite sous Envoi de paquets vides pour garder la session active, vous pouvez régler les secondes entre les keepalives (0 pour désactiver) à 300 secondes pour obtenir un résultat similaire.

Une fois que vous comprenez la translation de port et les Keepalives, vous êtes presque arrivé au « tunneling ».