# Probleme avec ssh



## SuperCed (20 Juin 2002)

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 root@80.14.70.86
root@80.14.70.86'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 (21 Juin 2002)

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 &gt;& /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 (21 Juin 2002)

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 superced@80.14.70.86
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-&gt;client aes128-cbc hmac-md5 none
debug1: kex: client-&gt;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
superced@80.14.70.86'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 -&gt; drain
debug1: channel 0: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -&gt; closed
debug1: channel 0: rcvd close
debug1: channel 0: close_read
debug1: channel 0: input open -&gt; 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 (21 Juin 2002)

<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 (22 Juin 2002)

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


----------



## Anonyme (25 Juin 2002)

<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


----------

