Bonjour à tous,

J'ai un truc curieux sur une Suse E10.

Avec 2 machines, une sous linux et une autre sous windows avec putty,
un ssh root@ip fonctionne.

Avec d'autres machines (test avec slack 12, solaris 8 et slack 10.2),
le mot de passe m'est demandé, mais le shell ne se lance pas (ou ne me
donne pas la main). J'ai laissé cuire 5 à 10 minutes, c'est parfois long,
mais pas de prompt.

Je n'ai aucun message, un CTRL-C me redonne la main sur le client.

J'ai testé avec ou sans PAM sans changement.

À partir des clients qui ne fonctionnent pas, un ssh sur un autre utilisateur
fonctionne, qu celui-ci soit dans la base LDAP ou locale.

J'ai tourné la config dans tout les sens, mais je bloque.

Si quelqu'un à une piste à me donner, ce serait sympa.

Pascal

--
La bonne santé n'est que la plus lente des façons de mourir. (Coluche)

* Pascal Bourdais <pbourdais@chez.com>
in fr.comp.os.linux.configuration:
> Je n'ai aucun message, un CTRL-C me redonne la main sur le client.

Une première piste est de tester avec ssh -vvv depuis les clients qui
n'aboutissent pas pour voir où ça bloque...

--
DW

Pascal Bourdais a écrit :
> Bonjour à tous,
>
> J'ai un truc curieux sur une Suse E10.
>
> Avec 2 machines, une sous linux et une autre sous windows avec putty,
> un ssh root@ip fonctionne.
>
> Avec d'autres machines (test avec slack 12, solaris 8 et slack 10.2),
> le mot de passe m'est demandé, mais le shell ne se lance pas (ou ne me
> donne pas la main). J'ai laissé cuire 5 à 10 minutes, c'est parfois long,
> mais pas de prompt.
>
> Je n'ai aucun message, un CTRL-C me redonne la main sur le client.
>
> J'ai testé avec ou sans PAM sans changement.
>
> À partir des clients qui ne fonctionnent pas, un ssh sur un autre utilisateur
> fonctionne, qu celui-ci soit dans la base LDAP ou locale.
>
> J'ai tourné la config dans tout les sens, mais je bloque.
>
> Si quelqu'un à une piste à me donner, ce serait sympa.
>
> Pascal
>

Une requete de reverse dns de la machine sur laquelle tu te connectes en
ssh qui dure un peu trop longtemps ?
As tu essayé en placant l'adresse de la machine à partir de laquelle tu
te connectes dans le fichiers hosts de la machine distante ?

Le Mon, 22 Oct 2007 17:50:03 +0200, Damien Wyart a écrit:
> * Pascal Bourdais <pbourdais@chez.com>
> in fr.comp.os.linux.configuration:
>> Je n'ai aucun message, un CTRL-C me redonne la main sur le client.
>
> Une première piste est de tester avec ssh -vvv depuis les clients qui
> n'aboutissent pas pour voir où ça bloque...
>

Bien vu, un fichier id_rsa qui trainait dans mon repertoire ~/.ssh.

J'ai pris l'habitude, peut-être mauvaise, de faire un ssh-keygen et
de laisser les fichiers id_rsa et id_rsa.pub dans le repertoire ~/.ssh,
jusque là sans soucis ; je vais perdre cette habitude

Je l'ai viré et c'est bon.

C'est curieux que cela ai bloqué le fork du shell sur le serveur.

Merci

PB

--
La bonne santé n'est que la plus lente des façons de mourir. (Coluche)

Le 23 Oct 2007 06:42:46 GMT, Pascal Bourdais a écrit:
> Le Mon, 22 Oct 2007 17:50:03 +0200, Damien Wyart a écrit:
>> * Pascal Bourdais <pbourdais@chez.com>

<...>
Par contre, le problème que j'ai est que je peux plus générer de clé
pour me connecter sans mot de passe.
J'ai passé la serveur en mode débug sans voir de différence.

J'AI TROUVÉ : Le serveur ssh sur SUSE n'installe pas par defaut les
bibliothèques RSA, il faut installer le paquet rsaref.

Je savait bien qu'avec un système windowsé on aurait des problèmes.

Bonne journée.

Pascal

Bonjour,

Le 23 Oct 2007 06:42:46 GMT, Pascal Bourdais a écrit:
> Le Mon, 22 Oct 2007 17:50:03 +0200, Damien Wyart a écrit:
>> * Pascal Bourdais <pbourdais@chez.com>
>> in fr.comp.os.linux.configuration:

>
> Merci
>

Je me penche un peu plus sur le ssh, jusque la, avec slack, on pose et
ça marche.

En fait, ce n'est pas bon : je ne peux plus me connecter sans mot de passe.

J'ai passé le serveur en mode debug, ci dessous, j'ai fait un diff des 2 traces

< = ko
> = ok

154,177c154
< debug1: userauth-request for user root service ssh-connection method publickey^M
< debug1: attempt 1 failures 1^M
< debug2: input_userauth_request: try method publickey^M
< debug1: test whether pkalg/pkblob are acceptable^M
< debug3: mm_key_allowed entering^M
< debug3: mm_request_send entering: type 20^M
< debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED^M
< debug3: monitor_read: checking request 20^M
< debug3: mm_request_receive_expect entering: type 21^M
< debug3: mm_answer_keyallowed entering^M
< debug3: mm_request_receive entering^M
< debug3: mm_answer_keyallowed: key_from_blob: 0x8005d000^M
< debug1: temporarily_use_uid: 0/0 (e=0/0)^M
< debug1: trying public key file /root/.ssh/authorized_keys^M
< debug1: restore_uid: 0/0^M
< debug1: temporarily_use_uid: 0/0 (e=0/0)^M
< debug1: trying public key file /root/.ssh/authorized_keys2^M
< debug1: restore_uid: 0/0^M
< debug3: mm_answer_keyallowed: key 0x8005d000 is disallowed^M
< debug3: mm_request_send entering: type 21^M
< debug3: mm_request_receive entering^M
< debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa^M
< Failed publickey for root from 192.168.1.26 port 38303 ssh2^M
203d179
< debug3: mm_auth_password: user authenticated^M
< Accepted password for root from 192.168.1.26 port 38303 ssh2^M
---
> debug3: mm_auth_password: user authenticated^M
> Accepted password for root from 192.168.1.26 port 38684 ssh2^M


tout semble correct, a part l'essai d'utilisation de la clé rsa.

Si je met une clé rsa1, je n'ai pas de soucis, si je met autre chose
(rsa ou dsa), ça plante.

Merci pour les pistes

Pascal

"Pascal Bourdais" <pbourdais@chez.com> a écrit dans le message de news:
471dcf14$0$22525$426a34cc@news.free.fr...
> Bonjour,
>
> Le 23 Oct 2007 06:42:46 GMT, Pascal Bourdais a écrit:
>> Le Mon, 22 Oct 2007 17:50:03 +0200, Damien Wyart a écrit:
>>> * Pascal Bourdais <pbourdais@chez.com>
>>> in fr.comp.os.linux.configuration:
>
>>
>> Merci
>>
>
> Je me penche un peu plus sur le ssh, jusque la, avec slack, on pose et
> ça marche.
>
> En fait, ce n'est pas bon : je ne peux plus me connecter sans mot de
> passe.
>
> J'ai passé le serveur en mode debug, ci dessous, j'ai fait un diff des 2
> traces
>
> < = ko
>> = ok
>
> 154,177c154
> < debug1: userauth-request for user root service ssh-connection method
> publickey^M
> < debug1: attempt 1 failures 1^M
> < debug2: input_userauth_request: try method publickey^M
> < debug1: test whether pkalg/pkblob are acceptable^M
> < debug3: mm_key_allowed entering^M
> < debug3: mm_request_send entering: type 20^M
> < debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED^M
> < debug3: monitor_read: checking request 20^M
> < debug3: mm_request_receive_expect entering: type 21^M
> < debug3: mm_answer_keyallowed entering^M
> < debug3: mm_request_receive entering^M
> < debug3: mm_answer_keyallowed: key_from_blob: 0x8005d000^M
> < debug1: temporarily_use_uid: 0/0 (e=0/0)^M
> < debug1: trying public key file /root/.ssh/authorized_keys^M
> < debug1: restore_uid: 0/0^M
> < debug1: temporarily_use_uid: 0/0 (e=0/0)^M
> < debug1: trying public key file /root/.ssh/authorized_keys2^M
> < debug1: restore_uid: 0/0^M
> < debug3: mm_answer_keyallowed: key 0x8005d000 is disallowed^M
> < debug3: mm_request_send entering: type 21^M
> < debug3: mm_request_receive entering^M
> < debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa^M
> < Failed publickey for root from 192.168.1.26 port 38303 ssh2^M
> 203d179
> < debug3: mm_auth_password: user authenticated^M
> < Accepted password for root from 192.168.1.26 port 38303 ssh2^M
> ---
>> debug3: mm_auth_password: user authenticated^M
>> Accepted password for root from 192.168.1.26 port 38684 ssh2^M
>
>
> tout semble correct, a part l'essai d'utilisation de la clé rsa.
>
> Si je met une clé rsa1, je n'ai pas de soucis, si je met autre chose
> (rsa ou dsa), ça plante.
>
> Merci pour les pistes
>
> Pascal

Qu'y a-t-il dans /etc/ssh/ssh_config
Ce fichier est la config du client (chez Mandriva)

Voici le mien :
Host *
ForwardX11 yes
ForwardX11Trusted yes
Protocol 2,1
StrictHostKeyChecking no

Les lignes Protocol et StrictHostKeyChecking doivent être différentes chez
toi si seule rsa1 fonctionne ...

pmxk

Bonjour et merci à ceux qui se sont penché sur mon problème.


Le Tue, 23 Oct 2007 20:44:37 +0200, pmxk a écrit:
> "Pascal Bourdais" <pbourdais@chez.com> a écrit dans le message de news:
> 471dcf14$0$22525$426a34cc@news.free.fr...
>> Bonjour,
>>
>> Le 23 Oct 2007 06:42:46 GMT, Pascal Bourdais a écrit:
>>> Le Mon, 22 Oct 2007 17:50:03 +0200, Damien Wyart a écrit:
>>>> * Pascal Bourdais <pbourdais@chez.com>
>>>> in fr.comp.os.linux.configuration:
>>
>>>
>>
>> Je me penche un peu plus sur le ssh, jusque la, avec slack, on pose et
>> ça marche.
>>

J'ai trouvé le problème, je ne pige pas pourquoi ça réagit comme ça,
mais j'ai résolu le truc (enfin j'espère).

J'ai mis en place l'authentification sur LDAP, après config, le démon
nscd partait en vrac et bouffait toutes les ressources machines, je l'ai
donc arrété.

Si je le demarre, l'authentification ssh fonctionne, si je ne le demarre
pas, ça ne fonctionne pas pour root.

Je l'ai redémarré avec une mise en cache des groupes uniquement, le
reste ne semble pas avoir d'influence sur ssh.

Je continue de creuser, je subodore une c...e dans la config pam/ldap.

Pascal


--
La bonne santé n'est que la plus lente des façons de mourir. (Coluche)