Curiosité ssh

Le
Pascal Bourdais
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)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Damien Wyart
Le #1904321
* Pascal Bourdais 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

oLaFKeWL
Le #1904320
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 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 ?

pmxk
Le #1904292
"Pascal Bourdais" 471dcf14$0$22525$
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 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



Pascal Bourdais
Le #1904270
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" 471dcf14$0$22525$
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 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)




Publicité
Poster une réponse
Anonyme