Petit pb de configuration de xinetd

Support Debian
#1

Hello tout le monde… :smiley:

je suis en train de monter un serveur. De base, j’ai inetd.conf comme superdémon et, souhaitant découvrir les larges possibilités de xinetd, j’ai voulu l’installer…

bon, l’install elle-même, pas de soucis. Je n’ai pas indiqué de configuration par défaut (une erreur? Une nécessité?), par contre, j’ai configuré deux services, pour l’instant : ssh (port 22, configuré sur la livebox après avoir préciser à quel adresse se trouvait le serveur) et samba (port 139, service netbios-ssn - et non pas “samba” ou “smb”, contrairement à ce que j’aurais initialement cru. Sauf que c’est normal puisque smb est un protocole de communication et non simplement un service… bon, l’erreur est humaine).

Au niveau de ssh, j’ai paramétré deux hostnames (pour pouvoir travailler via putty, à distance, à partir de deux ordi différents), via la commande “only_from”. J’ai ensuite alimenté /etc/hosts en y ajoutant les hostsname respectifs et les adresses ip fixes corresondantes. Pour faire dans le quasi concret, j’ai qq chose comme :

192.x.y.z chris
192.x.y.b posteB

Or, c’est là que je ne pige pas… Si je change l’adresse IP fixe du client posteB, disons en 192.x.y.c, je peux toujours me connecter au serveur via ssh. Et… Pire, si je commente carrément la ligne, c’est la même chose.

Ce qui veut dire, je pense, que d’une façon ou d’une autre, soit xinetd n’est pas lancé (et pourtant, il apparait partout : dans /etc/services, dans init.d, dans les rc.d… etc…), soit il y a un autre pb de configuration.

Donc, pour résumer, j’ai deux questions (enfin… un peu plus, finalement) : quel est le pb? et est ce que par hasard, après avoir installé xinetd, il ne faut pas faire un update-rc -f inetd remove pour faire sauter le démarrage du service inetd au boot du serveur (comme je l’ai fait pour gdm, par exemple). En effet, je me dis que peut-être inetd et xinetd sont en qq sorte en conflit… ou bien que la config d’inetd prime sur celle de xinetd… Ou encore, dans le cas tout à fait inverse, il faudrait que je configure qq chose de plus au niveau de inetd de façon à ce que les configurations de xinetd soient prises en compte.

Et bien sûr, il y a la possibilité pour moi d’avoir oublié qq chose d’important, auquel je ne pense pas…

So??? Une idée?

Supermerci d’avance! :smiley: :smiley: :smt003

#2

Hello,

Eh bien, personne n’a d’idée? Ou personne ne connait la config de xinetd? (rhooooooo mauvaise langue, lol - je plaisante).

#3

Dernière tentative… lol. Personne connait xinetd? :smiley:

#4

Ca sert a rien de mettre les ip dans /etc/host, a par pour faire la resolution en local. Si tu veux pas que tel ip se connecte sur ta machine ajoute l’ip dans /etc/hosts.deny.

#5

Tu es sûr que sshd est lancé via xinetd? Vérifie qu’il n’y a pas de démon (en local bien sûr, pas via ssh :slightly_smiling:). Sinon, tu n’as pas complètement tort, inetd suffit largement à mes besoins et je n’ai jamais utilisé xinetd.
Joue effectvievement avec /etc/host.allow et /etc/host.deny si c’est comme inetd…

#6

Ah, fran.b… Salut! Merci pour ta réponse (et merci à toi, bloodaxe, bien sûr)

“Tu es sûr que sshd est lancé via xinetd?”

Justement… Comment tu peux le vérifier? Voilà quelque chose qui me serait bien utile! :slightly_smiling: Le truc, c’est qu’inetd est toujours installé, mais je ne sais pas s’il bosse avec xinetd, s’ils se complète, ou si inetd, installé de base, prend de toute façon le pas sur xinetd. Cependant, inetd n’est pas, à proprement parlé, configuré, tout (c’est à dire pas grand chose, en l’occurence, vu qu’il y a grosso modo cinq lignes) étant commenté.

Techniquement, je pourrais me contenter d’inetd, je suis d’accord, bien sûr, mais xinetd comporte pas mal d’options qui me paraissaient intéressant de savoir utiliser dans un cadre professionnel. Mon but étant d’apprendre, j’ai estimé intéressant de poser un xinetd en tant que superdémon dans ma distro.

“Joue effectvievement avec /etc/host.allow et /etc/host.deny si c’est comme inetd…”

Oui, je vais jeter un oeil. Bon… Cependant, que ce soit /etc/hosts, /etc/hosts.deny et /etc/hosts.allow, ca ne peut marcher que pour les IP fixes, non? So, admettons que je mette deux des trois ordinateurs dans “allow” (dans la section relative à la partie sshd) et que j’inscrive les deux en question dans “only_from”, ca me permettra bien de faire en sorte que seuls ces derniers puissent être utilisés pour administrer mon serveur à distance? J’interprète bien la situation? En tout cas, c’est le genre de truc que j’aimerais réussir à faire avec Xinetd.

bloodaxe70 “Ca sert a rien de mettre les ip dans /etc/host, a par pour faire la resolution en local”.

Oui, tu as raison, naturellement… En fait, j’avais paramétré /etc/host avec le nom de la machine et l’IP correspondante, puis alimenté ma section “sshd” dans xinetd.conf en mettant le nom des bécanes qui m’intéressaient (le mien et le poste qui physiquement se trouve à côté du serveur). L’idée, c’est qu’ainsi, je pensais que les IP correspondante aux noms indiqués dans la partie only_from puissent servir pour administrer le serveur à distance. Mais ca n’a pas l’air de marcher comme ça…

“Si tu veux pas que tel ip se connecte sur ta machine ajoute l’ip dans /etc/hosts.deny.”

Ok, je vois le truc. Cependant, comment ça se passe pour les IP fournie en dhcp? On peut y mettre une étendue? Ca me parait étonnant (mais c’est peut-être possible, je le reconnais. Etant parti du postulat que ce n’était pas possible, je n’ai pas poussé la vérification plus que ça). Bon… faudrait que je fasse une petite recherche sur le web, là.

Petite question subsidiaire… J’ai bien configuré le fichier smb.conf. J’ai un client, moi-même, qui fonctionne nickel. Par contre, quand je rajoute une personne (son nom de connexion sur la machine + son mot de passe) en faisant un smbpasswd -a, ca “failed”. Je n’ai pas encore tout testé… mais je n’en vois pas la raison. Je me suis dit que peut-être, il fallait les créer en tant qu’utilisateur du serveur au préalable (adduser) puis les bouger dans le même groupe que ma petite personne? (à savoir le groupe “christian”, pour l’instant). Ou y aurait-il une autre raison possible?

Thank U à tous!
:smiley: :smiley:

#7

Ah, et au passage… Je cherche du boulot dans l’administration info dans la région parisienne (ou des conseils à me refiler)… si qq a une info à me refiler, ca pourrait m’intéresser… :smiley:

#8

Je répond rapidement (car absent de chez moi), pour savoir qui prend en charge le port ssh par exemple, tu fais

netstat -tpl

cela te donnera les ports en écoute et les processus qui écoute sur ces ports.

Pour smb, dans la configuration par défaut, il faut que les personnes aient un compte sur le serveur donc oui, tu les crées avec comme shell /bin/false par exemple.

#9

Multipass:/etc/init.d# netstat -plt
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 *:nfs : LISTEN -
tcp 0 0 *:netbios-ssn : LISTEN 21587/smbd
tcp 0 0 *:622 : LISTEN 2563/rpc.mountd
tcp 0 0 *:sunrpc : LISTEN 2039/portmap
tcp 0 0 *:4496 : LISTEN -
tcp 0 0 *:auth : LISTEN 2573/inetd
tcp 0 0 *:1047 : LISTEN 2648/rpc.statd
tcp 0 0 localhost:ipp : LISTEN 2406/cupsd
tcp 0 0 localhost:postgresql : LISTEN 2305/postmaster
tcp 0 0 localhost:smtp : LISTEN 2520/exim4
tcp 0 0 *:microsoft-ds : LISTEN 21587/smbd
tcp6 0 0 *:ssh : LISTEN 27562/sshd

Ok… quand je fais netstat -plt, j’ai le résultat ci-dessus… xinetd ne figure pas dans le tas. Y a qq chose que je n’ai pas dû configurer quelque part…

#10

Opps je crois que j’ai pigé… Je vais tenter le truc ce soir…

Si, et je dis bien “si” j’ai bien compris, en réalité, il faut désactiver les services dont le démarrage sera pris en compte par xinetd… En réalié, xinetd se positionne sur les ports d’écoute, disons le port 22, dans le cas de sshd. Si ledit service est démarrer, il ne pourra pas le faire. Et dès lors que l’on fait appel au service en question, “charge le service en mémoire et le colle sur le port”, pour reprendre l’explication que j’ai trouvé sur la toile… Je rentrerai dans des explications plus complètes plus tard si le problème se situe là. En tout cas, ca expliquerait effectivement bien pourquoi le port d’écoute - enfin, le service lui-même - de xinetd n’apparait pas dans les processus lorsque je fais le netstat -plt. En principe, si tout fonctionne, en refaisant un netstat, je devrais non plus voir sshd sur le port 22 mais xinetd…

On va voir ça tout à l’heure… Croisons les doigts.

(Cela dit, si qq l’a déjà fait avant, ca m’intéresserait de savoir si je suis sur la bonne piste).

#11

Fais un

touch /etc/ssh/sshd_not_to_be_run

#12

Ok… je vais le faire… demain : mon serveur a pété un plomb… le SGF de /dev/mapper/mon_serveur-home a sauté sur Samba. je l’ai plus ou moins réparé avec les outils fdisk et cie (j’ai galéré pour plus ou moins comprendre comment ils fonctionnaient, mais bon… c’était un bon exercice) mais c’est /dev/sda1 qui a merdé a la suite… du coup, j’ai préféré réinstaller l’ensemble du bazar, en simple ext3.

Cela dit, ca m’a déjà fait ça une fois auparavant. Faut savoir que j’ai désactié l’interface graphique, bien qu’initialement installé (autrement dit j’ai fait un /etc/init.d gdm stop, avant de faire un update-rc.d -f gdm remove). J’ai juste à lancer le startx pour le récupérer en cas de besoin… sauf que les trois fois ou je l’ai fait, l’ordi, il m’a jeté des pierres, ensuite, et de la même façon que décrit ci-dessus… Pour l’instant j’ai tout laissé en mode graphique, mais au passage, tu sais à quoi ce plantage peut être dû?

Autrement, pour le touch, je m’en occupe demain, même si - pour l’instant, puisque je n’ai pas eu le temps de regarder - je ne vois pas bien ce que la création d’un fichier vide apportera. J’imagine que celui-là a qq chose de particulier?

Cela étant…

Merci pour le coup de main, comme d’hab’