je sais pas sur les autres OS, mais sous mac os x 10.4, si on crée un
nouvel utilisateur sans lui définir de shell, ça nous met
automatiquement sh :-/
et de toutes façons, ça me parait bien plus sur (et souple) de
configurer sshd pour interdire le shell, plutôt que de le faire au
niveau du système
donc, est ce qu'il y a moyen de configurer sshd pour que le pirate
éventuel ne puisse pas accéder au shell, peu importe ce qui est
configuré au niveau du système ?
peut être avec ForceCommand et un paramètre spécial ?
le pb c'est que le pirate éventuel est quand même un peu en contact avec
le shell, puisqu'il peut choisir le contenu de SSH_ORIGINAL_COMMAND, et
que le shell peut éventuellement avoir une faille par là ...
ce qui serais vachement bien, aussi,
c'est de pouvoir donner une liste de commande,
en sorte que l'utilisateur (celui qui va se connecter au compte via ssh)
ait la possibilité d'exécuter une commande au choix (et éventuellement
aucune)
ça n'est pas ce que fait ForceCommand,
puisqu'il permet 1 seule commande, et en plus il l'exécute de toutes
façons, que l'utilisateur veuille l'exécuter, ou une autre, ou aucune
et de toutes façons, ça me parait bien plus sur (et souple) de configurer sshd pour interdire le shell, plutôt que de le faire au niveau du système
Je pas tout comprendre.
As-tu besoin de sshd ? En d'autres termes, as-tu besoin d'accéder à ta machine depuis l'extérieur ? Si la réponse est "non", désinstalle sshd, et le problème est réglé.
Si tu as effectivement besoin d'accéder à ta machine depuis l'extérieur, c'est pour y faire quoi exactement ?
On Fri, 18 Sep 2009 23:25:26 +0200, Thomas :
et de toutes façons, ça me parait bien plus sur (et souple) de
configurer sshd pour interdire le shell, plutôt que de le faire au
niveau du système
Je pas tout comprendre.
As-tu besoin de sshd ? En d'autres termes, as-tu besoin d'accéder à ta
machine depuis l'extérieur ?
Si la réponse est "non", désinstalle sshd, et le problème est réglé.
Si tu as effectivement besoin d'accéder à ta machine depuis
l'extérieur, c'est pour y faire quoi exactement ?
et de toutes façons, ça me parait bien plus sur (et souple) de configurer sshd pour interdire le shell, plutôt que de le faire au niveau du système
Je pas tout comprendre.
As-tu besoin de sshd ? En d'autres termes, as-tu besoin d'accéder à ta machine depuis l'extérieur ? Si la réponse est "non", désinstalle sshd, et le problème est réglé.
Si tu as effectivement besoin d'accéder à ta machine depuis l'extérieur, c'est pour y faire quoi exactement ?
Thomas
In article , Fabien LE LEZ wrote:
On Fri, 18 Sep 2009 23:25:26 +0200, Thomas :
>et de toutes façons, ça me parait bien plus sur (et souple) de >configurer sshd pour interdire le shell, plutôt que de le faire au >niveau du système
Je pas tout comprendre.
As-tu besoin de sshd ?
oui
Si tu as effectivement besoin d'accéder à ta machine depuis l'extérieur, c'est pour y faire quoi exactement ?
un tunnel TCP (pour ma 1 ere question,) rien d'autre
je sais pas sur les autres OS, mais sous mac os x 10.4, si on crée un nouvel utilisateur sans lui définir de shell, ça nous met automatiquement sh :-/
Sous Linux, ça se configure avec l'option -D de useradd.
donc, est ce qu'il y a moyen de configurer sshd pour que le pirate éventuel ne puisse pas accéder au shell, peu importe ce qui est configuré au niveau du système ?
Sshd avec connexion par mot de passe est assez pénible à configurer. Pour ton cas, je te conseille de supprimer cette possibilité (PasswordAuthentication = no), et donc de n'autoriser que les connexions par clé.
Tu crées ensuite une clé (ssh-keygen), et tu mets la partie publique dans /home/l'utilisateur en question/.ssh/authorized_keys. Si mes souvenirs sont bons, ça te permet une très grande souplesse dans ce que tu autorises l'utilisateur à faire via SSH. Cf http://troy.jdmz.net/rsync/index.html pour un exemple.
Tu peux bien sûr avoir, pour le même utilisateur, plusieurs clés avec des utilisations différentes.
On Fri, 18 Sep 2009 23:25:26 +0200, Thomas :
je sais pas sur les autres OS, mais sous mac os x 10.4, si on crée un
nouvel utilisateur sans lui définir de shell, ça nous met
automatiquement sh :-/
Sous Linux, ça se configure avec l'option -D de useradd.
donc, est ce qu'il y a moyen de configurer sshd pour que le pirate
éventuel ne puisse pas accéder au shell, peu importe ce qui est
configuré au niveau du système ?
Sshd avec connexion par mot de passe est assez pénible à configurer.
Pour ton cas, je te conseille de supprimer cette possibilité
(PasswordAuthentication = no), et donc de n'autoriser que les
connexions par clé.
Tu crées ensuite une clé (ssh-keygen), et tu mets la partie publique
dans /home/l'utilisateur en question/.ssh/authorized_keys. Si mes
souvenirs sont bons, ça te permet une très grande souplesse dans ce
que tu autorises l'utilisateur à faire via SSH. Cf
http://troy.jdmz.net/rsync/index.html pour un exemple.
Tu peux bien sûr avoir, pour le même utilisateur, plusieurs clés avec
des utilisations différentes.
je sais pas sur les autres OS, mais sous mac os x 10.4, si on crée un nouvel utilisateur sans lui définir de shell, ça nous met automatiquement sh :-/
Sous Linux, ça se configure avec l'option -D de useradd.
donc, est ce qu'il y a moyen de configurer sshd pour que le pirate éventuel ne puisse pas accéder au shell, peu importe ce qui est configuré au niveau du système ?
Sshd avec connexion par mot de passe est assez pénible à configurer. Pour ton cas, je te conseille de supprimer cette possibilité (PasswordAuthentication = no), et donc de n'autoriser que les connexions par clé.
Tu crées ensuite une clé (ssh-keygen), et tu mets la partie publique dans /home/l'utilisateur en question/.ssh/authorized_keys. Si mes souvenirs sont bons, ça te permet une très grande souplesse dans ce que tu autorises l'utilisateur à faire via SSH. Cf http://troy.jdmz.net/rsync/index.html pour un exemple.
Tu peux bien sûr avoir, pour le même utilisateur, plusieurs clés avec des utilisations différentes.
vincent
Thomas wrote:
bonjour :-)
bonjour,
ce qui serais vachement bien, aussi, c'est de pouvoir donner une liste de commande, en sorte que l'utilisateur (celui qui va se connecter au compte via ssh) ait la possibilité d'exécuter une commande au choix (et éventuellement aucune)
J'ai souvenir d'un "restricted shell" qui pourrait être ton ami si cela existe encore
-- vincent.
Thomas wrote:
bonjour :-)
bonjour,
ce qui serais vachement bien, aussi,
c'est de pouvoir donner une liste de commande,
en sorte que l'utilisateur (celui qui va se connecter au compte via ssh)
ait la possibilité d'exécuter une commande au choix (et éventuellement
aucune)
J'ai souvenir d'un "restricted shell" qui pourrait être ton ami
si cela existe encore
ce qui serais vachement bien, aussi, c'est de pouvoir donner une liste de commande, en sorte que l'utilisateur (celui qui va se connecter au compte via ssh) ait la possibilité d'exécuter une commande au choix (et éventuellement aucune)
J'ai souvenir d'un "restricted shell" qui pourrait être ton ami si cela existe encore
-- vincent.
Yannick Palanque
À 2009-09-19T03:25:28+0200, Fabien LE LEZ écrivit :
Sshd avec connexion par mot de passe est assez pénible à configurer. Pour ton cas, je te conseille de supprimer cette possibilité (PasswordAuthentication = no), et donc de n'autoriser que les connexions par clé.
« ChallengeResponseAuthentication no » également, voire plutôt (je n'ai jamais bien saisi la subtilité de tout cela...)
-- « Notre époque sans doute, pour celui qui en lira l'histoire dans deux mille ans, ne semblera pas moins laisser baigner certaines consciences tendres et pures dans un milieu vital qui apparaîtra alors comme monstrueusement pernicieux et dont elles s'accommodaient. » Proust, LTr
À 2009-09-19T03:25:28+0200,
Fabien LE LEZ <gramster@gramster.com> écrivit :
Sshd avec connexion par mot de passe est assez pénible à configurer.
Pour ton cas, je te conseille de supprimer cette possibilité
(PasswordAuthentication = no), et donc de n'autoriser que les
connexions par clé.
« ChallengeResponseAuthentication no » également, voire plutôt (je n'ai
jamais bien saisi la subtilité de tout cela...)
--
« Notre époque sans doute, pour celui qui en lira l'histoire dans deux
mille ans, ne semblera pas moins laisser baigner certaines consciences
tendres et pures dans un milieu vital qui apparaîtra alors comme
monstrueusement pernicieux et dont elles s'accommodaient. » Proust, LTr
À 2009-09-19T03:25:28+0200, Fabien LE LEZ écrivit :
Sshd avec connexion par mot de passe est assez pénible à configurer. Pour ton cas, je te conseille de supprimer cette possibilité (PasswordAuthentication = no), et donc de n'autoriser que les connexions par clé.
« ChallengeResponseAuthentication no » également, voire plutôt (je n'ai jamais bien saisi la subtilité de tout cela...)
-- « Notre époque sans doute, pour celui qui en lira l'histoire dans deux mille ans, ne semblera pas moins laisser baigner certaines consciences tendres et pures dans un milieu vital qui apparaîtra alors comme monstrueusement pernicieux et dont elles s'accommodaient. » Proust, LTr
Thomas
In article , Yannick Palanque wrote:
À 2009-09-19T03:25:28+0200, Fabien LE LEZ écrivit :
> Sshd avec connexion par mot de passe est assez pénible à configurer. > Pour ton cas, je te conseille de supprimer cette possibilité > (PasswordAuthentication = no), et donc de n'autoriser que les > connexions par clé.
« ChallengeResponseAuthentication no » également, voire plutôt (je n'ai jamais bien saisi la subtilité de tout cela...)
Protocol 2 PermitRootLogin no PubkeyAuthentication yes HostbasedAuthentication no PasswordAuthentication no ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication no UsePAM no AllowUsers ...
voilà tout ce que je met systématiquement pour bloquer le niveau de sécurité à un minimum j'espère que je n'en oublie pas ...
In article <20090919132538.788b2111@acephale.fr>,
Yannick Palanque <yannick_usenet@palanque.name> wrote:
À 2009-09-19T03:25:28+0200,
Fabien LE LEZ <gramster@gramster.com> écrivit :
> Sshd avec connexion par mot de passe est assez pénible à configurer.
> Pour ton cas, je te conseille de supprimer cette possibilité
> (PasswordAuthentication = no), et donc de n'autoriser que les
> connexions par clé.
« ChallengeResponseAuthentication no » également, voire plutôt (je n'ai
jamais bien saisi la subtilité de tout cela...)
Protocol 2
PermitRootLogin no
PubkeyAuthentication yes
HostbasedAuthentication no
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM no
AllowUsers ...
voilà tout ce que je met systématiquement pour bloquer le niveau de
sécurité à un minimum
j'espère que je n'en oublie pas ...
À 2009-09-19T03:25:28+0200, Fabien LE LEZ écrivit :
> Sshd avec connexion par mot de passe est assez pénible à configurer. > Pour ton cas, je te conseille de supprimer cette possibilité > (PasswordAuthentication = no), et donc de n'autoriser que les > connexions par clé.
« ChallengeResponseAuthentication no » également, voire plutôt (je n'ai jamais bien saisi la subtilité de tout cela...)
Protocol 2 PermitRootLogin no PubkeyAuthentication yes HostbasedAuthentication no PasswordAuthentication no ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication no UsePAM no AllowUsers ...
voilà tout ce que je met systématiquement pour bloquer le niveau de sécurité à un minimum j'espère que je n'en oublie pas ...
>je sais pas sur les autres OS, mais sous mac os x 10.4, si on crée un >nouvel utilisateur sans lui définir de shell, ça nous met >automatiquement sh :-/
Sous Linux, ça se configure avec l'option -D de useradd.
et si on met pas -D ? ça met rien ou qqch ?
>donc, est ce qu'il y a moyen de configurer sshd pour que le pirate >éventuel ne puisse pas accéder au shell, peu importe ce qui est >configuré au niveau du système ?
Sshd avec connexion par mot de passe est assez pénible à configurer.
? tu parles du fait qu'on ne peut pas faire une config par clé ?
Tu crées ensuite une clé (ssh-keygen), et tu mets la partie publique dans /home/l'utilisateur en question/.ssh/authorized_keys. Si mes souvenirs sont bons, ça te permet une très grande souplesse dans ce que tu autorises l'utilisateur à faire via SSH. Cf http://troy.jdmz.net/rsync/index.html pour un exemple.
est ce à dire que pour ma 1ere question, faire un script sh qui se termine aussitôt serait suffisant ?
pour les 2 questions, ça me parait bien plus sur que ça soit directement sshd qui gère l'autorisation d'exécuter des commandes, sous-traiter ça à sh, ça me parait tangent ... pas vous ? ça vous parait normal ??
en fait, ce qui est donné dans l'exemple pour répondre à ma 2eme question, ça m'était deja passé par la tête très rapidement, mais je me suis dit "non, gérer l'interdiction d'exécuter n'importe quelle commande avec sh, quand même, c'est trop gros"
In article <71c8b5dimp53kpor13p2b1lhsg59638r35@4ax.com>,
Fabien LE LEZ <gramster@gramster.com> wrote:
On Fri, 18 Sep 2009 23:25:26 +0200, Thomas :
>je sais pas sur les autres OS, mais sous mac os x 10.4, si on crée un
>nouvel utilisateur sans lui définir de shell, ça nous met
>automatiquement sh :-/
Sous Linux, ça se configure avec l'option -D de useradd.
et si on met pas -D ? ça met rien ou qqch ?
>donc, est ce qu'il y a moyen de configurer sshd pour que le pirate
>éventuel ne puisse pas accéder au shell, peu importe ce qui est
>configuré au niveau du système ?
Sshd avec connexion par mot de passe est assez pénible à configurer.
?
tu parles du fait qu'on ne peut pas faire une config par clé ?
Tu crées ensuite une clé (ssh-keygen), et tu mets la partie publique
dans /home/l'utilisateur en question/.ssh/authorized_keys. Si mes
souvenirs sont bons, ça te permet une très grande souplesse dans ce
que tu autorises l'utilisateur à faire via SSH. Cf
http://troy.jdmz.net/rsync/index.html pour un exemple.
est ce à dire que pour ma 1ere question, faire un script sh qui se
termine aussitôt serait suffisant ?
pour les 2 questions, ça me parait bien plus sur que ça soit directement
sshd qui gère l'autorisation d'exécuter des commandes,
sous-traiter ça à sh, ça me parait tangent ...
pas vous ? ça vous parait normal ??
en fait, ce qui est donné dans l'exemple pour répondre à ma 2eme
question, ça m'était deja passé par la tête très rapidement,
mais je me suis dit "non, gérer l'interdiction d'exécuter n'importe
quelle commande avec sh, quand même, c'est trop gros"
>je sais pas sur les autres OS, mais sous mac os x 10.4, si on crée un >nouvel utilisateur sans lui définir de shell, ça nous met >automatiquement sh :-/
Sous Linux, ça se configure avec l'option -D de useradd.
et si on met pas -D ? ça met rien ou qqch ?
>donc, est ce qu'il y a moyen de configurer sshd pour que le pirate >éventuel ne puisse pas accéder au shell, peu importe ce qui est >configuré au niveau du système ?
Sshd avec connexion par mot de passe est assez pénible à configurer.
? tu parles du fait qu'on ne peut pas faire une config par clé ?
Tu crées ensuite une clé (ssh-keygen), et tu mets la partie publique dans /home/l'utilisateur en question/.ssh/authorized_keys. Si mes souvenirs sont bons, ça te permet une très grande souplesse dans ce que tu autorises l'utilisateur à faire via SSH. Cf http://troy.jdmz.net/rsync/index.html pour un exemple.
est ce à dire que pour ma 1ere question, faire un script sh qui se termine aussitôt serait suffisant ?
pour les 2 questions, ça me parait bien plus sur que ça soit directement sshd qui gère l'autorisation d'exécuter des commandes, sous-traiter ça à sh, ça me parait tangent ... pas vous ? ça vous parait normal ??
en fait, ce qui est donné dans l'exemple pour répondre à ma 2eme question, ça m'était deja passé par la tête très rapidement, mais je me suis dit "non, gérer l'interdiction d'exécuter n'importe quelle commande avec sh, quand même, c'est trop gros"
Oui, le shell par défaut (logique). Typiquement, Bash (mais ça dépend de la distribution).
Sshd avec connexion par mot de passe est assez pénible à configurer.
tu parles du fait qu'on ne peut pas faire une config par clé ?
Une config par utilisateur.
Par définition, la connexion par mot de passe se fait sans clé.
est ce à dire que pour ma 1ere question, faire un script sh qui se termine aussitôt serait suffisant ?
Non : s'il se termine tout de suite, tu n'auras pas le temps d'ouvrir le tunnel. En revanche, /bin/echo devrait convenir parfaitement.
en fait, ce qui est donné dans l'exemple pour répondre à ma 2eme question, ça m'était deja passé par la tête très rapidement, mais je me suis dit "non, gérer l'interdiction d'exécuter n'importe quelle commande avec sh, quand même, c'est trop gros"
Bof... On frise la métaphysique, là. Tant qu'un système fait ce que je veux (et seulement ce que je veux), tout va bien.
Note qu'il y a une grosse différence entre utiliser sh pour exécuter un script prédéfini et autoriser l'utilisateur à interagir avec le shell.
Dans le premier cas, tu lances un script, qui a besoin d'un interpréteur (ça peut être Bash, comme ça peut être Perl ou Python). Ou bien, tu aurais pu coder le même programme en C, et lancer un exécutable natif (sans interpréteur donc).
Dans le deuxième cas, tu autorises l'utilisateur distant à lancer la commande qui lui plaît.
On Sun, 20 Sep 2009 03:45:21 +0200, Thomas :
et si on met pas -D ? ça met rien ou qqch ?
Oui, le shell par défaut (logique). Typiquement, Bash (mais ça dépend
de la distribution).
Sshd avec connexion par mot de passe est assez pénible à configurer.
tu parles du fait qu'on ne peut pas faire une config par clé ?
Une config par utilisateur.
Par définition, la connexion par mot de passe se fait sans clé.
est ce à dire que pour ma 1ere question, faire un script sh qui se
termine aussitôt serait suffisant ?
Non : s'il se termine tout de suite, tu n'auras pas le temps d'ouvrir
le tunnel.
En revanche, /bin/echo devrait convenir parfaitement.
en fait, ce qui est donné dans l'exemple pour répondre à ma 2eme
question, ça m'était deja passé par la tête très rapidement,
mais je me suis dit "non, gérer l'interdiction d'exécuter n'importe
quelle commande avec sh, quand même, c'est trop gros"
Bof... On frise la métaphysique, là.
Tant qu'un système fait ce que je veux (et seulement ce que je veux),
tout va bien.
Note qu'il y a une grosse différence entre utiliser sh pour exécuter
un script prédéfini et autoriser l'utilisateur à interagir avec le
shell.
Dans le premier cas, tu lances un script, qui a besoin d'un
interpréteur (ça peut être Bash, comme ça peut être Perl ou Python).
Ou bien, tu aurais pu coder le même programme en C, et lancer un
exécutable natif (sans interpréteur donc).
Dans le deuxième cas, tu autorises l'utilisateur distant à lancer la
commande qui lui plaît.
Oui, le shell par défaut (logique). Typiquement, Bash (mais ça dépend de la distribution).
Sshd avec connexion par mot de passe est assez pénible à configurer.
tu parles du fait qu'on ne peut pas faire une config par clé ?
Une config par utilisateur.
Par définition, la connexion par mot de passe se fait sans clé.
est ce à dire que pour ma 1ere question, faire un script sh qui se termine aussitôt serait suffisant ?
Non : s'il se termine tout de suite, tu n'auras pas le temps d'ouvrir le tunnel. En revanche, /bin/echo devrait convenir parfaitement.
en fait, ce qui est donné dans l'exemple pour répondre à ma 2eme question, ça m'était deja passé par la tête très rapidement, mais je me suis dit "non, gérer l'interdiction d'exécuter n'importe quelle commande avec sh, quand même, c'est trop gros"
Bof... On frise la métaphysique, là. Tant qu'un système fait ce que je veux (et seulement ce que je veux), tout va bien.
Note qu'il y a une grosse différence entre utiliser sh pour exécuter un script prédéfini et autoriser l'utilisateur à interagir avec le shell.
Dans le premier cas, tu lances un script, qui a besoin d'un interpréteur (ça peut être Bash, comme ça peut être Perl ou Python). Ou bien, tu aurais pu coder le même programme en C, et lancer un exécutable natif (sans interpréteur donc).
Dans le deuxième cas, tu autorises l'utilisateur distant à lancer la commande qui lui plaît.
Thomas
In article , Thomas wrote:
In article , Yannick Palanque wrote:
> À 2009-09-19T03:25:28+0200, > Fabien LE LEZ écrivit : > > > Sshd avec connexion par mot de passe est assez pénible à configurer. > > Pour ton cas, je te conseille de supprimer cette possibilité > > (PasswordAuthentication = no), et donc de n'autoriser que les > > connexions par clé. > > « ChallengeResponseAuthentication no » également, voire plutôt (je n'ai > jamais bien saisi la subtilité de tout cela...)
"également"
chaque commande correspond à une méthode d'authentification différente il faut donc interdire toutes celles pour lesquelles ça peut suffire de deviner le mdp pour pouvoir rentrer, et n'autoriser que celle où il faut deviner la clé privée
Protocol 2 PermitRootLogin no PubkeyAuthentication yes HostbasedAuthentication no PasswordAuthentication no ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication no UsePAM no AllowUsers ...
voilà tout ce que je met systématiquement pour bloquer le niveau de sécurité à un minimum j'espère que je n'en oublie pas ...
In article
<fantome.forums.tDeContes-52F18D.14254319092009@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
In article <20090919132538.788b2111@acephale.fr>,
Yannick Palanque <yannick_usenet@palanque.name> wrote:
> À 2009-09-19T03:25:28+0200,
> Fabien LE LEZ <gramster@gramster.com> écrivit :
>
> > Sshd avec connexion par mot de passe est assez pénible à configurer.
> > Pour ton cas, je te conseille de supprimer cette possibilité
> > (PasswordAuthentication = no), et donc de n'autoriser que les
> > connexions par clé.
>
> « ChallengeResponseAuthentication no » également, voire plutôt (je n'ai
> jamais bien saisi la subtilité de tout cela...)
"également"
chaque commande correspond à une méthode d'authentification différente
il faut donc interdire toutes celles pour lesquelles ça peut suffire de
deviner le mdp pour pouvoir rentrer, et n'autoriser que celle où il faut
deviner la clé privée
Protocol 2
PermitRootLogin no
PubkeyAuthentication yes
HostbasedAuthentication no
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM no
AllowUsers ...
voilà tout ce que je met systématiquement pour bloquer le niveau de
sécurité à un minimum
j'espère que je n'en oublie pas ...
> À 2009-09-19T03:25:28+0200, > Fabien LE LEZ écrivit : > > > Sshd avec connexion par mot de passe est assez pénible à configurer. > > Pour ton cas, je te conseille de supprimer cette possibilité > > (PasswordAuthentication = no), et donc de n'autoriser que les > > connexions par clé. > > « ChallengeResponseAuthentication no » également, voire plutôt (je n'ai > jamais bien saisi la subtilité de tout cela...)
"également"
chaque commande correspond à une méthode d'authentification différente il faut donc interdire toutes celles pour lesquelles ça peut suffire de deviner le mdp pour pouvoir rentrer, et n'autoriser que celle où il faut deviner la clé privée
Protocol 2 PermitRootLogin no PubkeyAuthentication yes HostbasedAuthentication no PasswordAuthentication no ChallengeResponseAuthentication no KerberosAuthentication no GSSAPIAuthentication no UsePAM no AllowUsers ...
voilà tout ce que je met systématiquement pour bloquer le niveau de sécurité à un minimum j'espère que je n'en oublie pas ...
>> Sshd avec connexion par mot de passe est assez pénible à configurer. >tu parles du fait qu'on ne peut pas faire une config par clé ?
Une config par utilisateur.
je te demandais si c'est de ça que tu parlais quand tu disais "Sshd avec connexion par mot de passe est assez pénible à configurer", ou si c'était à cause d'autre chose
>est ce à dire que pour ma 1ere question, faire un script sh qui se >termine aussitôt serait suffisant ?
Non : s'il se termine tout de suite, tu n'auras pas le temps d'ouvrir le tunnel. En revanche, /bin/echo devrait convenir parfaitement.
si si, ça marche très bien, pas besoin du shell pour les tunnels ...
>en fait, ce qui est donné dans l'exemple pour répondre à ma 2eme >question, ça m'était deja passé par la tête très rapidement, >mais je me suis dit "non, gérer l'interdiction d'exécuter n'importe >quelle commande avec sh, quand même, c'est trop gros"
Bof... On frise la métaphysique, là. Tant qu'un système fait ce que je veux (et seulement ce que je veux), tout va bien.
mais quelles notions de sécurité as tu ??
Note qu'il y a une grosse différence entre utiliser sh pour exécuter un script prédéfini et autoriser l'utilisateur à interagir avec le shell.
Dans le premier cas, tu lances un script, qui a besoin d'un interpréteur (ça peut être Bash, comme ça peut être Perl ou Python). Ou bien, tu aurais pu coder le même programme en C, et lancer un exécutable natif (sans interpréteur donc).
Dans le deuxième cas, tu autorises l'utilisateur distant à lancer la commande qui lui plaît.
je reconnais qu'un shell ouvert et un shell avec un script fermé c'est pas du tout pareil, mais là on parle pas de confort utilisateur, on parle de sécurité !!
alors reconnais à ton tour qu'un script qui peut avoir des failles exécuté par un shell qui peut avoir des failles, c'est pas du tout pareil non plus que si tout était fait directement par sshd, lequel est quand même, on peut le supposer, assez surveillé par des gens d'un certain niveau en sécurité ...
In article <hi4bb55ls49sbrctchdj4abhtq2oj8gghb@4ax.com>,
Fabien LE LEZ <gramster@gramster.com> wrote:
On Sun, 20 Sep 2009 03:45:21 +0200, Thomas :
>> Sshd avec connexion par mot de passe est assez pénible à configurer.
>tu parles du fait qu'on ne peut pas faire une config par clé ?
Une config par utilisateur.
je te demandais si c'est de ça que tu parlais quand tu disais "Sshd avec
connexion par mot de passe est assez pénible à configurer", ou si
c'était à cause d'autre chose
>est ce à dire que pour ma 1ere question, faire un script sh qui se
>termine aussitôt serait suffisant ?
Non : s'il se termine tout de suite, tu n'auras pas le temps d'ouvrir
le tunnel.
En revanche, /bin/echo devrait convenir parfaitement.
si si, ça marche très bien,
pas besoin du shell pour les tunnels ...
>en fait, ce qui est donné dans l'exemple pour répondre à ma 2eme
>question, ça m'était deja passé par la tête très rapidement,
>mais je me suis dit "non, gérer l'interdiction d'exécuter n'importe
>quelle commande avec sh, quand même, c'est trop gros"
Bof... On frise la métaphysique, là.
Tant qu'un système fait ce que je veux (et seulement ce que je veux),
tout va bien.
mais quelles notions de sécurité as tu ??
Note qu'il y a une grosse différence entre utiliser sh pour exécuter
un script prédéfini et autoriser l'utilisateur à interagir avec le
shell.
Dans le premier cas, tu lances un script, qui a besoin d'un
interpréteur (ça peut être Bash, comme ça peut être Perl ou Python).
Ou bien, tu aurais pu coder le même programme en C, et lancer un
exécutable natif (sans interpréteur donc).
Dans le deuxième cas, tu autorises l'utilisateur distant à lancer la
commande qui lui plaît.
je reconnais qu'un shell ouvert et un shell avec un script fermé c'est
pas du tout pareil,
mais là on parle pas de confort utilisateur, on parle de sécurité !!
alors reconnais à ton tour qu'un script qui peut avoir des failles
exécuté par un shell qui peut avoir des failles, c'est pas du tout
pareil non plus que si tout était fait directement par sshd, lequel est
quand même, on peut le supposer, assez surveillé par des gens d'un
certain niveau en sécurité ...
>> Sshd avec connexion par mot de passe est assez pénible à configurer. >tu parles du fait qu'on ne peut pas faire une config par clé ?
Une config par utilisateur.
je te demandais si c'est de ça que tu parlais quand tu disais "Sshd avec connexion par mot de passe est assez pénible à configurer", ou si c'était à cause d'autre chose
>est ce à dire que pour ma 1ere question, faire un script sh qui se >termine aussitôt serait suffisant ?
Non : s'il se termine tout de suite, tu n'auras pas le temps d'ouvrir le tunnel. En revanche, /bin/echo devrait convenir parfaitement.
si si, ça marche très bien, pas besoin du shell pour les tunnels ...
>en fait, ce qui est donné dans l'exemple pour répondre à ma 2eme >question, ça m'était deja passé par la tête très rapidement, >mais je me suis dit "non, gérer l'interdiction d'exécuter n'importe >quelle commande avec sh, quand même, c'est trop gros"
Bof... On frise la métaphysique, là. Tant qu'un système fait ce que je veux (et seulement ce que je veux), tout va bien.
mais quelles notions de sécurité as tu ??
Note qu'il y a une grosse différence entre utiliser sh pour exécuter un script prédéfini et autoriser l'utilisateur à interagir avec le shell.
Dans le premier cas, tu lances un script, qui a besoin d'un interpréteur (ça peut être Bash, comme ça peut être Perl ou Python). Ou bien, tu aurais pu coder le même programme en C, et lancer un exécutable natif (sans interpréteur donc).
Dans le deuxième cas, tu autorises l'utilisateur distant à lancer la commande qui lui plaît.
je reconnais qu'un shell ouvert et un shell avec un script fermé c'est pas du tout pareil, mais là on parle pas de confort utilisateur, on parle de sécurité !!
alors reconnais à ton tour qu'un script qui peut avoir des failles exécuté par un shell qui peut avoir des failles, c'est pas du tout pareil non plus que si tout était fait directement par sshd, lequel est quand même, on peut le supposer, assez surveillé par des gens d'un certain niveau en sécurité ...