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
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é ...
Sauf sous Debian, mais je suis déjà dehors, très loin.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article
<fantome.forums.tDeContes-2417F2.14444801102009@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
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é ...
Sauf sous Debian, mais je suis déjà dehors, très loin.
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
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é ...
Sauf sous Debian, mais je suis déjà dehors, très loin.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
Thomas
In article , patpro ~ Patrick Proniewski wrote:
In article , Thomas wrote:
> 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é ...
Sauf sous Debian, mais je suis déjà dehors, très loin.
In article <patpro-B79902.14472601102009@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
In article
<fantome.forums.tDeContes-2417F2.14444801102009@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> 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é ...
Sauf sous Debian, mais je suis déjà dehors, très loin.
> 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é ...
Sauf sous Debian, mais je suis déjà dehors, très loin.
> In article > , > Thomas wrote: > > > 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é ... > > Sauf sous Debian, mais je suis déjà dehors, très loin.
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article
<fantome.forums.tDeContes-4ED244.16025201102009@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
In article <patpro-B79902.14472601102009@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
> In article
> <fantome.forums.tDeContes-2417F2.14444801102009@news.free.fr>,
> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
>
> > 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é ...
>
> Sauf sous Debian, mais je suis déjà dehors, très loin.
> In article > , > Thomas wrote: > > > 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é ... > > Sauf sous Debian, mais je suis déjà dehors, très loin.
Ceci dit, sans vouloir relancer la polémique du « à qui la faute », le lien ci-dessus présente les choses d'un façon un peu orientée, qui met en gros toute la faute sur le (les ?) développeur Debian.
J'aurais quand même tendance à dire que la réalité est souvent plus complexe, que c'est souvent une accumulation d'erreurs de provenance diverses qui aboutit à de telles catastrophes, plus qu'une erreur unique et parfaitement identifiable d'une seule personne, et que c'est probablement le cas (la chaine d'erreurs) ici.
Bref, le fait reste que dans l'OpenSSL (ce qui est encore plus grave que si ça touchait juste ssh) livré par Debian pendant un certain temps, il y avait un énorme trou de sécurité, ce qui tend à montrer que le code d'OpenSSL, du moins tel qu'il est livré à certains utilisateurs, n'est pas toujours examiné d'aussi près par des experts en sécurité qu'on pourrait le souhaiter (pour faire le lien avec ce que disait Thomas deux messages plus haut).
Ceci dit, de là à en conclure que puisqu'il y a parfois des problèmes même dans des logiciels réputés bien éprouvés, alors autant les mettre dans le même panier qu'un script maison qu'on a montré à personne, il y a un pas que je me garderai bien de franchir...
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Ceci dit, sans vouloir relancer la polémique du « à qui la faute », le
lien ci-dessus présente les choses d'un façon un peu orientée, qui met
en gros toute la faute sur le (les ?) développeur Debian.
J'aurais quand même tendance à dire que la réalité est souvent plus
complexe, que c'est souvent une accumulation d'erreurs de provenance
diverses qui aboutit à de telles catastrophes, plus qu'une erreur unique
et parfaitement identifiable d'une seule personne, et que c'est
probablement le cas (la chaine d'erreurs) ici.
Bref, le fait reste que dans l'OpenSSL (ce qui est encore plus grave que
si ça touchait juste ssh) livré par Debian pendant un certain temps, il
y avait un énorme trou de sécurité, ce qui tend à montrer que le code
d'OpenSSL, du moins tel qu'il est livré à certains utilisateurs, n'est
pas toujours examiné d'aussi près par des experts en sécurité qu'on
pourrait le souhaiter (pour faire le lien avec ce que disait Thomas deux
messages plus haut).
Ceci dit, de là à en conclure que puisqu'il y a parfois des problèmes
même dans des logiciels réputés bien éprouvés, alors autant les mettre
dans le même panier qu'un script maison qu'on a montré à personne, il y
a un pas que je me garderai bien de franchir...
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Ceci dit, sans vouloir relancer la polémique du « à qui la faute », le lien ci-dessus présente les choses d'un façon un peu orientée, qui met en gros toute la faute sur le (les ?) développeur Debian.
J'aurais quand même tendance à dire que la réalité est souvent plus complexe, que c'est souvent une accumulation d'erreurs de provenance diverses qui aboutit à de telles catastrophes, plus qu'une erreur unique et parfaitement identifiable d'une seule personne, et que c'est probablement le cas (la chaine d'erreurs) ici.
Bref, le fait reste que dans l'OpenSSL (ce qui est encore plus grave que si ça touchait juste ssh) livré par Debian pendant un certain temps, il y avait un énorme trou de sécurité, ce qui tend à montrer que le code d'OpenSSL, du moins tel qu'il est livré à certains utilisateurs, n'est pas toujours examiné d'aussi près par des experts en sécurité qu'on pourrait le souhaiter (pour faire le lien avec ce que disait Thomas deux messages plus haut).
Ceci dit, de là à en conclure que puisqu'il y a parfois des problèmes même dans des logiciels réputés bien éprouvés, alors autant les mettre dans le même panier qu'un script maison qu'on a montré à personne, il y a un pas que je me garderai bien de franchir...
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Thomas
In article , Thomas wrote:
In article , Thomas wrote:
> Protocol 2 > PermitRootLogin no
StrictModes yes
> PubkeyAuthentication yes > HostbasedAuthentication no > PasswordAuthentication no > ChallengeResponseAuthentication no > KerberosAuthentication no > GSSAPIAuthentication no > UsePAM no
GatewayPorts no
X11Forwarding no
UseLogin no UsePrivilegeSeparation yes PermitUserEnvironment no PermitTunnel 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 ...
j'ai re-parcouru le man sshd_config, mais à chaque fois je le fais très rapidement parce que sinon je me cogne sur des trucs que je ne comprend pas et j'arrive pas à aller jusqu'au bout
par exemple je sais pas du tout quels sont les cryptages utilisés, et je ne sais pas lesquels il faudrait et dans quelles circonstances
donc il y a peut être encore des trucs simples qui m'ont échappés
In article
<fantome.forums.tDeContes-5ED8BE.13442801102009@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
In article
<fantome.forums.tDeContes-52F18D.14254319092009@news.free.fr>,
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> Protocol 2
> PermitRootLogin no
StrictModes yes
> PubkeyAuthentication yes
> HostbasedAuthentication no
> PasswordAuthentication no
> ChallengeResponseAuthentication no
> KerberosAuthentication no
> GSSAPIAuthentication no
> UsePAM no
GatewayPorts no
X11Forwarding no
UseLogin no
UsePrivilegeSeparation yes
PermitUserEnvironment no
PermitTunnel 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 ...
j'ai re-parcouru le man sshd_config, mais à chaque fois je le fais très
rapidement parce que sinon je me cogne sur des trucs que je ne comprend
pas et j'arrive pas à aller jusqu'au bout
par exemple je sais pas du tout quels sont les cryptages utilisés, et je
ne sais pas lesquels il faudrait et dans quelles circonstances
donc il y a peut être encore des trucs simples qui m'ont échappés
> PubkeyAuthentication yes > HostbasedAuthentication no > PasswordAuthentication no > ChallengeResponseAuthentication no > KerberosAuthentication no > GSSAPIAuthentication no > UsePAM no
GatewayPorts no
X11Forwarding no
UseLogin no UsePrivilegeSeparation yes PermitUserEnvironment no PermitTunnel 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 ...
j'ai re-parcouru le man sshd_config, mais à chaque fois je le fais très rapidement parce que sinon je me cogne sur des trucs que je ne comprend pas et j'arrive pas à aller jusqu'au bout
par exemple je sais pas du tout quels sont les cryptages utilisés, et je ne sais pas lesquels il faudrait et dans quelles circonstances
donc il y a peut être encore des trucs simples qui m'ont échappés
