Je viens d'installer chez moi un petit NAS domestique (Qnap TS-101),
qui va me servir à plusieurs choses:
1) mettre mes données volumineuses (photos, musiques, videos...)
dessus
2) faire un backup des documents personnels importants situés sur le
PC
3) donner des accès FTP/HTTP à des gens de l'extérieur pour échanger
facilement des fichiers
4) accéder à mes documents personnels depuis l'extérieur (FTP ou HTTP)
Le NAS est derrière la box/routeur, et j'ai ouvert juste les ports
nécessaires. Les accès ne sont pas sécurisés (pas SSL).
Je sais bien que dès qu'on ouvre les accès vers l'extérieur, il y a
des risques. Mais j'aimerais évaluer ces risques:
Est-ce que 3) pose un problème par rapport à 2) ? Les partages et
droits d'accès isolent en principe mes données perso du reste, mais
est-ce qu'une connection FTP avec un compte présente le risque de
permettre d'accéder à d'autres comptes sur le même serveur ?
On 02 Dec 2008 12:40:35 GMT, Jean-Marc Desperrier :
Malheureusement en ce qui me concerne, scp pose souvent de catastrophiques problèmes de perf qui contraignent à passer par autre chose
Gloups... sur quel type de connexion ? Avec du 1 Gbps, effectivement, on peut avoir des problèmes. Mais en-dessous, ça me paraît bizarre.
Jean-Marc Desperrier
Xavier wrote:
Jean-Marc Desperrier wrote:
Je ne sais pas si c'est un problème de l'implémentation de OpenSSH ou du client ...
C'est un problème d'implémentation. Il serait facile de ne chiffrer que la session d'authentification, et pas la session DATA, mais l'Autorité Suprême a décidé que non, malgré les requêtes faites sur la ML openssh
Ce n'est pas une bonne raison.
L'effet du chiffrement sur la taille des données est nul, le chiffrement en soit ne faisant pas grossir les données, la seule chose qui a un léger effet est qu'il faut faire correspondre la taille totale à un multiple de la taille du bloc chiffré. Ce qui, sauf peut-être cas d'implémentation catastrophique qui les envoie octet par octet à la couche qui formate les blocs de données chiffrés, ne change globalement rien. Et la charge d'un chiffrement AES, c'est négligeable aussi pour un processeur Intel/AMD récent, les autres algo étant parfois plus lourd, mais bon, pas de plusieurs ordres de grandeur.
Et pourtant là à l'instant encore, avec un fc8 en serveur, un pscp en client, je me retrouve avec un 84.4 kB/s sur réseau local. WinSCP ne fait pas mieux que pscp, et je n'ai pas souvenir d'avoir en général constaté une grosse différence quand mon client était un Linux.
Probablement le problème pourrait se résoudre en investiguant suffisament, mais le fait qu'en FTP, même le client le plus merdique, le ftp intégré de base à windows ne pose pas ce problème, fait souvent la différence en déploiement derrière, pour précisément permettre de considérer le FTP comme un protocole d'un autre âge.
Dans le même environnement, telnet est vraiment devenu un protocole d'un autre âge, les environnement Linux/Solaris ayant joué leur rôle de ce coté en le désactivant par défaut/activant SSH par défaut.
Xavier wrote:
Jean-Marc Desperrier<jmdesp@alussinan.org> wrote:
Je ne sais pas si c'est un problème de l'implémentation de OpenSSH ou du
client ...
C'est un problème d'implémentation. Il serait facile de ne chiffrer que
la session d'authentification, et pas la session DATA, mais l'Autorité
Suprême a décidé que non, malgré les requêtes faites sur la ML openssh
Ce n'est pas une bonne raison.
L'effet du chiffrement sur la taille des données est nul, le chiffrement
en soit ne faisant pas grossir les données, la seule chose qui a un
léger effet est qu'il faut faire correspondre la taille totale à un
multiple de la taille du bloc chiffré. Ce qui, sauf peut-être cas
d'implémentation catastrophique qui les envoie octet par octet à la
couche qui formate les blocs de données chiffrés, ne change globalement
rien.
Et la charge d'un chiffrement AES, c'est négligeable aussi pour un
processeur Intel/AMD récent, les autres algo étant parfois plus lourd,
mais bon, pas de plusieurs ordres de grandeur.
Et pourtant là à l'instant encore, avec un fc8 en serveur, un pscp en
client, je me retrouve avec un 84.4 kB/s sur réseau local. WinSCP ne
fait pas mieux que pscp, et je n'ai pas souvenir d'avoir en général
constaté une grosse différence quand mon client était un Linux.
Probablement le problème pourrait se résoudre en investiguant
suffisament, mais le fait qu'en FTP, même le client le plus merdique, le
ftp intégré de base à windows ne pose pas ce problème, fait souvent la
différence en déploiement derrière, pour précisément permettre de
considérer le FTP comme un protocole d'un autre âge.
Dans le même environnement, telnet est vraiment devenu un protocole d'un
autre âge, les environnement Linux/Solaris ayant joué leur rôle de ce
coté en le désactivant par défaut/activant SSH par défaut.
Je ne sais pas si c'est un problème de l'implémentation de OpenSSH ou du client ...
C'est un problème d'implémentation. Il serait facile de ne chiffrer que la session d'authentification, et pas la session DATA, mais l'Autorité Suprême a décidé que non, malgré les requêtes faites sur la ML openssh
Ce n'est pas une bonne raison.
L'effet du chiffrement sur la taille des données est nul, le chiffrement en soit ne faisant pas grossir les données, la seule chose qui a un léger effet est qu'il faut faire correspondre la taille totale à un multiple de la taille du bloc chiffré. Ce qui, sauf peut-être cas d'implémentation catastrophique qui les envoie octet par octet à la couche qui formate les blocs de données chiffrés, ne change globalement rien. Et la charge d'un chiffrement AES, c'est négligeable aussi pour un processeur Intel/AMD récent, les autres algo étant parfois plus lourd, mais bon, pas de plusieurs ordres de grandeur.
Et pourtant là à l'instant encore, avec un fc8 en serveur, un pscp en client, je me retrouve avec un 84.4 kB/s sur réseau local. WinSCP ne fait pas mieux que pscp, et je n'ai pas souvenir d'avoir en général constaté une grosse différence quand mon client était un Linux.
Probablement le problème pourrait se résoudre en investiguant suffisament, mais le fait qu'en FTP, même le client le plus merdique, le ftp intégré de base à windows ne pose pas ce problème, fait souvent la différence en déploiement derrière, pour précisément permettre de considérer le FTP comme un protocole d'un autre âge.
Dans le même environnement, telnet est vraiment devenu un protocole d'un autre âge, les environnement Linux/Solaris ayant joué leur rôle de ce coté en le désactivant par défaut/activant SSH par défaut.
patpro ~ patrick proniewski
In article <gh3vm4$lgn$, Jean-Marc Desperrier wrote:
Et pourtant là à l'instant encore, avec un fc8 en serveur, un pscp en client, je me retrouve avec un 84.4 kB/s sur réseau local. WinSCP ne fait pas mieux que pscp, et je n'ai pas souvenir d'avoir en général constaté une grosse différence quand mon client était un Linux.
Probablement le problème pourrait se résoudre en investiguant suffisament, mais le fait qu'en FTP, même le client le plus merdique, le ftp intégré de base à windows ne pose pas ce problème, fait souvent la différence en déploiement derrière, pour précisément permettre de considérer le FTP comme un protocole d'un autre âge.
Dans le même environnement, telnet est vraiment devenu un protocole d'un autre âge, les environnement Linux/Solaris ayant joué leur rôle de ce coté en le désactivant par défaut/activant SSH par défaut.
J'ai souvenir d'une lecture ancienne qui parlait du problème de ssh (et donc scp) avec la gestion de la fenêtre d'envoi (taille des packets pas optimisée en fonction de la latence, notamment).
un peu de lecture : <http://www.psc.edu/networking/projects/hpn-ssh/>
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <gh3vm4$lgn$1@writer.imaginet.fr>,
Jean-Marc Desperrier <jmdesp@alussinan.org> wrote:
Et pourtant là à l'instant encore, avec un fc8 en serveur, un pscp en
client, je me retrouve avec un 84.4 kB/s sur réseau local. WinSCP ne
fait pas mieux que pscp, et je n'ai pas souvenir d'avoir en général
constaté une grosse différence quand mon client était un Linux.
Probablement le problème pourrait se résoudre en investiguant
suffisament, mais le fait qu'en FTP, même le client le plus merdique, le
ftp intégré de base à windows ne pose pas ce problème, fait souvent la
différence en déploiement derrière, pour précisément permettre de
considérer le FTP comme un protocole d'un autre âge.
Dans le même environnement, telnet est vraiment devenu un protocole d'un
autre âge, les environnement Linux/Solaris ayant joué leur rôle de ce
coté en le désactivant par défaut/activant SSH par défaut.
J'ai souvenir d'une lecture ancienne qui parlait du problème de ssh (et
donc scp) avec la gestion de la fenêtre d'envoi (taille des packets pas
optimisée en fonction de la latence, notamment).
un peu de lecture :
<http://www.psc.edu/networking/projects/hpn-ssh/>
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
In article <gh3vm4$lgn$, Jean-Marc Desperrier wrote:
Et pourtant là à l'instant encore, avec un fc8 en serveur, un pscp en client, je me retrouve avec un 84.4 kB/s sur réseau local. WinSCP ne fait pas mieux que pscp, et je n'ai pas souvenir d'avoir en général constaté une grosse différence quand mon client était un Linux.
Probablement le problème pourrait se résoudre en investiguant suffisament, mais le fait qu'en FTP, même le client le plus merdique, le ftp intégré de base à windows ne pose pas ce problème, fait souvent la différence en déploiement derrière, pour précisément permettre de considérer le FTP comme un protocole d'un autre âge.
Dans le même environnement, telnet est vraiment devenu un protocole d'un autre âge, les environnement Linux/Solaris ayant joué leur rôle de ce coté en le désactivant par défaut/activant SSH par défaut.
J'ai souvenir d'une lecture ancienne qui parlait du problème de ssh (et donc scp) avec la gestion de la fenêtre d'envoi (taille des packets pas optimisée en fonction de la latence, notamment).
un peu de lecture : <http://www.psc.edu/networking/projects/hpn-ssh/>
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
mpg
Le (on) mardi 02 décembre 2008 19:52, Jean-Marc Desperrier a écrit (wrote) :
Et pourtant là à l'instant encore, avec un fc8 en serveur, un pscp en client, je me retrouve avec un 84.4 kB/s sur réseau local. WinSCP ne fait pas mieux que pscp, et je n'ai pas souvenir d'avoir en général constaté une grosse différence quand mon client était un Linux.
Wow, c'est bizarre, chez moi j'ai de l'ordre de 2,5 Mo/s (et je pense que c'est la partie wifi qui limite). Et encore, c'est en sftp (sshfs pour être précis), qui est réputé un poil plus lent que le scp.
Manuel.
Le (on) mardi 02 décembre 2008 19:52, Jean-Marc Desperrier a écrit (wrote) :
Et pourtant là à l'instant encore, avec un fc8 en serveur, un pscp en
client, je me retrouve avec un 84.4 kB/s sur réseau local. WinSCP ne
fait pas mieux que pscp, et je n'ai pas souvenir d'avoir en général
constaté une grosse différence quand mon client était un Linux.
Wow, c'est bizarre, chez moi j'ai de l'ordre de 2,5 Mo/s (et je pense que
c'est la partie wifi qui limite). Et encore, c'est en sftp (sshfs pour être
précis), qui est réputé un poil plus lent que le scp.
Le (on) mardi 02 décembre 2008 19:52, Jean-Marc Desperrier a écrit (wrote) :
Et pourtant là à l'instant encore, avec un fc8 en serveur, un pscp en client, je me retrouve avec un 84.4 kB/s sur réseau local. WinSCP ne fait pas mieux que pscp, et je n'ai pas souvenir d'avoir en général constaté une grosse différence quand mon client était un Linux.
Wow, c'est bizarre, chez moi j'ai de l'ordre de 2,5 Mo/s (et je pense que c'est la partie wifi qui limite). Et encore, c'est en sftp (sshfs pour être précis), qui est réputé un poil plus lent que le scp.
Manuel.
mpg
Le (on) mardi 02 décembre 2008 03:24, Fabien LE LEZ a écrit (wrote) :
On 01 Dec 2008 17:49:26 GMT, mpg :
J'aime bien le raccourci copyrighté = illégal.
La notion de "légalité" est du ressort d'un juge.
Ou en tout cas devrait n'être que du ressort d'un juge, on est bien d'accord.
Étant donné que Hadopi peut couper ta connexion à Internet de façon automatique, copyrighté = problèmes potentiels.
Tu as sans doute raison d'un point de vue pragmatique, mais ça m'énerve quand même, de devoir en arriver à chiffrer du contenu légitime juste parce que ta connexion est tenue en otage par des gens qui pourraient avoir la « gachete » facile. Enfin, ce n'était pas le lieu pour s'énerver à ce sujet, désolé.
Manuel.
Le (on) mardi 02 décembre 2008 03:24, Fabien LE LEZ a écrit (wrote) :
On 01 Dec 2008 17:49:26 GMT, mpg <mpg-news@elzevir.fr>:
J'aime bien le raccourci copyrighté = illégal.
La notion de "légalité" est du ressort d'un juge.
Ou en tout cas devrait n'être que du ressort d'un juge, on est bien
d'accord.
Étant donné que Hadopi peut couper ta connexion à Internet de façon
automatique, copyrighté = problèmes potentiels.
Tu as sans doute raison d'un point de vue pragmatique, mais ça m'énerve
quand même, de devoir en arriver à chiffrer du contenu légitime juste parce
que ta connexion est tenue en otage par des gens qui pourraient avoir
la « gachete » facile. Enfin, ce n'était pas le lieu pour s'énerver à ce
sujet, désolé.
Le (on) mardi 02 décembre 2008 03:24, Fabien LE LEZ a écrit (wrote) :
On 01 Dec 2008 17:49:26 GMT, mpg :
J'aime bien le raccourci copyrighté = illégal.
La notion de "légalité" est du ressort d'un juge.
Ou en tout cas devrait n'être que du ressort d'un juge, on est bien d'accord.
Étant donné que Hadopi peut couper ta connexion à Internet de façon automatique, copyrighté = problèmes potentiels.
Tu as sans doute raison d'un point de vue pragmatique, mais ça m'énerve quand même, de devoir en arriver à chiffrer du contenu légitime juste parce que ta connexion est tenue en otage par des gens qui pourraient avoir la « gachete » facile. Enfin, ce n'était pas le lieu pour s'énerver à ce sujet, désolé.
Manuel.
Patrick Lamaiziere
Jean-Marc Desperrier écrivait
Et la charge d'un chiffrement AES, c'est négligeable aussi pour un processeur Intel/AMD récent, les autres algo étant parfois plus lourd, mais bon, pas de plusieurs ordres de grandeur.
Sur un Geode LX 800 (ok c'est pas très puissant), avec scp je passe de 3 Mo/s à 5,5 Mo/s en utilisant le moteur AES intégré au CPU. Comme quoi le coût du cryptage est loin d'être négligeable sur un tel processeur.
Jean-Marc Desperrier écrivait
Et la charge d'un chiffrement AES, c'est négligeable aussi pour un
processeur Intel/AMD récent, les autres algo étant parfois plus lourd,
mais bon, pas de plusieurs ordres de grandeur.
Sur un Geode LX 800 (ok c'est pas très puissant), avec scp je passe de 3
Mo/s à 5,5 Mo/s en utilisant le moteur AES intégré au CPU. Comme quoi le
coût du cryptage est loin d'être négligeable sur un tel processeur.
Et la charge d'un chiffrement AES, c'est négligeable aussi pour un processeur Intel/AMD récent, les autres algo étant parfois plus lourd, mais bon, pas de plusieurs ordres de grandeur.
Sur un Geode LX 800 (ok c'est pas très puissant), avec scp je passe de 3 Mo/s à 5,5 Mo/s en utilisant le moteur AES intégré au CPU. Comme quoi le coût du cryptage est loin d'être négligeable sur un tel processeur.
Jean-Marc Desperrier
Patrick Lamaiziere wrote:
Jean-Marc Desperrier écrivait
Et la charge d'un chiffrement AES, c'est négligeable aussi pour un processeur Intel/AMD récent, les autres algo étant parfois plus lourd, mais bon, pas de plusieurs ordres de grandeur.
Sur un Geode LX 800 (ok c'est pas très puissant), avec scp je passe de 3 Mo/s à 5,5 Mo/s en utilisant le moteur AES intégré au CPU. Comme quoi le coût du cryptage est loin d'être négligeable sur un tel processeur.
Mais là, coté client c'était un X2 3800+ dual core (et puis surtout les chiffres n'étaient pas de l'ordre de plusieurs méga par seconde où la perf du processeur commence à peser). Coté serveur, par contre c'est sur une machine virtuelle qui doit avoir une bonne part de responsabilité.
Patrick Lamaiziere wrote:
Jean-Marc Desperrier écrivait
Et la charge d'un chiffrement AES, c'est négligeable aussi pour un
processeur Intel/AMD récent, les autres algo étant parfois plus lourd,
mais bon, pas de plusieurs ordres de grandeur.
Sur un Geode LX 800 (ok c'est pas très puissant), avec scp je passe de 3
Mo/s à 5,5 Mo/s en utilisant le moteur AES intégré au CPU. Comme quoi le
coût du cryptage est loin d'être négligeable sur un tel processeur.
Mais là, coté client c'était un X2 3800+ dual core (et puis surtout les
chiffres n'étaient pas de l'ordre de plusieurs méga par seconde où la
perf du processeur commence à peser). Coté serveur, par contre c'est sur
une machine virtuelle qui doit avoir une bonne part de responsabilité.
Et la charge d'un chiffrement AES, c'est négligeable aussi pour un processeur Intel/AMD récent, les autres algo étant parfois plus lourd, mais bon, pas de plusieurs ordres de grandeur.
Sur un Geode LX 800 (ok c'est pas très puissant), avec scp je passe de 3 Mo/s à 5,5 Mo/s en utilisant le moteur AES intégré au CPU. Comme quoi le coût du cryptage est loin d'être négligeable sur un tel processeur.
Mais là, coté client c'était un X2 3800+ dual core (et puis surtout les chiffres n'étaient pas de l'ordre de plusieurs méga par seconde où la perf du processeur commence à peser). Coté serveur, par contre c'est sur une machine virtuelle qui doit avoir une bonne part de responsabilité.
pehache-tolai
On 2 déc, 12:03, Stephane Gregoire wrote:
Salut, Le Tue, 02 Dec 2008 10:43:25 +0000, pehache-tolai a écrit :
> En fait j'ai découvert hier qu'il était capable de faire du https non > seulement pour l'administration, mais aussi pour la gestion et l'échange > de fichiers.
D'après cette page, on peux installer un client/serveur SSH : <http://scratchpad.wikia.com/wiki/ Open_Turbostation:TS101#Installing_new_packages> ou lien court : <http://scratchpad.wikia.com/wiki/Open_Turbostation:TS101>
Mais comme je n'ai jamais utilisé de NAS, je ne sais pas si c'est trivial de mettre à jour le firmware.
Comme c'est décrit dans la doc, c'est simple. Maintenant je ne pas très sûr d'avoir envie d'installer des firmwares alternatifs... Enfin, ce n'est pas très clair si cette mise à jour consiste simplement en des packages additionnels qui ne touchent pas au firmware existant, ou bien si c'est un remplacement complet du firmware.
Par ailleurs je n'y connais pas grand chose: est-ce que la simple installation d'un client/serveur SSH suffit en soi pour pouvoir faire du sftp ? J'imagine que non ?
-- pehache
On 2 déc, 12:03, Stephane Gregoire <stephane.grego...@mhuu.org> wrote:
Salut,
Le Tue, 02 Dec 2008 10:43:25 +0000, pehache-tolai a écrit :
> En fait j'ai découvert hier qu'il était capable de faire du https non
> seulement pour l'administration, mais aussi pour la gestion et l'échange
> de fichiers.
D'après cette page, on peux installer un client/serveur SSH :
<http://scratchpad.wikia.com/wiki/
Open_Turbostation:TS101#Installing_new_packages>
ou lien court : <http://scratchpad.wikia.com/wiki/Open_Turbostation:TS101>
Mais comme je n'ai jamais utilisé de NAS, je ne sais pas si c'est trivial
de mettre à jour le firmware.
Comme c'est décrit dans la doc, c'est simple. Maintenant je ne pas
très sûr d'avoir envie d'installer des firmwares alternatifs... Enfin,
ce n'est pas très clair si cette mise à jour consiste simplement en
des packages additionnels qui ne touchent pas au firmware existant, ou
bien si c'est un remplacement complet du firmware.
Par ailleurs je n'y connais pas grand chose: est-ce que la simple
installation d'un client/serveur SSH suffit en soi pour pouvoir faire
du sftp ? J'imagine que non ?
Salut, Le Tue, 02 Dec 2008 10:43:25 +0000, pehache-tolai a écrit :
> En fait j'ai découvert hier qu'il était capable de faire du https non > seulement pour l'administration, mais aussi pour la gestion et l'échange > de fichiers.
D'après cette page, on peux installer un client/serveur SSH : <http://scratchpad.wikia.com/wiki/ Open_Turbostation:TS101#Installing_new_packages> ou lien court : <http://scratchpad.wikia.com/wiki/Open_Turbostation:TS101>
Mais comme je n'ai jamais utilisé de NAS, je ne sais pas si c'est trivial de mettre à jour le firmware.
Comme c'est décrit dans la doc, c'est simple. Maintenant je ne pas très sûr d'avoir envie d'installer des firmwares alternatifs... Enfin, ce n'est pas très clair si cette mise à jour consiste simplement en des packages additionnels qui ne touchent pas au firmware existant, ou bien si c'est un remplacement complet du firmware.
Par ailleurs je n'y connais pas grand chose: est-ce que la simple installation d'un client/serveur SSH suffit en soi pour pouvoir faire du sftp ? J'imagine que non ?
-- pehache
Fabien LE LEZ
On 04 Dec 2008 10:24:50 GMT, pehache-tolai :
est-ce que la simple installation d'un client/serveur SSH suffit en soi pour pouvoir faire du sftp ?
Il me semble que oui. En tout cas, c'est le cas pour OpenSSH. Mais au pire, tu peux toujours te rabattre sur scp...
On 04 Dec 2008 10:24:50 GMT, pehache-tolai <pehache.7@gmail.com>:
est-ce que la simple
installation d'un client/serveur SSH suffit en soi pour pouvoir faire
du sftp ?
Il me semble que oui. En tout cas, c'est le cas pour OpenSSH.
Mais au pire, tu peux toujours te rabattre sur scp...
est-ce que la simple installation d'un client/serveur SSH suffit en soi pour pouvoir faire du sftp ?
Il me semble que oui. En tout cas, c'est le cas pour OpenSSH. Mais au pire, tu peux toujours te rabattre sur scp...
Jean-Marc Desperrier
pehache-tolai wrote:
[...] Par ailleurs je n'y connais pas grand chose: est-ce que la simple installation d'un client/serveur SSH suffit en soi pour pouvoir faire du sftp ? J'imagine que non ?
Dans le cas d'openSSH, installer la partie serveur suffit.
Dans le détail le sftp est géré par un exécutable séparé sftp-server http://docs.sun.com/app/docs/doc/816-5212/6mbcdgk8u?a=view , mais qui fait partie du package openSSH et auquel sshd passe automatiquement la main quand le client passe une commande sftp.
pehache-tolai wrote:
[...]
Par ailleurs je n'y connais pas grand chose: est-ce que la simple
installation d'un client/serveur SSH suffit en soi pour pouvoir faire
du sftp ? J'imagine que non ?
Dans le cas d'openSSH, installer la partie serveur suffit.
Dans le détail le sftp est géré par un exécutable séparé sftp-server
http://docs.sun.com/app/docs/doc/816-5212/6mbcdgk8u?a=view , mais qui
fait partie du package openSSH et auquel sshd passe automatiquement la
main quand le client passe une commande sftp.
[...] Par ailleurs je n'y connais pas grand chose: est-ce que la simple installation d'un client/serveur SSH suffit en soi pour pouvoir faire du sftp ? J'imagine que non ?
Dans le cas d'openSSH, installer la partie serveur suffit.
Dans le détail le sftp est géré par un exécutable séparé sftp-server http://docs.sun.com/app/docs/doc/816-5212/6mbcdgk8u?a=view , mais qui fait partie du package openSSH et auquel sshd passe automatiquement la main quand le client passe une commande sftp.
