Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux subversion et ssh sans cles

subversion et ssh sans cles

20 réponses
Avatar
Curious George
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 ?

Je suis preneur de toutes piste.

G.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
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.

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
Avatar
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).
Avatar
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 ?

Est-ce que c'est seulement possible ?



Bonjour,

et oui, c'est possible :-)

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-
pty,command="/path/to/svn.sh" ssh-rsa ...

dans les .ssh/authorized_keys

à 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

path=/usr/storapi/bin
# /path/to/cmd arg... => /path/to/cmd
cmd=${SSH_ORIGINAL_COMMAND%% *}
# /path/to/cmd => cmd
cmd=${cmd##*/}
# /path/to/cmd arg... => arg...
args=${SSH_ORIGINAL_COMMAND#* }
args="${args# }"

case ${cmd} in

# symmask)
# pattern='*@(list|discover)*'
# ;;
#
# symcfg)
# pattern='*@(list|discover)*'
#
# if [[ ${args} = *discover* ]]; then
# path=/usr/sbin:/sbin:${path}
#
# case $(uname) in
# AIX)
# precmd='cfgmgr'
# ;;
# HP-UX)
# precmd='ioscan -fnC disk; insf -eC disk'
# ;;
# esac
# fi
# ;;
#
# symdisk|symdrv|symevent|symgate|symmaskdb|symclone|symsnap)
# pattern='*list*'
# ;;
#
# syminq)
# pattern='*'
# ;;
#
# symrdf)
# pattern='*@(list|ping)*'
# ;;
#
# stordaemon|symdev|symlabel|symdg|symld|sympd|symcg|symreplicate)
# pattern='*@(list|show)*'
# ;;
#
# symchg)
# pattern='*@(list|view)*'
# ;;
#
# symconfigure)
# pattern='*@(list|version)*'
# ;;
#
# powermt)
# path=/usr/sbin:/sbin
# pattern='*display*'
# ;;

symdev|symmaskdb)
pattern='*list*'
;;

*)
print -ru2 -- "${SSH_ORIGINAL_COMMAND}: command rejected"
exit 1
;;

esac

if [[ ( -n ${pattern} && ${args} != ${pattern} ) ||
( -z ${pattern} && -n ${args} ) ]]; then
print -ru2 -- "${SSH_ORIGINAL_COMMAND}: bad argument"
exit 1
fi

if [[ -n ${path} ]]; then
export PATH=${path}
fi

if [[ -n ${precmd} ]]; then
eval ${precmd}
fi

unset SSH_ORIGINAL_COMMAND
# was ${cmd} ${args}; exit $?
eval exec ${cmd} ${args}

# eof

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.
Avatar
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 ?

Est-ce que c'est seulement possible ?



Bonjour,

et oui, c'est possible :-)

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-
pty,command="/path/to/svn.sh" ssh-rsa ...

dans les .ssh/authorized_keys

à 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é
Avatar
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 ?

Est-ce que c'est seulement possible ?



Bonjour,

et oui, c'est possible :-)

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-
pty,command="/path/to/svn.sh" ssh-rsa ...

dans les .ssh/authorized_keys

à 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é
Avatar
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
Avatar
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
Avatar
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/>
Avatar
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 !
Avatar
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é
1 2