ssh : shell interdit

Le
Thomas
bonjour :-)



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

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fabien LE LEZ
Le #20177771
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 ?
Thomas
Le #20178291
In article Fabien LE LEZ
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

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/
Fabien LE LEZ
Le #20178331
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.
vincent
Le #20179161
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.
Yannick Palanque
Le #20180281
À 2009-09-19T03:25:28+0200,
Fabien LE LEZ
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
Le #20180601
In article Yannick Palanque
À 2009-09-19T03:25:28+0200,
Fabien LE LEZ
> 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 ...

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/
Thomas
Le #20185191
In article Fabien LE LEZ
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"

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/
Fabien LE LEZ
Le #20185221
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.
Thomas
Le #20268361
In article
Thomas
In article Yannick Palanque
> À 2009-09-19T03:25:28+0200,
> Fabien LE LEZ >
> > 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 ...



X11Forwarding no

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/
Thomas
Le #20268891
In article Fabien LE LEZ
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é ...

--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/
Publicité
Poster une réponse
Anonyme