SSH : telnet sécurisé et bien plus encore

23 avril 2006

Télécharger en PDF


SSH (Secure Shell) est une application réseau utilisée pour les connexions distantes sécurisées. En effet, ssh permet non seulement une connexion distante mais permet également le transfert de fichier et la redirection de ports cryptée. Nous allons ici nous intéresser à la version libre de SSH : OpenSSH (www.openssh.org). SSH utilise le port 22/tcp. Il est basé sur un principe de clef public et privé.

Tux


Sommaire

I.Fonctionnement 2

a)Types de clés 2

b)Protocoles SSH version 1 et SSH version 2 2

c)Etapes de connexion 3

d)Types d'authentification 5

e)Algorithmes cryptographiques utilisables 9

f)Etapes d'une connexion après une authentification réussie 9

II.Installation 9

III.Fichier de ssh et sshd 10

IV.Configuration 10

a)Serveur SSH 10

b)Client SSH 11

c)Port forwarding et authentification d'hôte 12

V.Utilisation 13

d)Connexion à la telnet : commande ssh 13

e)Copie de fichiers ponctuellement : commande scp 13

f)FTP sécurisé de SSH : commande sftp 13

g)SSH et les tubes 14

1Principe 14

2Exemple : sauvegarde de données 14

3Exemple : restauration de données 14

h)Montage de partition par SSH 15

1FUSE 15

2SSHFS 15

VI.Configuration d'une authentification par clés 15

a)Génération d'une paire de clés pour l'authentification 15

b)Configuration sur la machine distante 16

c)Connexion et authentification 17

d)Simplification des connexions multiples 17

VII.Telnet et co 17

VIII.Tunnels SSH 18

a)Principe de fonctionnement 18

Redirection locale de port 18

Redirection distante de port 19

IX.Redirection X11 19

a)Configuration du serveur 20

b)Configuration du client 20

c)Fonctionnement 20

d)Utilisation 22

e)Mode Untrusted et Trusted 22

X.Et pour Windows...ben oui ça existe... 23

Bibliographie 23



I.Fonctionnement


SSH se sert de chiffrement à clé publique pour l'authentification et de chiffrement à clé privée pour la communication : c'est le principe des clés de session.


a)Types de clés


SSH utilise plusieurs types de clés :


En plus de ces clés, SSH permet de crypter avec un algorithme symétrique toutes les paires de clés afin de les protéger. Pour cela, il demande une passphrase et crypte la clé privée avec.


b)Protocoles SSH version 1 et SSH version 2



Il existe deux versions, bien évidemment incompatibles, du protocole SSH : les versions 1.x (1.3 et 1.5), et la version 2.0. Tant que le serveur et le client supportent la même version du protocole, l'utilisateur ne s'aperçoit de rien.

Dans la version 1, le protocole est défini en une seul et unique couche, tandis que dans SSH version 2, on distingue en trois « couches » (dans le même esprit que la division de la couche Liaison de la pile TCP/IP):

  1. SSH Transport Layer Protocol (SSH-TRANS) : elle prend en charge l'intégrité des données transitant par le canal, le chiffrement de celles-ci et leur éventuelle compression et enfin l'authentification des machines entre elles.

  2. SSH Authentication Protocol (SSH-AUTH) : elle prend en charge ... l'authentification (mot de passe, par hôte, clés publiques et autres)

  3. SSH Connection Protocol (SSH-CONN) : elle assure la gestion du tunnel (shell, agent SSH, redirection de ports, contrôle de flux).

On trouvera tous les détails normalisés à l'adresse (et possiblement immangeables) : http://www.ietf.org/html.charters/secsh-charter.html



Les différences techniques essentielles entre les versions 1 et 2 sont :

SSH version 1

SSH version 2

conception en une seule couche

séparation des couches authentification, connexion et transport

Intégrité des données via CRC32 (peu fiable)

intégrité via HMAC (hash cryptographique)

un UNIQUE canal par session

nombre indéterminé de canaux par session

négociation du seul chiffrement symétrique du tunnel et de la clé de session UNIQUE pour les deux sens de communication du canal

négociations plus détaillées (chiffrement symétrique, clé-publiques, compression, ...) et une clé de session par sens de communication ainsi que le choix de la compression et de l'intégrité aussi par sens

RSA seulement pour l'algorithme à clés-publiques

RSA et DSA pour l'algorithme à clés-publiques

clé de session transmise par le client

clés de session négociées avec un protocole Diffie-Hellman

clé de session valable pour toute la session

clés de session renouvelées


A partir de maintenant je considérerai principalement la version 2 du protocole SSH.


c)Etapes de connexion


Une connexion SSH se fait en plusieurs étapes :




A partir de cette étape, les communications sont cryptées dans les deux sens.






d)Types d'authentification



Il existe principalement quatre types d'authentification pour SSH :













On peut autoriser un ou plusieurs de ces types d'authentification. Sshd essayera en priorité le type le plus sûr et si le client ne veut pas de ce type d'authentification, il descendra le niveau de sécurité vers une autre méthode d'authentification.

Lorsque la clé publique du serveur n'est pas connue, le client demande à l'utilisateur s'il est sûr de vouloir se connecter au serveur. Si l'option StrictHostKeyChecking yes est indiquée dans le fichier ssh_config, alors si la clé n'est pas présente ou différente dans l'un des fichiers known_hosts du client, celui-ci se voit refuser la connexion.

Lorsque l'authentification réussi, la clé publique du serveur auquel on se retrouve connecté est ajoutée au fichier .ssh/known_hosts. Si la clé du serveur a changé à la prochaine connexion, il faudra supprimer la clé du serveur pour pouvoir tenter de se connecter au serveur. Cela permet d'être averti que la clé du serveur a changé : cela peut venir d'un formattage, d'un changement de serveur ou d'un pirate « man-in-the-middle » où une autre personne cherche à se faire passer pour le serveur.



Les types d'authentification autorisés se règlent dans le fichier /etc/ssh/sshd_config par les directives (détaillées plus bas) :

e)Algorithmes cryptographiques utilisables



SSH supporte les algorithmes de cryptographie suivants :



f)Etapes d'une connexion après une authentification réussie

Lorsqu'un utilisateur se connecte avec succès, sshd procède comme suit :

II.Installation



Vérifier d'abord que ssh est bien installé sur votre systeme, le client ainsi que le serveur, ssh nécessite ssl (openssl).

[root]# rpm -q openssl openssh

Pour pouvoir se connecter en ssh depuis une machine extérieur sur son ordinateur, il faut :

[root]# yum install openssh-server

[root]# service sshd start

[user]$ ssh hôte.domaine



III.Fichier de ssh et sshd

Ssh et sshd utilisent les fichiers suivants :



Les fichiers de clés privées doivent avoir les droits 600 sinon sshd ne démarre pas.

IV.Configuration


Les différents fichiers de configuration se trouvent dans /etc/ssh/, voici les différents paramètres de configuration possibles pour le serveur ainsi que pour le client (sshd_config et ssh_config) :

a)Serveur SSH



Option

Description

AllowGroups liste

Suivi de la liste des groupes autorisés à se connecter au serveur (peut contenir * ou ?)

AllowUsers liste

Suivi de la liste des utilisateurs autorisés à se connecter au serveur (peut contenir * ou ?)

AuthorizedKeysFile path_filename

Chemin et nom de fichier absolu ou relatif au dossier de l'utilisateur, qui contient la liste des clés publiques recevables pour une identification par challenge ou clé publique

ClientAliveInterval number

Nombre de secondes d'inactivité avant test de réponse du client

DenyGroups liste

Suivi de la liste des groupes interdits de se connecter au serveur (peut contenir * ou ?)

DenyUsers liste

Suivi de la liste des utilisateurs interdits de se connecter au serveur (peut contenir * ou ?)

GatewayPorts port_number

Indique si les ports forwardés par le clients sur le serveur sont visible de l'extérieur du serveur (yes) ou non (no).

HostKey path_filename

Indique le chemin de la clé privée du serveur

IgnoreUserKnownHosts yes|no

Indique au serveur sshd de na pas tenir compte des fichiers de machines connus dans les répertoires des utilisateurs.

ListenAddress IP

Adresse sur laquelle le serveur écoute

LoginGraceTime number

Délai en secondes pour l'authentification

PermitRootLogin yes|no

Indique si root peut se connecter en ssh sur le serveur (yes ou no)

Port port_number

Spécifie le port d'écoute pour les connexions SSH au serveur

Subsystem subsys_name commandline

Met en place un sous système hébergé par sshd (par ex : sftp)

UsePrivilegeSeparation yes|no

Indique si sshd diminue ses privilèges à ceux de l'utilisateur connecté (yes) ou reste root (no)

UsePAM yes|no

Permet d'utiliser PAM pour l'authentification. Dans ce cas, il faut choisier entre PasswordAuthentication et ChallengeResponseAuthentication

Authentification

PasswordAuthentication yes|no

Indique si l'authentification par mot de passe est autorisé

HostbasedAuthentication yes|no

Indique si l'authentification par hôte est autorisée

PubkeyAuthentication/RSAAuthentication yes|no

Indique si l'authentification par clés publique est autorisée

ChallengeResponseAuthentication yes|no

Indique si l'authentification par challenge est autorisée



b)Client SSH



Option

Description

Host nom_machine

Indique que toutes les autres options qui se trouvent en dessous de ce tag sont relatifs à nom_machine (jusqu'à la fin ou au prochain Host). nom_machine peut comprendre * et ? pour donner un pattern.

GatewayPorts yes ou no ou IP_locale

Autorise les autres machines à se connecter à tous les ports forwardés.

HostName nom_machine

Nom de la machine à laquelle on veut se connecter.

LocalForward port_connexion_locale serveur_distant:port_serveur_distant

Une fois la connexion SSH mise en place, on pourra se connecter à localhost:port_connexion_locale ce qui représente en fait une connexion à serveur_distant:port_serveur_distant par le canal sécurisé.

RemoteForward port_serveur_local serveur_local:port_connexion_distante

Une fois la connexion SSH mise en place, une personne, ayant accès au serveur auquel vous êtes connecté, pourra se connecter à localhost:port_connexion_distante ce qui représentera en fait une connexion à port_serveur_local:serveur_local

NumberOfPasswordPrompts number

Nombre de fois que l'on autorise une erreur d'authentification à la connexion avant de stopper la connexion.

Port port

Indique le port de connexion sur la machine distante

StrictHostKeyChecking yes ou no

Refuse ou pas la connexion à des machines dont la clé a changé depuis la dernière connexion.

User username

Indique le nom de l'utilisateur sur la machine distante.



c)Port forwarding et authentification d'hôte



Si vous êtes amené à vous connecter à la fois sur une passerelle et sur une machine se trouvant derrière la passerelle (celle-ci faisant un port forwarding entre, par exemple, son port 2222 et le port 22 de la machine interne), vous allez rencontrer un problème. En effet, la première fois que vous vous connecter en SSH à une machine, votre client SSH associe (de façon cryptée) son IP avec la clé publique d'hôte de la machine contactée mais pas avec le numéro de port (dans le fichier ~/.ssh/known_hosts). Lorsque vous allez vous connecter, à la machine interne par le port 2222 de la passerelle (ssh -p 2222 passerelle), le client SSH va enregistrer l'IP de la passerelle associée avec la clé d'hôte de la machine interne. Si vous vous connecter ensuite directement à la passerelle sur son port 22, vous allez obtenir un message d'erreur vous disant que la clé d'hôte a changée et vous ne pourrait pas vous connecter.



Il faudra donc mettre la configuration suivante dans votre fichier ~/.ssh/config :

Host passerelle

Hostname nom_DNS_passerelle

CheckHostIP no

Port 22

HostKeyAlias passerelle



Host machine_interne

Hostname nom_DNS_passerelle

CheckHostIP no

Port 2222

HostKeyAlias machine_interne



Ensuite, il vous suffira de taper ssh passerelle ou ssh machine_interne pour vous connecter à la bonne machine.

CheckHostIP no permet de ne pas vérifier l'IP de la machine à laquelle on se connecte. Utile si la passerelle a une IP dynamique.

HostKeyAlias permet de donner un nom à la clé afin qu'elle soit associée à ce nom et non à l'IP de la machine distante.

V.Utilisation

d)Connexion à la telnet : commande ssh


Pour se connecter, il suffit de taper :

[user]$ ssh utilisateur@hôte

On peut aussi utiliser l'option -l pour spécifier le nom d'utilisateur distant.

Les options -v, -vv et -vvv permettent, en cas d'erreur par exemple, de voir ce que fait ssh pendant la connexion.

e)Copie de fichiers ponctuellement : commande scp



Pour copier un fichier se trouvant sur une machine accessible en ssh :

[user]$ scp user@serveur:fichier_source fichier_destination



Les options suivantes peuvent être utiles :



f)FTP sécurisé de SSH : commande sftp



Note : SFTP n'est pas une version de FTP sécurisée à travers SSH mais bien un protocole à part entière qui reprend une grande partie des commandes FTP.


Il existe aussi un « mode ftp » sftp. Elle a les mêmes commande que la commande ftp.

[user]$ sftp serveur

sftp> ls

sftp> bye

Il existe des clients SFTP graphiques comme lftp ou krusader.



g)SSH et les tubes

1Principe

On peut se servir de SSH pour exécuter une commande à distance en lui passant un contenu local sur son STDIN distant et récupérer le résultat de la commande localement :

[user]$ ssh utilisateur@machine_distante « commande » < fichier_stdin > fichier_stdout

ou

[user]$ commande | ssh utilisateur@machine_distante « commande » | commande

ou n'importe quelle autre combinaison de > , < ou |



2Exemple : sauvegarde de données



On peut par exemple faire une sauvegarde distante :

[user]$ ssh utilisateur@machine_distante « tar czf - dossier_distant » > sauvegarde.tar.gz

ou locale :

[user]$ tar czf - dossier_local | ssh utilisateur@machine_distante « cat sauvegarde.tar.gz »



Le - dans la commande tar sert à lui dire d'envoyer le contenu gzippé sur stdout au lieu de la mettre dans un fichier.



3Exemple : restauration de données



On peut par exemple faire une restauration distante :

[user]$ ssh utilisateur@machine_distante « tar xzf » < sauvegarde.tar.gz

ou locale :

[user]$ ssh utilisateur@machine_distante « cat sauvegarde.tar.gz » | tar xzf



h)Montage de partition par SSH



1FUSE



FUSE est un projet permettant de développer des modules de systèmes de fichiers dans la ring 3 (utilisateur) et non dans le ring 0 (noyau). Cela permet notament d'éviter les kernels panics lors du dysfonctionnement d'un module.

Pour installer ce module, reporter vous à la page d'installation du site du projet : http://fuse.sourceforge.net.

Pour pouvoir monter et démonter des partitions avec FUSE vous devez vous ajouter dans le groupe fuse. (en root, éditer le fichier /etc/group et ajouter vous à la fin de la ligne commençant par fuse).

2SSHFS

SSHFS vous permet de monter des dossiers distants au travers d'un canal SSH.

Pour l'installer, reportez vous à la page suivante : http://fuse.sourceforge.net/sshfs.html



Pour monter un dossier distant :

[user]$ mkdir point_montage

[user]$ sshfs utilisateur@machine_distante:/chemin/dossier point_montage



Pour démonter :

[user]$ fusermount -u machine_distante



VI.Configuration d'une authentification par clés


Vous avez pu constater que ssh utilise toujours le mot de passe comme identification. Or cette méthode n'est pas très sécurisée. Il existe un autre mode de fonctionnement utilisant des clés publics et privés. Pour générer une paire de clés utilisez la commande ssh-keygen -t dsa. Cette commande vous demande une passphrase qui se doit d'être une phrase relativement longue. Une fois cette commande tapée vous avez deux clés de générées dans le répertoire .ssh/.



a)Génération d'une paire de clés pour l'authentification



Génération d'une paire de clés Privées/Publics :

[utilisateur votre_machine]$ ssh-keygen -t dsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/utilisateur/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): votre_passphrase
Enter same passphrase again: encore_votre_passphrase
Your identification has been saved in /home/utilisateur/.ssh/id_rsa.
Your public key has been saved in /home/utilisateur/.ssh/id_rsa.pub.
The key fingerprint is:
25:d1:ff:34:da:ef:2b:ed:9e:95:04:bc:56:81:2a:3c utisateur@votre_machine



Pendant la génération de la paire de clé et afin de protéger (encrypter) la clé privée, une passphrase vous sera demandée. Elle sert en quelque sorte de mot de passe. Elle doit être une vraie phrase donc relativement longue. Attention, vous ne voyez pas ce que vous tapez, donc faites bien attention.

b)Configuration sur la machine distante



Dans les deux cas suivant, ce sera bien sûr le mot de passe qui vous sera demmandé et pas la passphrase de la clé que vous copiez.

Il existe deux méthodes pour transférer sa clé publique dans son répertoire distant :



La clé public est dans le fichier ~/.ssh/id_dsa.pub et la clé privée dans ~/.ssh/id_dsa. Cette dernière doit normalement avoir les droits 0600 (lecture et écriture pour vous seulement).

Il suffit alors d'envoyer la clé public dans votre répertoire de connexion sur le serveur distant, puis d'exécuter la commande suivante :

[user]$ cat id_dsa.pub >> ~/.ssh/authorized_keys.



Dans le fichier authorized_keys, en début de chaque ligne, vous pouvez ajouter une ou plusieurs des options suivantes :

options

Définition

from="liste"

Liste de machines depuis lesquelles on est autorisé à se connecter, séparées par des virgules

command="commande"

Commande à exécuter à la connexion

no-port-forwarding

Interdit le Port Forwarding. Voir plus bas.

no-X11-forwarding

Interdit la redirection X11 (pas de connexion en graphique possible)

permitopen="host:port"

Limite le forwarding le Port Forwarding vers/depuis host:port. On peut en mettre plusieurs permitopen en les séparant par des virgules.



c)Connexion et authentification



Maintenant lorsque vous vous connectez sur la machine distante sur votre compte, vous n'avez plus besoin de rentrer votre mot de passe mais la passphrase que vous a demandé ssh-keygen.

Le contenu du fichier /etc/motd peut être affiché et la date et ehure de votre connexion loggé.

d)Simplification des connexions multiples


Toutefois, cette méthode nécessite de retaper à chaque fois votre passphrase ce qui peut être fastidieux si vous utilisez plusieurs connexions. Pour remédier à ce problème il existe un utilitaire ssh-agent qui peut s'occuper de l'authentification.

[utilisateur@machine dossier]$ ssh-agent $SHELL
[utilisateur@machine dossier]$ ssh-add
Enter passphrase for /home/utilisateur/.ssh/id_dsa:
Identity added: /home/utilisateur/.ssh/id_dsa (/home/utilisateur/.ssh/id_dsa)
[utilisateur@machine dossier]$ ssh-add -l
1024 61:42:00:98:0c:9b:4a:76:90:18:34:ef:09:12:45:fd /home/utilisateur/.ssh/id_dsa (DSA)
[utilisateur@machine dossier]$ ssh utilisateur@machine
Last login: Sat Apr  1 20:34:35 2006 from autre_machine
...
[utilisateur@machine dossier]$ exit



Cependant ssh-agent n'agit que pendant le temps de vie de la console donc pas après un redémarrage.



VII.Telnet et co



TELNET assure les mêmes fonctionnalités que SSH mais en version NON CRYPTE. CE PROTOCOLE EST DONC A PROSCRIRE POUR LES CONNEXIONS A DISTANCE à moins que l'appareil auquel on se connecte ne gère pas SSH (routeur, switch...). A noter que la commande telnet permet aussi de tester un service non crypté (non SSL) comme SMTP, POP ou IMAP.

Dans tous les cas, il faut vérifier que le service telnetd n'est pas présent dans le dossier /etc/xinetd.d. On devrait aussi désactiver le telnet de kerberos (krb5-telnet)...



VIII.Tunnels SSH


SSH permet également la création d'un tunnel crypté entre deux machines. SSH s'arrange pour multiplexer les données des différents tunnels et du tunnels par défaut (le contrôle à distance) pour assurer une sécurité à des protocoles non sécurisés.

Par exemple, pour mapper le port 110 du serveur machine.domain sur le port 3002 de la machine locale en passant par la machine autre_machine.domain sur laquelle vous avez un compte, et le tout de façon à ce que ce port 3002 soit accessible par le voisinage réseau de la machine locale (-g) :

[user]$ ssh -g -L 3002:machine.domain:110 user_distant@autre_machine.domain



Autre options intéressantes :



La syntaxe suivante permet de faire fermer la connexion, par exemple dans le cas des tunnels, au bout d'un certain temps (en secondes) :

[user]$ ssh -f autres_options sleep nb_secondes

a)Principe de fonctionnement



Le tunneling est le fait de pouvoir accéder, en plus de la connexion Shell distante, à d'autres services comme le mail, le partage de fichier ou le FTP au travers de la connexion sécurisée établie avec le serveur.

Un tunnel SSH a un seul but : sécuriser des protocoles qui ne sont pas prévus à la base pour l'être : par exemple, SMTP, X...



Note : pour ne pas avoir à taper toutes les options à chaque fois, on peut utiliser le fichier de configuration /etc/ssh/ssh_config ou un fichier de configuration personnel que l'on passe en paramètre avec l'option -F. L'option -g permet d'exposer les « ports forwardés » à toutes les machines qui ont accès à votre machine, sinon ils ne seront accessibles que depuis la boucle locale.

Redirection locale de port



Cela permet d'accéder à des services exposés sur la machine distante (serveur SSHD auquel on est connecté) ou sur des machines internes au réseau du serveur SSHD : option -L port_connexion_locale:serveur_distant:port_serveur_distant. Une fois la connexion SSH mise en place, on pourra se connecter à localhost:port_connexion_locale ce qui représente en fait une connexion à serveur_distant:port_serveur_distant par le canal sécurisé.




Redirection distante de port



Cela permet d'exposer des services de la machine locale ou de son voisinage réseau sur le serveur auquel elle est connecté : option -R port_serveur_local:serveur_local:port_connexion_distante. Une fois la connexion SSH mise en place, une personne, ayant accès au serveur auquel vous êtes connecté, pourra se connecter à localhost:port_connexion_distante ce qui représentera en fait une connexion à port_serveur_local:serveur_local





IX.Redirection X11

La redirection X11 permet de faire passer la connexion entre le serveur X (situé sur le client SSH) et le client X (situé sur le serveur SSH) au travers du canal sécurisé de SSH. Cela permet de lancer une application graphique sur le serveur SSH et de voir le résultat sur l'écran du client SSH (ce que permet X11) et le tout d'une manière sécurisée (ce que permet SSH).

a)Configuration du serveur



Pour autoriser les clients SSH à rediriger les programmes graphiques sur leurs écrans (redirection X11), les directives suivantes doivent prendre la valeur yes :

b)Configuration du client

Pour autoriser les clients à recevoir la redirection X11, le client doit :



c)Fonctionnement



D'abord, petite précision, pour X Window, le concept de client et serveur est inversé. Le client X est tout programme graphique lancé par le client sur le serveur SSH. Et le serveur X est le serveur tournant que le client qui permet l'affichage local au client. Voir tutoriel sur X.






Si le terminal depuis lequel on a appelé ssh dispose d'un affichage graphique :



Note sur la sécurité de l'opération : il est très important que l'utilisateur connecté soit le seul (à part root) à pouvoir lire le fichier .Xauthority situé dans son répertoire de connexion, autrement dit avec les droits rw------- (600). Sans cela, n'importe qui qui aurait accès à ce fichier pourrait se connecter au pseudo serveur X du serveur SSHD et ainsi voir ce que voit le client SSH saisies souris et clavier compris.



Note technique :

d)Utilisation



Il est recommander d'utiliser l'option -C pour permettre la compression des données circulant dans le canal.

On peut l'utiliser de plusieurs manières :



Il est nécessaire de l'assurer (en cas de problème) que les précautions suivantes sont prises :



e)Mode Untrusted et Trusted



Le modèle de sécurité X11 fait une distinction entre des clients « trusted » et « untrusted ». Sans rentrer dans le détail, les clients X11 « untrusted » ne peuvent pas agir avec les fenêtre et ressources possédées par des clients « trusted ».

Depuis la version 3.8, OpenSSH supporte la sécurité X11 et fait une redirection X11 « untrusted » par défaut. Cependant, la plus part des applications quelles sont des clients X « trusted » et peuvent ne pas fonctionner correctement ou crasher de manière inattendue en mode « untrusted ». Il est seulement nécessaire de configurer la redirection X11 en mode « trusted » dans les cas précédents. Cela peut se faire de deux façons différentes suivant le caractère permanent à donner ou pas :



X.Et pour Windows...ben oui ça existe...



Le client PUTTY est un ssh gratuit pour Windows...sa configuration est graphique donc cela ne devrait pas poser de problèmes. SI vous voulez de la redirection X11, installer Cygwin en plus pour avoir un serveur X.

WinSCP est l'équivalent Windows de scp.



Bibliographie



Pages de man de ssh, sshd, ssh_config, sshd_config

OpenSSH

PuTTY: a free telnet/ssh client

Utilisation de SSH

Cryptographie - Secure Shell (protocole SSH)

SSH Filesystem

HSC - Brève - SSH et redirection X11

Relayage SSH

sharevb