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

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

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 ^_^

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+

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

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

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

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

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

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 zut

Je 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

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

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

Bahan

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

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

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

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

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