Il est possible, dans un fichier ~/.ssh/authorized_keys, d'insérer au
début de la ligne d'une clef différentes directives, comme ceci (tiré
quasi-textuellement de la doc de SVN) :
et de restreindre l'usage de cette clef à la seule utilisation de la
commande donnée.
Ma question est : ce "vérouillage" sur la commande est-il assez fort
pour qu'on puisse se permettre d'utiliser une clef sans passphrase ? Je
comprends bien qu'une clef sans passphrase permettra à n'importe qui
ayant cassé le compte client à se connecter illico sur le serveur svn
par ailleurs. Ma question est donc "ouvre-t-on, côté serveur, des portes
ailleurs que sur svnserve dans cet exemple ?"
Le but est bien évidemment, dans le cas de svn, de ne pas avoir à
retaper son mot de passe en permanence.
La question subsidiaire : cette technique (command="...",
no-ceci,no-cela) est-elle plus dangereuse que l'utilisation d'un agent
ssh couplé à keychain côté client ?
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
Eric Lalitte
"btzaf" wrote in message news:453a440f$0$1502$
Ma question est : ce "vérouillage" sur la commande est-il assez fort pour qu'on puisse se permettre d'utiliser une clef sans passphrase ?
C'est presque une question existencielle :-) Si tu dois lancer ta commande sans interaction d'un utilisateur, lors d'un reboot ou pour un cron, tu n'as pas le choix, il faut laisser la clef en clair. Si jamais la session est interactive, il vaut mieux avoir une passphrase à entrer je pense que prendre un risque inutile.
Ma question est donc "ouvre-t-on, côté serveur, des portes ailleurs que sur svnserve dans cet exemple ?"
Si tu n'autorises que l'accès par clefs SSH et qu'il n'y a pas d'autres clefs publiques dans le authorized_keys coté serveur, la seule commande qu'il sera exécutée sera celle que tu auras spécifiée. Tu n'ouvriras donc pas d'autre porte que celle que tu auras spécifiée. Tu peux en plus ajouter dans authorized_keys un from="@IP" qui te permettra de ne donner accès qu'à des machines bien précises (si jamais la clef en clair est volée)
Le but est bien évidemment, dans le cas de svn, de ne pas avoir à retaper son mot de passe en permanence. La question subsidiaire : cette technique (command="...", no-ceci,no-cela) est-elle plus dangereuse que l'utilisation d'un agent ssh couplé à keychain côté client ?
Très bonne question :-) Regardons le cas où on se fait pirater le compte unix incriminé sur le client. Avec la restriction sur la clef, celle-ci est en clair sur le disque, mais ne permet que d'exécuter la commande spécifiée. Dans le cas de l'agent+keychain, on peut d'une par récupérer un accès shell complet, mais en plus dumper la clef privée en mémoire et l'utiliser d'où on voudra...
Je pense que le couplage de ces deux méthodes offre un très bon compromis: - pas de clef en clair sur le disque - restriction à une unique commande et/ou une adresse IP - le mot de passe n'est à entrer qu'une seule fois (il vaut mieux cependant restreindre la durée de la session keychain à une durée fixe)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"btzaf" <btzaf@free.fr> wrote in message
news:453a440f$0$1502$426a74cc@news.free.fr
Ma question est : ce "vérouillage" sur la commande est-il assez fort
pour qu'on puisse se permettre d'utiliser une clef sans passphrase ?
C'est presque une question existencielle :-)
Si tu dois lancer ta commande sans interaction d'un utilisateur, lors
d'un reboot ou pour un cron, tu n'as pas le choix, il faut laisser la
clef en clair.
Si jamais la session est interactive, il vaut mieux avoir une
passphrase à entrer je pense que prendre un risque inutile.
Ma question est donc "ouvre-t-on, côté serveur, des portes
ailleurs que sur svnserve dans cet exemple ?"
Si tu n'autorises que l'accès par clefs SSH et qu'il n'y a pas d'autres
clefs publiques dans le authorized_keys coté serveur, la seule commande
qu'il sera exécutée sera celle que tu auras spécifiée. Tu
n'ouvriras donc pas d'autre porte que celle que tu auras spécifiée.
Tu peux en plus ajouter dans authorized_keys un from="@IP" qui te
permettra de ne donner accès qu'à des machines bien précises (si jamais
la clef en clair est volée)
Le but est bien évidemment, dans le cas de svn, de ne pas avoir à
retaper son mot de passe en permanence.
La question subsidiaire : cette technique (command="...",
no-ceci,no-cela) est-elle plus dangereuse que l'utilisation d'un agent
ssh couplé à keychain côté client ?
Très bonne question :-)
Regardons le cas où on se fait pirater le compte unix incriminé sur le
client.
Avec la restriction sur la clef, celle-ci est en clair sur le disque,
mais ne permet que d'exécuter la commande spécifiée.
Dans le cas de l'agent+keychain, on peut d'une par récupérer un accès
shell complet, mais en plus dumper la clef privée en mémoire et
l'utiliser d'où on voudra...
Je pense que le couplage de ces deux méthodes offre un très bon
compromis:
- pas de clef en clair sur le disque
- restriction à une unique commande et/ou une adresse IP
- le mot de passe n'est à entrer qu'une seule fois (il vaut mieux
cependant restreindre la durée de la session keychain à une durée fixe)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Ma question est : ce "vérouillage" sur la commande est-il assez fort pour qu'on puisse se permettre d'utiliser une clef sans passphrase ?
C'est presque une question existencielle :-) Si tu dois lancer ta commande sans interaction d'un utilisateur, lors d'un reboot ou pour un cron, tu n'as pas le choix, il faut laisser la clef en clair. Si jamais la session est interactive, il vaut mieux avoir une passphrase à entrer je pense que prendre un risque inutile.
Ma question est donc "ouvre-t-on, côté serveur, des portes ailleurs que sur svnserve dans cet exemple ?"
Si tu n'autorises que l'accès par clefs SSH et qu'il n'y a pas d'autres clefs publiques dans le authorized_keys coté serveur, la seule commande qu'il sera exécutée sera celle que tu auras spécifiée. Tu n'ouvriras donc pas d'autre porte que celle que tu auras spécifiée. Tu peux en plus ajouter dans authorized_keys un from="@IP" qui te permettra de ne donner accès qu'à des machines bien précises (si jamais la clef en clair est volée)
Le but est bien évidemment, dans le cas de svn, de ne pas avoir à retaper son mot de passe en permanence. La question subsidiaire : cette technique (command="...", no-ceci,no-cela) est-elle plus dangereuse que l'utilisation d'un agent ssh couplé à keychain côté client ?
Très bonne question :-) Regardons le cas où on se fait pirater le compte unix incriminé sur le client. Avec la restriction sur la clef, celle-ci est en clair sur le disque, mais ne permet que d'exécuter la commande spécifiée. Dans le cas de l'agent+keychain, on peut d'une par récupérer un accès shell complet, mais en plus dumper la clef privée en mémoire et l'utiliser d'où on voudra...
Je pense que le couplage de ces deux méthodes offre un très bon compromis: - pas de clef en clair sur le disque - restriction à une unique commande et/ou une adresse IP - le mot de passe n'est à entrer qu'une seule fois (il vaut mieux cependant restreindre la durée de la session keychain à une durée fixe)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Nicolas George
btzaf wrote in message <453a440f$0$1502$:
Ma question est : ce "vérouillage" sur la commande est-il assez fort pour qu'on puisse se permettre d'utiliser une clef sans passphrase ?
Ça dépend de la commande, et de quelques autres paramètres de configuration. Je ne sais pas ce qu'il en est avec Subversion, mais avec CVS, quelqu'un qui a accès au dépôt peut ajouter des scripts qui seront exécutés sur le serveur lors de certaines opérations.
Il faut également faire attention à la récente possibilité de passer des variables d'environnement du client au serveur. C'est en général désactivé pour tout sauf éventuellement des variables d'environnement inoffensives, mais on ne sait jamais, avec certains programmes, ou certaines fonctionnalités mutantes de la libc.
Je comprends bien qu'une clef sans passphrase permettra à n'importe qui ayant cassé le compte client à se connecter illico sur le serveur svn par ailleurs.
Il faut quand même se rappeler que quelqu'un qui arrive à accéder à un compte peut y laisser des outils pour capturer les mots de passe, par exemple. Ce n'est pas aussi immédiat que simplement copier la clef, et plus visible, mais sur le principe, un compte compromis l'est complètement. Après, tout le reste est une question d'évaluation des risques et des coûts.
btzaf wrote in message <453a440f$0$1502$426a74cc@news.free.fr>:
Ma question est : ce "vérouillage" sur la commande est-il assez fort
pour qu'on puisse se permettre d'utiliser une clef sans passphrase ?
Ça dépend de la commande, et de quelques autres paramètres de configuration.
Je ne sais pas ce qu'il en est avec Subversion, mais avec CVS, quelqu'un qui
a accès au dépôt peut ajouter des scripts qui seront exécutés sur le serveur
lors de certaines opérations.
Il faut également faire attention à la récente possibilité de passer des
variables d'environnement du client au serveur. C'est en général désactivé
pour tout sauf éventuellement des variables d'environnement inoffensives,
mais on ne sait jamais, avec certains programmes, ou certaines
fonctionnalités mutantes de la libc.
Je
comprends bien qu'une clef sans passphrase permettra à n'importe qui
ayant cassé le compte client à se connecter illico sur le serveur svn
par ailleurs.
Il faut quand même se rappeler que quelqu'un qui arrive à accéder à un
compte peut y laisser des outils pour capturer les mots de passe, par
exemple. Ce n'est pas aussi immédiat que simplement copier la clef, et plus
visible, mais sur le principe, un compte compromis l'est complètement.
Après, tout le reste est une question d'évaluation des risques et des coûts.
Ma question est : ce "vérouillage" sur la commande est-il assez fort pour qu'on puisse se permettre d'utiliser une clef sans passphrase ?
Ça dépend de la commande, et de quelques autres paramètres de configuration. Je ne sais pas ce qu'il en est avec Subversion, mais avec CVS, quelqu'un qui a accès au dépôt peut ajouter des scripts qui seront exécutés sur le serveur lors de certaines opérations.
Il faut également faire attention à la récente possibilité de passer des variables d'environnement du client au serveur. C'est en général désactivé pour tout sauf éventuellement des variables d'environnement inoffensives, mais on ne sait jamais, avec certains programmes, ou certaines fonctionnalités mutantes de la libc.
Je comprends bien qu'une clef sans passphrase permettra à n'importe qui ayant cassé le compte client à se connecter illico sur le serveur svn par ailleurs.
Il faut quand même se rappeler que quelqu'un qui arrive à accéder à un compte peut y laisser des outils pour capturer les mots de passe, par exemple. Ce n'est pas aussi immédiat que simplement copier la clef, et plus visible, mais sur le principe, un compte compromis l'est complètement. Après, tout le reste est une question d'évaluation des risques et des coûts.
Thomas Samson
(Xavier) writes:
A noter en outre, que le compte root est le seul, dans l'implémentation actuelle de ssh (*) a pouvoir restreindre le login à uniquement la clé. (PermitRootLogin without-password)
(*) C'est nul, et il ne faut hélas pas espérer que ça change ...
Il y a plusieurs options envisageable pour faire cela ... La solution la plus 'propre' serait d'utiliser pam (il y a beaucoup de choses configurables avec pam)
La solution la plus simple est de ne pas mettre de mot de passe sur le compte (soit de ne pas en specifier, si une commande comme adduser est utilisee sans passwd, soit d'utiliser le 'lock' comme avec usermod -L username)
Ensuite, l'utilisateur ne peut plus utiliser de mot de passe.
Il y a aussi les combinaisons des options UsePAM, ChallengeResponseAuthentication, PasswordAuthentication, ...
-- Thomas Samson "Life, loathe it or ignore it, you can't like it." -- Marvin, "Hitchhiker's Guide to the Galaxy"
xavier@groumpf.org (Xavier) writes:
A noter en outre, que le compte root est le seul, dans l'implémentation
actuelle de ssh (*) a pouvoir restreindre le login à uniquement la clé.
(PermitRootLogin without-password)
(*) C'est nul, et il ne faut hélas pas espérer que ça change ...
Il y a plusieurs options envisageable pour faire cela ...
La solution la plus 'propre' serait d'utiliser pam (il y a beaucoup de
choses configurables avec pam)
La solution la plus simple est de ne pas mettre de mot de passe sur le
compte (soit de ne pas en specifier, si une commande comme adduser est
utilisee sans passwd, soit d'utiliser le 'lock' comme avec usermod -L
username)
Ensuite, l'utilisateur ne peut plus utiliser de mot de passe.
Il y a aussi les combinaisons des options UsePAM,
ChallengeResponseAuthentication, PasswordAuthentication, ...
--
Thomas Samson
"Life, loathe it or ignore it, you can't like it."
-- Marvin, "Hitchhiker's Guide to the Galaxy"
A noter en outre, que le compte root est le seul, dans l'implémentation actuelle de ssh (*) a pouvoir restreindre le login à uniquement la clé. (PermitRootLogin without-password)
(*) C'est nul, et il ne faut hélas pas espérer que ça change ...
Il y a plusieurs options envisageable pour faire cela ... La solution la plus 'propre' serait d'utiliser pam (il y a beaucoup de choses configurables avec pam)
La solution la plus simple est de ne pas mettre de mot de passe sur le compte (soit de ne pas en specifier, si une commande comme adduser est utilisee sans passwd, soit d'utiliser le 'lock' comme avec usermod -L username)
Ensuite, l'utilisateur ne peut plus utiliser de mot de passe.
Il y a aussi les combinaisons des options UsePAM, ChallengeResponseAuthentication, PasswordAuthentication, ...
-- Thomas Samson "Life, loathe it or ignore it, you can't like it." -- Marvin, "Hitchhiker's Guide to the Galaxy"
