[Linux] Permettre le rsh à une ip donnée Fermé

Question

Bonjour.J'ai à ma disposition deux serveurs tournant tous les deux sous Linux Red Hat 9.0 et je voulais savoir comment faire pour que l'un ait accès en rsh à l'autre. Quelle est la procédure pour permettre cela ? Y a-t-il un fichier spécial à remplir ?merci d'avance pour vos infos.Bahan

gbenay · Answer

Bonjour,Si tu as besoin necessairement de rsh (bien que je te conseille ssh, plus securise). il faut que le demon rshd( en general il est pris en charge par inetd ou xinetd) .Si c'est le cas il faut declarer a ce demon de prendre en charge le service"rshd"Dans le cas de xinetdil existe un fichier /etc/xinet.d/rshdet il faut que la ligne disable soit a noservice rsh{        disable = no             socket_type     = stream        ....}pour inet.dil faut -si je me souviens - modifier le fichier /etc/inetd.confpour lui donner les droits de "prendre en charge " le service rshdBon courage

B@|-|@N · Answer

Ok j'ai regardé un peu le ssh et j'ai créé une paire de clef avec l'aide de ssh-keygen. Le truc c'est que je ne sais pas si je suis en ssh 1 ou 2 ? Y a un moyen de le savoir facilement ça ? Quand j'ai créé mes deux clefs, j'ai utilisé comme type rsa1.Actuellement cela marchotte. En fait, ce qui m'ennuie c'est qu'il me demande fatalement un password... Y a pas moyen d'aller directement sur l'ordi distant sans avoir à taper de pass ? Je pensais qu'une fois l'étape des clefs passée c'était bon...De plus, quand je me suis connecté la première fois à l'ordi distant, il m'a dit la chose suivante :[bahan@Minoo bahan]$ ssh -l bahan ip_distanteThe authenticity of host 'ip_distante (ip_distante)' can't be established.RSA key fingerprint is 41:92:5b:a2:24:ca:4a:c5:82:b2:8a:03:ef:58:73:09.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added 'ip_distante' (RSA) to the list of known hosts.bahan@ip_distante's password:Est-ce normal ?Bahan, à galère l'administration ^_^

gbenay · Answer

Bonjour,1/ ssh1 ou ssh2Si tu as pris openssh il a les 2 protocoles, C'est le fichier /etc/ssh/sshd.configqui contient les elements necessaires a la configuration du serveur.Tu dois avoir la ligneProtocol 2,1qui indique que tu fonctionnes avec les 2 protocoles2/voit le man sshd pour comprendre la difference entre les 2 protocoles, (Chiffrement longueur des clefs, ...)3/ pour ne pas retaper le mot de passeIl faut creer sur le serveur un fichier $HOME/.ssh/authorized_keysqui contient la clef public du clientles lignes sont :protocole_chiffrement clef utilisateur@machine_clientou protocole_chiffrement est ssh-rsa (ou ssh-dsa) fait un man ssh pour + d'infos3/ A la premiere connexion le serveur repertorie dans un fichier$HOME/.ssh/known_hostsles clients qui se sont connectes. avec leur nom(ou adresse IP) le protocole, et la clef envoyee.Si le meme client se reconnecte en ayant modifie sa clef, le serveurpeut lui refuser l'acces. (on peut penser que c'est une intrusion par un mauvais client).Attention le fichier "authorized_keys" ne doit  etre lisible" que par le propriétaire C'est a dire droit = -rw-------Pense a regarder les man man ssh etman sshdA+

B@|-|@N · Answer

Merci.1. Protocol 1,2 est enc ommentaire dans sshd.config.J'avais regardé les man de ssh et de ssh-keygen, mais je n'avais pas du tout pensé au fichier de conf.Le truc c'est que j'ai effectivement le fichier authorized_keys en rw sur mon serveur, dont le contenu est le copier-coller du fichier identity.pub de mon client.Et pourtant, rien à faire, il me demande toujours le mot de passe quand je me connecte :ssh -l bahan ipduserveuril me demande le pass...Bahan

B@|-|@N · Answer

Est-ce que le problème peut venir du fait suivant : en gros je ne epsne pas que le nom de mon client, à savoir Minoo soit connu par mon serveur à savoir Toutoo.Or, comme dans le fichier authorized_keys, j'ai bien bahan@Minoo à la fin de la ligne, peut-être qu'il ne comprend pas ?Bahan

gbenay · Answer

Ok,essaie en remplacant le nom Minoo par son adresse ip

B@|-|@N · Answer

Alors j'ai essayé un autre truc :ssh -i /home/bahan/.ssh/identity.pub bahan@ip_toutooet là il me demande bien ma passphrase.Le problème c'est que j'ai beau la taper, il ne la reconnait pas T_T et, après trois essais infructueux, il me demande mon password reT_T.Bahan

[Dal] · Answer

Bahan,Pour ton problème d'échec de mot de passe, voilà ce que dit mon "man ssh" sur l'option -i :-i identity_file             Selects a file from which the identity (private key) for RSA or             DSA authentication is read.  The default is $HOME/.ssh/identity             for protocol version 1, and $HOME/.ssh/id_rsa and             $HOME/.ssh/id_dsa for protocol version 2.C'est donc la clé privée que tu dois fournir à l'option -iSur le problème de la demande du mot de passe... eh bien...  si la clé privée est protégée par un mot de passe, le client ssh va en avoir nécessairement besoin.Pour faire ce que tu veux faire, tu peux utiliser "ssh-agent" (en combinaison avec "ssh-add") qui va gérer sur la machine cliente les clés privées et les mots de passe associés.Vois cet article, qui parle du sujet :http://mah.everybody.org/docs/sshSi c'est trop complexe à mettre en place pour toi, alternativement, tu peux aussi créer une paire de clés non protégées par un mot de passe (tu tapes "entrée" lorsqu'on te demande un mot de passe lors de la création de la clé avec ssh-keygen).Dans tous les cas (et surtout dans ce dernier cas), il faut sécuriser la distribution et révoquer la paire de clés en cas de compromission. Si tu dois distribuer les clés sur plusieurs postes, crée des paires de clés différentes, afin de pouvoir gérer leur révocation indépendamment. Et n'utilise ces connexions que sur des comptes non-privilégiés.S'il y a un moyen de faire autrement pour se passer de la saisie du mot de passe, je suis preneur, car j'en serai très certainement utilisateur :)Dal

B@|-|@N · Answer

Bon, je me broie la tête là.Essayons de récapituler :Voici les lignes de comamnde que je fais :[bahan@Minoo .ssh]$ ssh -l bahan ip_toutooThe authenticity of host 'ip_toutoo (ip_toutoo)' can't be established.RSA key fingerprint is 41:92:5b:a2:24:ca:4a:c5:82:b2:8a:03:ef:58:73:09.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added 'ip_toutoo' (RSA) to the list of known hosts.bahan@ip_toutoo's password: je tape mon pass[bahan@Toutoo bahan]$exit[bahan@Minoo .ssh]$ ssh-keygen -t rsa1Generating public/private rsa1 key pair.Enter file in which to save the key (/home/bahan/.ssh/identity):Enter passphrase (empty for no passphrase):je tape totoEnter same passphrase again: je retape totoYour identification has been saved in /home/bahan/.ssh/identity.Your public key has been saved in /home/bahan/.ssh/identity.pub.The key fingerprint is:1f:a9:b6:ee:33:76:8b:13:48:2c:f6:10:53:3b:01:85 bahan@MinooEnsuite j'ouvre un autre terminal, je me connecte a Toutoo et je copie le contenu de /home/bahan/.ssh/identity.pub (sur Minoo) dans le fichier que je crée /home/bahan/.ssh/authorized_keys (sur Toutoo).Ensuite :[bahan@Minoo .ssh]$ ssh -i /home/bahan/.ssh/identity.pub bahan@ip_toutooEnter passphrase for key '/home/bahan/.ssh/identity.pub':totoEnter passphrase for key '/home/bahan/.ssh/identity.pub':totoEnter passphrase for key '/home/bahan/.ssh/identity.pub':totoomclinux@10.162.36.20's password: et zutJe ne comprends pas... Même en relançant le sreveur sshd que ce soit sur le client ou sur le serveur, cela ne fonctionne pas...Bahan, vais me pendre

[Dal] · Answer

Hmm.. Bahan, nos messages se sont croisés, je crois. As-tu lu mon message ci-dessus ?DalP.S. : ne te pends pas tout de suite ;P

B@|-|@N · Answer

Merci, je vais voir ça.Me disais bien que ce n'était pas le bon fichier.Bahan

B@|-|@N · Answer

Autre petite question :Comment puis-je, dans un script bash,  lancer une commande en ssh et a la demande du mot de passe, lui envoyer automatiquement ?Bahan

B@|-|@N · Answer

Hum hum, j'ai été voir dans le man de ssh_config, et il semblerait qu'en mettant le parametre BatchMode à yes, on n'a pas besoin de mot de passe.Bahan, vais creuser un peu plus

B@|-|@N · Answer

Bon alors j'ai un nouveau problème :Voilà ce que je tape sur mon client pour me connecter à mon serveur :[bahan@Minoo bahan]$ ssh -l bahan -o BatchMode='yes' ip_toutooPermission denied (publickey,password,keyboard-interactive).Pensez-vous que le permission denied vient du fait que je n'ai pas modifié mon fichier /etc/ssh/ssh_config sur mon serveur ?Dois-je ajouter une partie de ce genre :host ip_client BatchMode yes blablabla...Bahan

B@|-|@N · Answer

Après d'autres déboires, j'ai enfin découvert l'option -v et l'option -V.[bahan@Minoo bahan]$ ssh -V -o BatchMode=yes ip_serveurOpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701fEst-ce que cela veut dire que je ne peux pas utiliser du ssh 1, et que je suis obligé d'utiliser la version 2 de ssh ?[bahan@Minoo bahan]$ ssh -v -o BatchMode=yes ip_serveurOpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701fdebug1: Reading configuration data /etc/ssh/ssh_configdebug1: Applying options for *debug1: Rhosts Authentication disabled, originating port will not be trusted.debug1: ssh_connect: needpriv 0debug1: Connecting to ip_serveur [ip_serveur] port 22.debug1: Connection established.debug1: identity file /home/omclinux/.ssh/identity type 0debug1: identity file /home/omclinux/.ssh/id_rsa type -1debug1: identity file /home/omclinux/.ssh/id_dsa type -1debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1debug1: match: OpenSSH_3.5p1 pat OpenSSH*debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_3.5p1debug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug1: kex: server->client aes128-cbc hmac-md5 nonedebug1: kex: client->server aes128-cbc hmac-md5 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug1: dh_gen_key: priv key bits set: 135/256debug1: bits set: 1634/3191debug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYdebug1: Host 'ip_serveur' is known and matches the RSA host key.debug1: Found key in /home/bahan/.ssh/known_hosts:1debug1: bits set: 1573/3191debug1: ssh_rsa_verify: signature correctdebug1: kex_derive_keysdebug1: newkeys: mode 1debug1: SSH2_MSG_NEWKEYS sentdebug1: waiting for SSH2_MSG_NEWKEYSdebug1: newkeys: mode 0debug1: SSH2_MSG_NEWKEYS receiveddebug1: done: ssh_kex2.debug1: send SSH2_MSG_SERVICE_REQUESTdebug1: service_accept: ssh-userauthdebug1: got SSH2_MSG_SERVICE_ACCEPTdebug1: authentications that can continue: publickey,password,keyboard-interactivedebug1: next auth method to try is publickeydebug1: try privkey: /home/bahan/.ssh/id_rsadebug1: try privkey: /home/bahan/.ssh/id_dsadebug1: no more auth methods to tryPermission denied (publickey,password,keyboard-interactive).debug1: Calling cleanup 0x80674d0(0x0)je n'arrive pas à voir ce qui ne va pas...Bahan

[Dal] · Answer

Bahan,debug1: try privkey: /home/bahan/.ssh/id_rsadebug1: try privkey: /home/bahan/.ssh/id_dsadebug1: no more auth methods to tryIl me semble que ton message d'erreur indique que le client ssh ne trouve aucun procédé d'authentification permettant l'accès à la machine, l'authentification par certificat ayant échoué et l'authentification par échange intéractif étant supprimée par ton option "BatchMode=yes".Mettre cette option dans ssh_config ne devrait pas changer grand chose, à mon sens... mais tu peux essayer.En passant, attention à ne pas confondre le mot de passe affecté au compte Unix distant auquel tu te connectes et le mot de passe de déblocage de la clé privée (qui peuvent et *devraient* être différents). Lorsque tu utilises ssh avec l'option "-i" le mot de passe qui t'es demandé est celui attaché au certificat.As-tu consulté : http://mah.everybody.org/docs/ssh ?Dal

[Linux] Permettre le rsh à une ip donnée

16 réponses

Discussions similaires