On me demande de configurer un acces a un serveur subversion interne
pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et
je met la bonne incantation dans .ssh/autrized_keys et le dev peut
faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou
meme l'execution de n'importe quelle commande ?
On me demande de configurer un acces a un serveur subversion interne pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et je met la bonne incantation dans .ssh/autrized_keys et le dev peut faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
Est-ce que c'est seulement possible ?
Ben oui. dans le répertoire conf/ de ton dépot, cf les fichiers authz svnserve.conf passwd
-- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 12-07-2011, Curious George <cg@nowhere.invalid> a écrit :
Bonjour,
On me demande de configurer un acces a un serveur subversion interne
pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et
je met la bonne incantation dans .ssh/autrized_keys et le dev peut
faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou
meme l'execution de n'importe quelle commande ?
Est-ce que c'est seulement possible ?
Ben oui.
dans le répertoire conf/ de ton dépot, cf les fichiers
authz
svnserve.conf
passwd
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
On me demande de configurer un acces a un serveur subversion interne pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et je met la bonne incantation dans .ssh/autrized_keys et le dev peut faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
Est-ce que c'est seulement possible ?
Ben oui. dans le répertoire conf/ de ton dépot, cf les fichiers authz svnserve.conf passwd
-- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
lusenet
[fu2 fcou, cela ne me semble pas de la configuration Linux]
Le Tue, 12 Jul 2011 04:48:58 -0500, Curious George a écrit : [...]
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
Est-ce que c'est seulement possible ?
Il "suffit" d'avoir un shell qui exécute "svnserve" inconditionellement.
La commande à exécuter est la même que celle utilisée dans l'option "command=" du fichier ".ssh/authorized_keys" si c'est déjà ce qui est utilisé.
Toutefois, lors d'un "checkout" (qui fait quelque chose, penser aux checkouts de branches ou tags pas juste de "trunk") il y a au moins deux connexions au serveur distant donc il faudra que les développeurs externes entrent leur mot de passe deux fois, ce qui est au minimum fastidieux. [1]
Je suis preneur de toutes piste.
J'utilise un programme du même genre que "anoncvssh.c" de OpenBSD (<http://www.openbsd.org/anoncvs.shar>), qui fait entre autres un execle(".../svnserve", ".../svnserve", "-tr", "/svn", NULL, env);
Le ".../svnserve" est remplacé par le vrai chemin d'accès au programme "svnserve", le "-tr" sert, entre autres, à éviter d'exposer le chemin "/svn/repository" ("svn+ssh://machine/repository" suffit, cf. "man svnserve") et "env" est un environnement minimaliste et quasiment fixe.
Après on peut le faire dans le langage qu'on veut, moi c'est en C mais j'ai de l'ordre de 50000 connexions SVN par jour (donc Perl, Python ou Ruby commencent à être lourds).
Un autre intérêt par rapport à "command=" dans la configuration SSH est de pouvoir afficher un message utile si l'utilisateur se trompe/essaie de se connecter interactivement et pas simplement le message de connexion de 'svnserve' "( success ( 2 2 ( ) ..." ou rien du tout.
Loïc.
[1] Sauf s'ils utilisent un IDE qui retient leur mot de passe ce qui, à mon avis, annule l'unique intérêt d'avoir un mot de passe plutôt qu'une authentification par clefs, c'est-à-dire empêcher les passphrases vides et les accès sans authentification apparente (les agents SSH et l'éducation des développeurs servent aussi à éviter les passphrases vides, mais le serveur n'a pas plus de contrôle effectif que sur les IDEs des développeurs).
[fu2 fcou, cela ne me semble pas de la configuration Linux]
Le Tue, 12 Jul 2011 04:48:58 -0500, Curious George a écrit :
[...]
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou
meme l'execution de n'importe quelle commande ?
Est-ce que c'est seulement possible ?
Il "suffit" d'avoir un shell qui exécute "svnserve" inconditionellement.
La commande à exécuter est la même que celle utilisée dans l'option
"command=" du fichier ".ssh/authorized_keys" si c'est déjà ce qui est
utilisé.
Toutefois, lors d'un "checkout" (qui fait quelque chose, penser aux
checkouts de branches ou tags pas juste de "trunk") il y a au moins deux
connexions au serveur distant donc il faudra que les développeurs
externes entrent leur mot de passe deux fois, ce qui est au minimum
fastidieux. [1]
Je suis preneur de toutes piste.
J'utilise un programme du même genre que "anoncvssh.c" de OpenBSD
(<http://www.openbsd.org/anoncvs.shar>), qui fait entre autres un
execle(".../svnserve", ".../svnserve", "-tr", "/svn", NULL, env);
Le ".../svnserve" est remplacé par le vrai chemin d'accès au programme
"svnserve", le "-tr" sert, entre autres, à éviter d'exposer le chemin
"/svn/repository" ("svn+ssh://machine/repository" suffit, cf.
"man svnserve") et "env" est un environnement minimaliste et quasiment
fixe.
Après on peut le faire dans le langage qu'on veut, moi c'est en C mais
j'ai de l'ordre de 50000 connexions SVN par jour (donc Perl, Python ou
Ruby commencent à être lourds).
Un autre intérêt par rapport à "command=" dans la configuration SSH est
de pouvoir afficher un message utile si l'utilisateur se trompe/essaie
de se connecter interactivement et pas simplement le message de
connexion de 'svnserve' "( success ( 2 2 ( ) ..." ou rien du tout.
Loïc.
[1] Sauf s'ils utilisent un IDE qui retient leur mot de passe ce qui,
à mon avis, annule l'unique intérêt d'avoir un mot de passe plutôt
qu'une authentification par clefs, c'est-à-dire empêcher les
passphrases vides et les accès sans authentification apparente (les
agents SSH et l'éducation des développeurs servent aussi à éviter
les passphrases vides, mais le serveur n'a pas plus de contrôle
effectif que sur les IDEs des développeurs).
[fu2 fcou, cela ne me semble pas de la configuration Linux]
Le Tue, 12 Jul 2011 04:48:58 -0500, Curious George a écrit : [...]
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
Est-ce que c'est seulement possible ?
Il "suffit" d'avoir un shell qui exécute "svnserve" inconditionellement.
La commande à exécuter est la même que celle utilisée dans l'option "command=" du fichier ".ssh/authorized_keys" si c'est déjà ce qui est utilisé.
Toutefois, lors d'un "checkout" (qui fait quelque chose, penser aux checkouts de branches ou tags pas juste de "trunk") il y a au moins deux connexions au serveur distant donc il faudra que les développeurs externes entrent leur mot de passe deux fois, ce qui est au minimum fastidieux. [1]
Je suis preneur de toutes piste.
J'utilise un programme du même genre que "anoncvssh.c" de OpenBSD (<http://www.openbsd.org/anoncvs.shar>), qui fait entre autres un execle(".../svnserve", ".../svnserve", "-tr", "/svn", NULL, env);
Le ".../svnserve" est remplacé par le vrai chemin d'accès au programme "svnserve", le "-tr" sert, entre autres, à éviter d'exposer le chemin "/svn/repository" ("svn+ssh://machine/repository" suffit, cf. "man svnserve") et "env" est un environnement minimaliste et quasiment fixe.
Après on peut le faire dans le langage qu'on veut, moi c'est en C mais j'ai de l'ordre de 50000 connexions SVN par jour (donc Perl, Python ou Ruby commencent à être lourds).
Un autre intérêt par rapport à "command=" dans la configuration SSH est de pouvoir afficher un message utile si l'utilisateur se trompe/essaie de se connecter interactivement et pas simplement le message de connexion de 'svnserve' "( success ( 2 2 ( ) ..." ou rien du tout.
Loïc.
[1] Sauf s'ils utilisent un IDE qui retient leur mot de passe ce qui, à mon avis, annule l'unique intérêt d'avoir un mot de passe plutôt qu'une authentification par clefs, c'est-à-dire empêcher les passphrases vides et les accès sans authentification apparente (les agents SSH et l'éducation des développeurs servent aussi à éviter les passphrases vides, mais le serveur n'a pas plus de contrôle effectif que sur les IDEs des développeurs).
gits
On 12 juil, 11:48, Curious George wrote:
Bonjour,
On me demande de configurer un acces a un serveur subversion interne pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et je met la bonne incantation dans .ssh/autrized_keys et le dev peut faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
à charge au script /path/to/svn.sh de faire ce qu'il veut tout en étant le plus sécurisé possible. la commande passé se trouve dans la variable $SSH_ORIGINAL_COMMAND.
ex. pour les commandes symcli (EMC) :
#!/usr/bin/sh
if [[ -n ${BASH_VERSION} ]]; then shopt -s expand_aliases extglob xpg_echo print () { if [[ $1 = *2* ]]; then shift 2 echo "$@" >&2 else shift 2 echo "$@" fi } fi
if [[ -z ${SSH_ORIGINAL_COMMAND} ]]; then print -ru2 -- "${SSH_ORIGINAL_COMMAND}: not set" exit 1 fi
# was if print -r -- "${SSH_ORIGINAL_COMMAND}" | # grep -q '[;&|(){}<>`^$?*]'; then # ?* may be ommited above and added below meta=$(print -r -- "${SSH_ORIGINAL_COMMAND}" | tr -d -- 't -/.a-zA-Z_0-9?*"'"'") if [[ -n ${meta} ]]; then print -ru2 -- "${SSH_ORIGINAL_COMMAND}: metacharacters rejected" exit 1 fi
en attendant de savoir quoi mettre dans cmd=, pattern= et path=, tu doit pouvoir tout simplement faire un echo $SSH_ORIGINAL_COMMAND
PS : j'ai laissé fcou car ce n'est pas propre à linux...
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
On 12 juil, 11:48, Curious George <c...@nowhere.invalid> wrote:
Bonjour,
On me demande de configurer un acces a un serveur subversion interne
pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et
je met la bonne incantation dans .ssh/autrized_keys et le dev peut
faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou
meme l'execution de n'importe quelle commande ?
à charge au script /path/to/svn.sh de faire ce qu'il veut tout en
étant le plus sécurisé possible.
la commande passé se trouve dans la variable $SSH_ORIGINAL_COMMAND.
ex. pour les commandes symcli (EMC) :
#!/usr/bin/sh
if [[ -n ${BASH_VERSION} ]]; then
shopt -s expand_aliases extglob xpg_echo
print () {
if [[ $1 = *2* ]]; then
shift 2
echo "$@" >&2
else
shift 2
echo "$@"
fi
}
fi
if [[ -z ${SSH_ORIGINAL_COMMAND} ]]; then
print -ru2 -- "${SSH_ORIGINAL_COMMAND}: not set"
exit 1
fi
# was if print -r -- "${SSH_ORIGINAL_COMMAND}" |
# grep -q '[;&|(){}<>`^$?*]'; then
# ?* may be ommited above and added below
meta=$(print -r -- "${SSH_ORIGINAL_COMMAND}" |
tr -d -- 't -/.a-zA-Z_0-9?*\"'"'")
if [[ -n ${meta} ]]; then
print -ru2 -- "${SSH_ORIGINAL_COMMAND}: metacharacters
rejected"
exit 1
fi
On me demande de configurer un acces a un serveur subversion interne pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et je met la bonne incantation dans .ssh/autrized_keys et le dev peut faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
à charge au script /path/to/svn.sh de faire ce qu'il veut tout en étant le plus sécurisé possible. la commande passé se trouve dans la variable $SSH_ORIGINAL_COMMAND.
ex. pour les commandes symcli (EMC) :
#!/usr/bin/sh
if [[ -n ${BASH_VERSION} ]]; then shopt -s expand_aliases extglob xpg_echo print () { if [[ $1 = *2* ]]; then shift 2 echo "$@" >&2 else shift 2 echo "$@" fi } fi
if [[ -z ${SSH_ORIGINAL_COMMAND} ]]; then print -ru2 -- "${SSH_ORIGINAL_COMMAND}: not set" exit 1 fi
# was if print -r -- "${SSH_ORIGINAL_COMMAND}" | # grep -q '[;&|(){}<>`^$?*]'; then # ?* may be ommited above and added below meta=$(print -r -- "${SSH_ORIGINAL_COMMAND}" | tr -d -- 't -/.a-zA-Z_0-9?*"'"'") if [[ -n ${meta} ]]; then print -ru2 -- "${SSH_ORIGINAL_COMMAND}: metacharacters rejected" exit 1 fi
en attendant de savoir quoi mettre dans cmd=, pattern= et path=, tu doit pouvoir tout simplement faire un echo $SSH_ORIGINAL_COMMAND
PS : j'ai laissé fcou car ce n'est pas propre à linux...
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Erwan David
gits écrivait :
On 12 juil, 11:48, Curious George wrote:
Bonjour,
On me demande de configurer un acces a un serveur subversion interne pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et je met la bonne incantation dans .ssh/autrized_keys et le dev peut faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
à charge au script /path/to/svn.sh de faire ce qu'il veut tout en étant le plus sécurisé possible. la commande passé se trouve dans la variable $SSH_ORIGINAL_COMMAND.
Sauf que là, la demande c'est "sans clef"...
Et en mettant comme shell de login pour ces comptes un shell restreint qui ne peut lancer que svn ?
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
gits <lefevre.cyrille@gmail.com> écrivait :
On 12 juil, 11:48, Curious George <c...@nowhere.invalid> wrote:
Bonjour,
On me demande de configurer un acces a un serveur subversion interne
pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et
je met la bonne incantation dans .ssh/autrized_keys et le dev peut
faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou
meme l'execution de n'importe quelle commande ?
à charge au script /path/to/svn.sh de faire ce qu'il veut tout en
étant le plus sécurisé possible.
la commande passé se trouve dans la variable $SSH_ORIGINAL_COMMAND.
Sauf que là, la demande c'est "sans clef"...
Et en mettant comme shell de login pour ces comptes un shell restreint
qui ne peut lancer que svn ?
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
On me demande de configurer un acces a un serveur subversion interne pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et je met la bonne incantation dans .ssh/autrized_keys et le dev peut faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
à charge au script /path/to/svn.sh de faire ce qu'il veut tout en étant le plus sécurisé possible. la commande passé se trouve dans la variable $SSH_ORIGINAL_COMMAND.
Sauf que là, la demande c'est "sans clef"...
Et en mettant comme shell de login pour ces comptes un shell restreint qui ne peut lancer que svn ?
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Erwan David
gits écrivait :
On 12 juil, 11:48, Curious George wrote:
Bonjour,
On me demande de configurer un acces a un serveur subversion interne pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et je met la bonne incantation dans .ssh/autrized_keys et le dev peut faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
à charge au script /path/to/svn.sh de faire ce qu'il veut tout en étant le plus sécurisé possible. la commande passé se trouve dans la variable $SSH_ORIGINAL_COMMAND.
Sauf que là, la demande c'est "sans clef"...
Et en mettant comme shell de login pour ces comptes un shell restreint qui ne peut lancer que svn ?
Ou alors mettre l'accès au svn dans un apache et faire passer ça en HTTPS, avec un BasicAuthentication ou un DigestAuthentication ?
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
gits <lefevre.cyrille@gmail.com> écrivait :
On 12 juil, 11:48, Curious George <c...@nowhere.invalid> wrote:
Bonjour,
On me demande de configurer un acces a un serveur subversion interne
pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et
je met la bonne incantation dans .ssh/autrized_keys et le dev peut
faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou
meme l'execution de n'importe quelle commande ?
à charge au script /path/to/svn.sh de faire ce qu'il veut tout en
étant le plus sécurisé possible.
la commande passé se trouve dans la variable $SSH_ORIGINAL_COMMAND.
Sauf que là, la demande c'est "sans clef"...
Et en mettant comme shell de login pour ces comptes un shell restreint
qui ne peut lancer que svn ?
Ou alors mettre l'accès au svn dans un apache et faire passer ça en
HTTPS, avec un BasicAuthentication ou un DigestAuthentication ?
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
On me demande de configurer un acces a un serveur subversion interne pour des developpeurs externes.
Normalement, je cree un compte, je demande au dev sa cle publique, et je met la bonne incantation dans .ssh/autrized_keys et le dev peut faire du svn et rien d'autre.
Mais la, pas le droit aux paires de cles, password obligatoire.
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
à charge au script /path/to/svn.sh de faire ce qu'il veut tout en étant le plus sécurisé possible. la commande passé se trouve dans la variable $SSH_ORIGINAL_COMMAND.
Sauf que là, la demande c'est "sans clef"...
Et en mettant comme shell de login pour ces comptes un shell restreint qui ne peut lancer que svn ?
Ou alors mettre l'accès au svn dans un apache et faire passer ça en HTTPS, avec un BasicAuthentication ou un DigestAuthentication ?
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Marc Boyer
Le 12-07-2011, Curious George a écrit :
Bonjour,
On me demande de configurer un acces a un serveur subversion interne pour des developpeurs externes.
J'ai une question, une fois vu les solutions compliquées des autres. Est-ce que tu *dois* passer par ssh ?
Parce que la solution qui me semblerait convenir sinon, c'est un démon subversion sur la machine avec le dépot, et des comptes qui sont liés aux dépots, et accès en svn ou https...
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 12-07-2011, Curious George <cg@nowhere.invalid> a écrit :
Bonjour,
On me demande de configurer un acces a un serveur subversion interne
pour des developpeurs externes.
J'ai une question, une fois vu les solutions compliquées des autres.
Est-ce que tu *dois* passer par ssh ?
Parce que la solution qui me semblerait convenir sinon, c'est
un démon subversion sur la machine avec le dépot, et des comptes
qui sont liés aux dépots, et accès en svn ou https...
Marc Boyer
--
À mesure que les inégalités regressent, les attentes se renforcent.
François Dubet
On me demande de configurer un acces a un serveur subversion interne pour des developpeurs externes.
J'ai une question, une fois vu les solutions compliquées des autres. Est-ce que tu *dois* passer par ssh ?
Parce que la solution qui me semblerait convenir sinon, c'est un démon subversion sur la machine avec le dépot, et des comptes qui sont liés aux dépots, et accès en svn ou https...
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Fabien LE LEZ
On Tue, 12 Jul 2011 04:48:58 -0500, Curious George :
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
A priori, il ne faut pas passer par SSH. Si tu veux du SSL, tu peux passer soit par HTTPS, soit par stunnel.
Toutefois, si, pour une raison ou une autre, tu dois vraiment utiliser SSH, une solution serait de définir comme shell pour l'utilisateur non pas /bin/bash, mais un script qui n'accepte que les commandes SVN.
Un exemple pour n'autoriser que rsync : http://www.inwap.com/mybin/miscunix/?rrsync
On Tue, 12 Jul 2011 04:48:58 -0500, Curious George :
Probleme : comment n'autoriser que svn et pas de login interactif ou
meme l'execution de n'importe quelle commande ?
A priori, il ne faut pas passer par SSH. Si tu veux du SSL, tu peux
passer soit par HTTPS, soit par stunnel.
Toutefois, si, pour une raison ou une autre, tu dois vraiment utiliser
SSH, une solution serait de définir comme shell pour l'utilisateur non
pas /bin/bash, mais un script qui n'accepte que les commandes SVN.
Un exemple pour n'autoriser que rsync :
http://www.inwap.com/mybin/miscunix/?rrsync
On Tue, 12 Jul 2011 04:48:58 -0500, Curious George :
Probleme : comment n'autoriser que svn et pas de login interactif ou meme l'execution de n'importe quelle commande ?
A priori, il ne faut pas passer par SSH. Si tu veux du SSL, tu peux passer soit par HTTPS, soit par stunnel.
Toutefois, si, pour une raison ou une autre, tu dois vraiment utiliser SSH, une solution serait de définir comme shell pour l'utilisateur non pas /bin/bash, mais un script qui n'accepte que les commandes SVN.
Un exemple pour n'autoriser que rsync : http://www.inwap.com/mybin/miscunix/?rrsync
Paul Gaborit
À (at) Tue, 12 Jul 2011 04:48:58 -0500, Curious George écrivait (wrote):
Mais la, pas le droit aux paires de cles, password obligatoire.
Quelle est la (sûrement mauvaise) raison invoquée pour cette demande plutôt surprenante ?
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Tue, 12 Jul 2011 04:48:58 -0500,
Curious George <cg@nowhere.invalid> écrivait (wrote):
Mais la, pas le droit aux paires de cles, password obligatoire.
Quelle est la (sûrement mauvaise) raison invoquée pour cette demande
plutôt surprenante ?
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Tue, 12 Jul 2011 04:48:58 -0500, Curious George écrivait (wrote):
Mais la, pas le droit aux paires de cles, password obligatoire.
Quelle est la (sûrement mauvaise) raison invoquée pour cette demande plutôt surprenante ?
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Che Averell
Paul Gaborit écrit :
Quelle est la (sûrement mauvaise) raison invoquée pour cette demande plutôt surprenante ?
Je parie pour l'excuse habituelle : les développeurs ne connaissent pas unix, alors arrêtez de les faire chier avec un barbarisme que personne comprend. Ou, même encore : si ça ne demande pas de mdp, ce n'est pas sécurisé, tout le monde peut s'y connecter !
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrit :
Quelle est la (sûrement mauvaise) raison invoquée pour cette demande
plutôt surprenante ?
Je parie pour l'excuse habituelle : les développeurs ne connaissent
pas unix, alors arrêtez de les faire chier avec un barbarisme que
personne comprend. Ou, même encore : si ça ne demande pas de mdp, ce
n'est pas sécurisé, tout le monde peut s'y connecter !
Quelle est la (sûrement mauvaise) raison invoquée pour cette demande plutôt surprenante ?
Je parie pour l'excuse habituelle : les développeurs ne connaissent pas unix, alors arrêtez de les faire chier avec un barbarisme que personne comprend. Ou, même encore : si ça ne demande pas de mdp, ce n'est pas sécurisé, tout le monde peut s'y connecter !
Erwan David
Che Averell écrivait :
Paul Gaborit écrit :
Quelle est la (sûrement mauvaise) raison invoquée pour cette demande plutôt surprenante ?
Je parie pour l'excuse habituelle : les développeurs ne connaissent pas unix, alors arrêtez de les faire chier avec un barbarisme que personne comprend. Ou, même encore : si ça ne demande pas de mdp, ce n'est pas sécurisé, tout le monde peut s'y connecter !
Qu'ils ne connaissent pas Unix n'a rien à voir, on fait très bien du ssh depuis un windows.
Mais reste *la* question : dans ce cas, pourquoi ssh ?
Un transport HTTPS pourrait très bien faire l'affaire...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Che Averell <averell@dalton-brothers.org> écrivait :
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrit :
Quelle est la (sûrement mauvaise) raison invoquée pour cette demande
plutôt surprenante ?
Je parie pour l'excuse habituelle : les développeurs ne connaissent
pas unix, alors arrêtez de les faire chier avec un barbarisme que
personne comprend. Ou, même encore : si ça ne demande pas de mdp, ce
n'est pas sécurisé, tout le monde peut s'y connecter !
Qu'ils ne connaissent pas Unix n'a rien à voir, on fait très bien du ssh
depuis un windows.
Mais reste *la* question : dans ce cas, pourquoi ssh ?
Un transport HTTPS pourrait très bien faire l'affaire...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Quelle est la (sûrement mauvaise) raison invoquée pour cette demande plutôt surprenante ?
Je parie pour l'excuse habituelle : les développeurs ne connaissent pas unix, alors arrêtez de les faire chier avec un barbarisme que personne comprend. Ou, même encore : si ça ne demande pas de mdp, ce n'est pas sécurisé, tout le monde peut s'y connecter !
Qu'ils ne connaissent pas Unix n'a rien à voir, on fait très bien du ssh depuis un windows.
Mais reste *la* question : dans ce cas, pourquoi ssh ?
Un transport HTTPS pourrait très bien faire l'affaire...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé