Probleme avec ssh

[SuperCed]

Je me connecte en ssh chez moi, mais des que je tapes une commande UNIX, je suis deconnecte.
Pourquoi? Comment je dois faire?

ex :

[localhost:Cedric/mkisofs 1.13/bin] cedric% ssh [email protected]
[email protected]'s password:
Welcome to Darwin!
[localhost:~] root# ls
Connection to 80.14.70.86 closed.
[localhost:Cedric/mkisofs 1.13/bin] cedric%

 

[Membre supprimé 2]

essaie un -v avec ta commande ssh pour en savoir un peu plus sur ce qui se passe.

sinon, peut-être un début d'explications:

---
There is a bug in 10.1.1. that causes the Terminal to logout disgracefully after having logged in (as superuser or other ordinary user) to your own machine using SSH. A "bus error" is the result.

The problem seems to be caused by "klist" that is called by "tcsh" on logout. This is a kerberos program and it calls CCacheServer. Klist crashes with a bus error. The problems will go away by commenting out (i.e. putting a # in front of it) the following line in the file /usr/share/init/tcsh/logout:

if ({ (klist -s >& /dev/null) }) kdestroy

You must do this as admin user using a plain text editor like joe or vi or emacs.
---

dans ton cas, la déconnection n'est pas vraiment "disgracefully" mais comme quoi, il reste encore quelques bugs et que tu es peut-être face à l'un deux.

ta machine 80.14.70.86 a un firewall?

enfin, juste 2 conseils:
ne te connecte pas directement en root par ssh, c'est déja tellement déconseillé en local, alors en remote!...
et créé-toi une clé privé avec pass phrase, tellement plus sûr qu'un password.

 

[SuperCed]

G un firewall oui, mais la, j'ai laisse tous mes ports ouverts pour faire des tests.


Si ca peut t'aider, voila le term :

[localhost:/Volumes/Datas/Cedric] root# ssh -v [email protected]
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 1
debug1: Connecting to 80.14.70.86 [80.14.70.86] port 22.
debug1: restore_uid
debug1: restore_uid
debug1: Connection established.
debug1: identity file /var/root/.ssh/identity type -1
debug1: identity file /var/root/.ssh/id_rsa type -1
debug1: identity file /var/root/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.1p1
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: 119/256
debug1: bits set: 1644/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '80.14.70.86' is known and matches the RSA host key.
debug1: Found key in /var/root/.ssh/known_hosts:3
debug1: bits set: 1603/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: /var/root/.ssh/identity
debug1: try privkey: /var/root/.ssh/id_rsa
debug1: try privkey: /var/root/.ssh/id_dsa
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is password
[email protected]'s password:
debug1: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)
debug1: ssh-userauth2 successful: method password
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Welcome to Darwin!
[localhost:~] superced% ls
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -> closed
debug1: channel 0: rcvd close
debug1: channel 0: close_read
debug1: channel 0: input open -> closed
debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
Connection to 80.14.70.86 closed.
debug1: Transferred: stdin 0, stdout 0, stderr 35 bytes in 50.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.7
debug1: Exit status -1
[localhost:/Volumes/Datas/Cedric] root#

 

[Membre supprimé 2]

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:

Si ca peut t'aider, voila le term :


Et bien écoute, je retiens 2 infos:

debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0

et

debug1: Exit status -1<HR></BLOCKQUOTE>

Perso, j'y vois qu'il y a plantage parce qu'on a un Exit status à -1 au lieu de 0 quand tout va bien.

Le truc bizarre c'est ton client_input_channel_req qui indique un exit-signal au lieu d'un exit-status. Mais je n'arrive pas à avoir la confirmation qu'il s'agit d'une sortie demandé par le client plutôt que par le serveur...

Peux-tu me confirmer deux trucs: tu obtiens une déconnexion quelque soit la commande UNIX employée ou seulement avec LS... j'ai trouvé un gars qui avait le même problème mais qu'avec LS apparemment (voir ici)

2ème truc: obtiens tu une déconnexion si tu attends quelques minutes sans rien faire...


Pour aller plus loin, peux-tu poster ton /etc/ssh_config

Et peux-tu essayer:
- de te connecter à ce serveur avec un autre Mac, ou un Linux
- d'inverser les rôles, c'est à dire passer ton Mac client en serveur SSH et inversement.

 

[SuperCed]

Ca me deconnecte quelque soit la commande.
Ca me deconnecte pas si j'attends quelques minutes...

 

[Anonyme]

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:

debug1: channel 0: is dead
<HR></BLOCKQUOTE>

Ca c est la réponse qui tue tout