SSH terminal locking up from OS X to FreeBSD

[jim@freeze.org]

Hi

I have been having problems when connecting to a FreeBSD
box (4.7-RELEASE-p27 FreeBSD #38) from Mac OS X. The
typical scenario is that I ssh from the OS X box to
the FreeBSD box:

ssh [email]user@myfreebsdbox.com[/email]

After I login, if there is no screen or cursor movement
for a minute or two, the terminal stops responding. The
OS X box is using tcsh and has 'set autologout=0'.

I have tested several machines and here are the results
I am getting:

FROM TO RESULT
==== ===== ======
OS X FBSD lockup
OS X Linux ok
Linux FBSD ok

It looks like an alergic reaction between OS X and FBSD,
but I don't have a clue where to start looking to
track this down.

Any ideas on what this is or how to debug it would be
appreciated.

--
Jim Freeze

[Eric F Crist]

On Feb 22, 2005, at 3:11 PM, [email]jim@freeze.org[/email] wrote:

> Hi
>
> I have been having problems when connecting to a FreeBSD
> box (4.7-RELEASE-p27 FreeBSD #38) from Mac OS X. The
> typical scenario is that I ssh from the OS X box to
> the FreeBSD box:
>
> ssh [email]user@myfreebsdbox.com[/email]
>
> After I login, if there is no screen or cursor movement
> for a minute or two, the terminal stops responding. The
> OS X box is using tcsh and has 'set autologout=0'.
>
> I have tested several machines and here are the results
> I am getting:
>
> FROM TO RESULT
> ==== ===== ======
> OS X FBSD lockup
> OS X Linux ok
> Linux FBSD ok
>
> It looks like an alergic reaction between OS X and FBSD,
> but I don't have a clue where to start looking to
> track this down.

What version of Mac OS X are you using? All of my workstations are Mac
OS X, and all but one server (an old cobalt raq 2) are running FreeBSD
5.3, and I have never seen a problem with using ssh from a terminal to
a FreeBSD system.

Try updating both OSes.

HTH
__________________________________________________ _____
Eric F Crist "I am so smart, S.M.R.T!"
Secure Computing Networks -Homer J Simpson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iEYEARECAAYFAkIbpbkACgkQRAAY9knOW+pCMQCfS1W6DdiaAh QSlgGoWejACg9g
dLEAnRzuFCccfo+yn8UnxmC5Rqx7vs+R
=ygrX
-----END PGP SIGNATURE-----

[jim@freeze.org]

* Eric F Crist <ecrist@secure-computing.net> [2005-02-22 15:35:53 -0600]:

> On Feb 22, 2005, at 3:11 PM, [email]jim@freeze.org[/email] wrote:
>
> What version of Mac OS X are you using? All of my workstations are Mac
> OS X, and all but one server (an old cobalt raq 2) are running FreeBSD
> 5.3, and I have never seen a problem with using ssh from a terminal to
> a FreeBSD system.

OS X is always the latest, currently 10.3.8.
I have no control over the version this
particular FreeBSD system, but this problem has
persisted for several versions of Mac OS X and
FreeBSD.

--
Jim Freeze

[Eric F Crist]

On Feb 22, 2005, at 3:50 PM, [email]jim@freeze.org[/email] wrote:

> * Eric F Crist <ecrist@secure-computing.net> [2005-02-22 15:35:53
> -0600]:
>

>> On Feb 22, 2005, at 3:11 PM, [email]jim@freeze.org[/email] wrote:
>>
>> What version of Mac OS X are you using? All of my workstations are
>> Mac
>> OS X, and all but one server (an old cobalt raq 2) are running FreeBSD
>> 5.3, and I have never seen a problem with using ssh from a terminal to
>> a FreeBSD system.

>
> OS X is always the latest, currently 10.3.8.
> I have no control over the version this
> particular FreeBSD system, but this problem has
> persisted for several versions of Mac OS X and
> FreeBSD.

Does it hang at certain times? Again, across multiple versions of OS X
and FreeBSD, I've never experienced a problem.


__________________________________________________ _____
Eric F Crist "I am so smart, S.M.R.T!"
Secure Computing Networks -Homer J Simpson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iEYEARECAAYFAkIbqlQACgkQRAAY9knOW+rcRwCfWbc2dghZE4 S7SWrhHEYrGaMP
wgEAn2m/H7/VuU9/bwtNB9YzuipLd2zn
=73c5
-----END PGP SIGNATURE-----

[jim@freeze.org]

* Eric F Crist <ecrist@secure-computing.net> [2005-02-22 15:55:32 -0600]:

> Does it hang at certain times? Again, across multiple versions of OS X
> and FreeBSD, I've never experienced a problem.

I haven't found a time that it will not hang after a few
minutes. (Never put a stopwatch to it.)

Your comments that you've never experienced a problem
are similar to a colleague of mine. Either you guys are
not logging into a problem FreeBSD machine or there is
some configuration option that I have/have not set on
my OS X machine.

I'm still puzzled as to how to track it down.

--
Jim Freeze

[Kevin Kinsey]

[email]jim@freeze.org[/email] wrote:

>Hi
>
>I have been having problems when connecting to a FreeBSD
>box (4.7-RELEASE-p27 FreeBSD #38) from Mac OS X. The
>typical scenario is that I ssh from the OS X box to
>the FreeBSD box:
>
> ssh [email]user@myfreebsdbox.com[/email]
>
>After I login, if there is no screen or cursor movement
>for a minute or two, the terminal stops responding. The
>OS X box is using tcsh and has 'set autologout=0'.
>
>I have tested several machines and here are the results
>I am getting:
>
> FROM TO RESULT
> ==== ===== ======
> OS X FBSD lockup
> OS X Linux ok
> Linux FBSD ok
>
>It looks like an alergic reaction between OS X and FBSD,
>but I don't have a clue where to start looking to
>track this down.
>
>Any ideas on what this is or how to debug it would be
>appreciated.
>
>
>

ssh -vvv user@somebox ??

I assume that they haven't removed the verbosity
options from the Mac implementation, have they?

Might show you something ...

Kevin Kinsey

[Chad Leigh -- Shire.Net LLC]

On Feb 22, 2005, at 2:59 PM, [email]jim@freeze.org[/email] wrote:

> * Eric F Crist <ecrist@secure-computing.net> [2005-02-22 15:55:32
> -0600]:
>

>> Does it hang at certain times? Again, across multiple versions of OS
>> X
>> and FreeBSD, I've never experienced a problem.

>
> I haven't found a time that it will not hang after a few
> minutes. (Never put a stopwatch to it.)
>
> Your comments that you've never experienced a problem
> are similar to a colleague of mine. Either you guys are
> not logging into a problem FreeBSD machine or there is
> some configuration option that I have/have not set on
> my OS X machine.
>
> I'm still puzzled as to how to track it down.

I've been logging in to FreeBSD systems from OS X for years without
issue. I currently log into FreeBSD 4.9 and 5.3 from 10.3.5-8 systems.
I have not ever had to do anything strange on the OS X side nor on the
FreeBSD side.

Can you run the FreeBSD sshd daemon in debug mode and see what it spits
out at you when you attempt to log in?

Does this happen with all your OS X machines or just one in particular?

Chad

[Chuck Swiger]

[email]jim@freeze.org[/email] wrote:
[ ... ]

> Your comments that you've never experienced a problem
> are similar to a colleague of mine. Either you guys are
> not logging into a problem FreeBSD machine or there is
> some configuration option that I have/have not set on
> my OS X machine.
>
> I'm still puzzled as to how to track it down.

Are the two machines on the same network segment, or are they remote? Do you
have IPFW rulesets enabled on either, particularly dynamic ones? Running sshd
with -vvv will help, as others have suggested, although you might also
consider running "tcpdump -Xvn host foo and port 22" and see what you see...

--
-Chuck

[David Kelly]

On Tue, Feb 22, 2005 at 09:11:48PM +0000, [email]jim@freeze.org[/email] wrote:

>
> It looks like an alergic reaction between OS X and FBSD,
> but I don't have a clue where to start looking to
> track this down.
>
> Any ideas on what this is or how to debug it would be
> appreciated.

Later in the thread Jim stated he had no control over the version of the
FreeBSD machine. Am guessing he might not have root there. Am guessing
he doesn't know what customizations may have been performed on it.

I have seen similar problems where one end may have been FreeBSD.
Suggest from the MacOS end to try forcing SSH protocol 1 with
"ssh -1 user@othermachine"

If that doesn't work try forcing version 2 with "-2".

Also might try moving ~/.ssh/ out of the way on the Mac to see what
happens if one starts afresh.

--
David Kelly N4HHE, [email]dkelly@HiWAAY.net[/email]
================================================== ======================
Whom computers would destroy, they must first drive mad.

[Eric F Crist]

On Feb 22, 2005, at 3:59 PM, [email]jim@freeze.org[/email] wrote:

> * Eric F Crist <ecrist@secure-computing.net> [2005-02-22 15:55:32
> -0600]:
>

>> Does it hang at certain times? Again, across multiple versions of OS
>> X
>> and FreeBSD, I've never experienced a problem.

>
> I haven't found a time that it will not hang after a few
> minutes. (Never put a stopwatch to it.)
>
> Your comments that you've never experienced a problem
> are similar to a colleague of mine. Either you guys are
> not logging into a problem FreeBSD machine or there is
> some configuration option that I have/have not set on
> my OS X machine.
>
> I'm still puzzled as to how to track it down.

I would take a guess that it's a problem with the FreeBSD 4.7 system,
and it's version of ssh. I have never done any type of config change
of ssh on my OS X system.

HTH
__________________________________________________ _____
Eric F Crist "I am so smart, S.M.R.T!"
Secure Computing Networks -Homer J Simpson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iEYEARECAAYFAkIbt+oACgkQRAAY9knOW+oTFQCgiWHWD1e5+z 1hVWRF+ParQCkA
Ye8Aniup0XxGDdp9NmFaZZlr3gsucLao
=5YN3
-----END PGP SIGNATURE-----

[jim@freeze.org]

* Kevin Kinsey <kdk@daleco.biz> [2005-02-22 16:04:06 -0600]:

> [email]jim@freeze.org[/email] wrote:

> >
> > FROM TO RESULT
> > ==== ===== ======
> > OS X FBSD lockup
> > OS X Linux ok
> > Linux FBSD ok
> >

> ssh -vvv user@somebox ??
>
> I assume that they haven't removed the verbosity
> options from the Mac implementation, have they?
>
> Might show you something ...

Anything in particular I am looking for?

---start log
Script started on Tue Feb 22 16:59:42 2005
user@cheetah 1 /Users/user % ssh -vvv [email]user@remotemachine.org[/email]
OpenSSH_3.6.1p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090702f
debug1: Reading configuration data /etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotemachine.org [123.45.67.89] port 22.
debug1: Connection established.
debug1: identity file /Users/user/.ssh/identity type -1
debug1: identity file /Users/user/.ssh/id_rsa type -1
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p1+CAN-2004-0175
debug3: Trying to reverse map address 123.45.67.89.
debug1: Miscellaneous failure
No credentials cache found

debug1: Miscellaneous failure
No credentials cache found

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 119/256
debug2: bits set: 1582/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /Users/user/.ssh/known_hosts
debug3: key_read: type mismatch
debug3: check_host_in_hostfile: match line 14
debug3: check_host_in_hostfile: filename /Users/user/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 9
debug1: Host 'remotemachine.org' is known and matches the RSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:14
debug2: bits set: 1630/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred external-keyx,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/user/.ssh/identity
debug3: no such identity: /Users/user/.ssh/identity
debug1: Trying private key: /Users/user/.ssh/id_rsa
debug3: no such identity: /Users/user/.ssh/id_rsa
debug1: Trying private key: /Users/user/.ssh/id_dsa
debug3: no such identity: /Users/user/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email]user@remotemachine.org[/email]'s password:
debug3: packet_send2: adding 64 (len 55 padlen 9 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: ssh_session2_setup: id 0
debug1: channel 0: request pty-req
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 8
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 255
debug3: tty_make_modes: 7 255
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 11 25
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 17 255
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 0
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 0
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 1
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 1
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 1
debug3: tty_make_modes: 93 0
debug1: channel 0: request shell
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
Last login: Tue Feb 22 22:58:44 2005 from rrcs-67-78-64-2
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.7-RELEASE-p27 (VKERN) #38: Thu Aug 26 17:44:26 MDT 2004

user@remotemachine 54 /home/user > exit
logout
debug1: client_input_channel_req: channel 0 rtype exit-status 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
debug3: channel 0: will not send data after close
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
debug3: channel_free: status: The following connections are open:\015
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)\015

debug3: channel_close_fds: channel 0: r -1 w -1 e 6
Connection to remotemachine.org closed.
debug1: Transferred: stdin 0, stdout 0, stderr 34 bytes in 5.4 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 6.3
debug1: Exit status 0
user@cheetah 2 /Users/user exit
exit

Script done on Tue Feb 22 17:00:03 2005
---end log

--
Jim Freeze

[jim@freeze.org]

* Chuck Swiger <cswiger@mac.com> [2005-02-22 17:17:09 -0500]:

> Are the two machines on the same network segment, or are they remote? Do
> you have IPFW rulesets enabled on either, particularly dynamic ones?
> Running sshd with -vvv will help, as others have suggested, although you
> might also consider running "tcpdump -Xvn host foo and port 22" and see
> what you see...

The machines are remote. Also, location doesn't seem to matter.
I get the same results when the Mac is on different networks,
wired or wireless.

No IPFW rulesets on this FreeBSD machine. On my old FreeBSD
machine I did have firewall rules enabled, but I got the same
result.

On the Mac, I have the default firewall rules on but allow
ssh connections.

I'll try the tcpdump. Is that command done as follows from the Mac?:

su
tcpdump -Xvn remotemachine.org user and port 22


--
Jim Freeze

[Jim Freeze]

* David Kelly <dkelly@hiwaay.net> [2005-02-22 16:31:43 -0600]:

> Later in the thread Jim stated he had no control over the version of the
> FreeBSD machine. Am guessing he might not have root there. Am guessing
> he doesn't know what customizations may have been performed on it.
>
> I have seen similar problems where one end may have been FreeBSD.
> Suggest from the MacOS end to try forcing SSH protocol 1 with
> "ssh -1 user@othermachine"
>
> If that doesn't work try forcing version 2 with "-2".
>

Thanks, tried both, and they both locked up.

> Also might try moving ~/.ssh/ out of the way on the Mac to see what
> happens if one starts afresh.

This didn't help either.

Thanks for the suggestions, but I'm still stumped. :(

--
Jim Freeze

[pete wright]

On Tue, 22 Feb 2005 23:13:52 +0000, [email]jim@freeze.org[/email] <jim@freeze.org> wrote:
(big snip)
unless i'm missing something you are making the connection then typing
exit in the shell.

> debug1: channel 0: open confirm rwindow 0 rmax 32768
> debug2: channel 0: rcvd adjust 131072
> Last login: Tue Feb 22 22:58:44 2005 from rrcs-67-78-64-2
> Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD 4.7-RELEASE-p27 (VKERN) #38: Thu Aug 26 17:44:26 MDT 2004
>
> user@remotemachine 54 /home/user > exit
> logout

(another big snip)

unless i'm missing something you are making the connection then typing
exit in the shell.

-pete

--
~~o0OO0o~~
Pete Wright
[url]www.nycbug.org[/url]
NYC's *BSD User Group

[Jim Freeze]

* pete wright <nomadlogic@gmail.com> [2005-02-22 15:32:10 -0800]:

> On Tue, 22 Feb 2005 23:13:52 +0000, [email]jim@freeze.org[/email] <jim@freeze.org> wrote:
> (big snip)
> unless i'm missing something you are making the connection then typing
> exit in the shell.

> > debug1: channel 0: open confirm rwindow 0 rmax 32768
> > debug2: channel 0: rcvd adjust 131072
> > Last login: Tue Feb 22 22:58:44 2005 from rrcs-67-78-64-2
> > Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
> > The Regents of the University of California. All rights reserved.
> > FreeBSD 4.7-RELEASE-p27 (VKERN) #38: Thu Aug 26 17:44:26 MDT 2004
> >
> > user@remotemachine 54 /home/user > exit
> > logout

> (another big snip)
>
> unless i'm missing something you are making the connection then typing
> exit in the shell.

For this example, yes. That was the exit to leave the remote host.
I did this just to show that I had successfully logged in. If I
had waited a few minutes, then I would not have been able to show
that because the terminal would have locked up.

--
Jim Freeze

[pete wright]

On Tue, 22 Feb 2005 23:36:40 +0000, Jim Freeze <jim@freeze.org> wrote:

> > unless i'm missing something you are making the connection then typing
> > exit in the shell.

>
> For this example, yes. That was the exit to leave the remote host.
> I did this just to show that I had successfully logged in. If I
> had waited a few minutes, then I would not have been able to show
> that because the terminal would have locked up.
>

hmm...maybe it'll be more helpfull if you wait until it actually
lock's on you and post that info. it also may be a good idea to run a
tcpdump or ethereal (i think one of those utils is built into OSX's
network utilites package) while this is happening. altho hopefully
something interesting will pop up in the ssh debug output. also, are
you able to check the logs on the the server end to see if anything
makes it to there that may be of interest?

HTH

-pete


--
~~o0OO0o~~
Pete Wright
[url]www.nycbug.org[/url]
NYC's *BSD User Group

[Chuck Swiger]

Jim Freeze wrote:
[ ... ]

> For this example, yes. That was the exit to leave the remote host.
> I did this just to show that I had successfully logged in. If I
> had waited a few minutes, then I would not have been able to show
> that because the terminal would have locked up.

Show us what SSH shows when the connection locks up. In particular, try doing
a "<RETURN>~?" after you get the connection lockup and see whether you get a
menu of escape sequences back.

--
-Chuck

[Jim Freeze]

* Chuck Swiger <cswiger@mac.com> [2005-02-22 18:39:35 -0500]:

> [email]jim@freeze.org[/email] wrote:

> >* Chuck Swiger <cswiger@mac.com> [2005-02-22 17:17:09 -0500]:
> >I'll try the tcpdump. Is that command done as follows from the Mac?:
> >
> > su
> > tcpdump -Xvn remotemachine.org user and port 22

>
> Try:
>
> tcpdump -Xvn host remotemachine.org and port 22

Ok, this is what I did from the Mac:

su
tcpdump -Xvn host remotemachine.org and port 22
tcpdump: WARNING: en0: no IPv4 address assigned
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 96 bytes


Then I did from another terminal on the Mac:

script ssh.log
ssh -vvv [email]user@remotemachine.org[/email]

The tcpdump window did not show any activity. Is this correct?

--
Jim Freeze

[Jim Freeze]

* Chuck Swiger <cswiger@mac.com> [2005-02-22 18:43:39 -0500]:

> Jim Freeze wrote:
> Show us what SSH shows when the connection locks up. In particular, try
> doing a "<RETURN>~?" after you get the connection lockup and see whether
> you get a menu of escape sequences back.

Hmm, I never knew about that.
So, I finally got tcpdump working, and after the terminal locks
up, hitting return produces no affect on the command line, but the ssh
connection is still open because I can see data go by on my tcpdump
window. And, I DO get the menu of escape sequences back after typing
"<RETURN>~?", but I was not successful in getting anything to work.
In fact, the tcpdump messages pretty much stopped after a few
key strokes.


--
Jim Freeze

[Chad Leigh -- Shire.Net LLC]

On Feb 22, 2005, at 10:04 PM, Jim Freeze wrote:

> * Chuck Swiger <cswiger@mac.com> [2005-02-22 18:43:39 -0500]:
>

>> Jim Freeze wrote:
>> Show us what SSH shows when the connection locks up. In particular,
>> try
>> doing a "<RETURN>~?" after you get the connection lockup and see
>> whether
>> you get a menu of escape sequences back.

>
> Hmm, I never knew about that.
> So, I finally got tcpdump working, and after the terminal locks
> up, hitting return produces no affect on the command line, but the ssh
> connection is still open because I can see data go by on my tcpdump
> window. And, I DO get the menu of escape sequences back after typing
> "<RETURN>~?", but I was not successful in getting anything to work.
> In fact, the tcpdump messages pretty much stopped after a few
> key strokes.
>

Just for giggles, what happens when you try a different encryption
method with the ssl client? For example, -c blowfish

man ssh for more details

Chad