Anyone know any issue with OS X 10.4 and CentOS with ssh or any connectivity issue with: OpenSSH_3.8.1p1 vs OpenSSH_3.9p1?
On 11/19/05, Ryan Lum cow@launchpc.com wrote:
Anyone know any issue with OS X 10.4 and CentOS with ssh or any connectivity issue with: OpenSSH_3.8.1p1 vs OpenSSH_3.9p1?
No, but you may have slightly different command structure for things like forwarding x apps. But then, if you're experiencing one, it would help if you told us so we didn't have to guess why you're asking.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
Sorry about being unclear.
The issue is I cannot create an openssh session from an tiger box to and centos box. The ssh connection actually connects because it will go ahead and add the id to known_host, however it takes very a long time. I have tested ssh from a xp/putty box and redhat box that lies out side of my network. Odd thing about the whole thing is it worked yesterday. I talked to the admin and he rest bash on the box, and the OS X box was able to connect, but it was still quite slow. After while the lag was long enough to timeout again. Another admin in the datacenter with a mac said he didn't have any problems. Besides recompiling any other ideas?
cow@supercow cow $ssh xxx.xxx.com -l xxx The authenticity of host 'xxxx.com (xxx.xxx.xxx)' can't be established. RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'xxxx.com,xxx.xxx.xxx' (RSA) to the list of known hosts. Connection closed by xxx.xxx.xxx cow@supercow cow $ssh -v OpenSSH_3.8.1p1, OpenSSL 0.9.7g 11 Apr 2005
On 11/19/05 7:58 PM, "Jim Perrin" jperrin@gmail.com wrote:
On 11/19/05, Ryan Lum cow@launchpc.com wrote:
Anyone know any issue with OS X 10.4 and CentOS with ssh or any connectivity issue with: OpenSSH_3.8.1p1 vs OpenSSH_3.9p1?
No, but you may have slightly different command structure for things like forwarding x apps. But then, if you're experiencing one, it would help if you told us so we didn't have to guess why you're asking.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, 2005-11-19 at 21:24 -0600, Ryan Lum wrote:
Sorry about being unclear.
The issue is I cannot create an openssh session from an tiger box to and centos box. The ssh connection actually connects because it will go ahead and add the id to known_host, however it takes very a long time. I have tested ssh from a xp/putty box and redhat box that lies out side of my network. Odd thing about the whole thing is it worked yesterday. I talked to the admin and he rest bash on the box, and the OS X box was able to connect, but it was still quite slow. After while the lag was long enough to timeout again. Another admin in the datacenter with a mac said he didn't have any problems. Besides recompiling any other ideas?
cow@supercow cow $ssh xxx.xxx.com -l xxx The authenticity of host 'xxxx.com (xxx.xxx.xxx)' can't be established. RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'xxxx.com,xxx.xxx.xxx' (RSA) to the list of known hosts. Connection closed by xxx.xxx.xxx cow@supercow cow $ssh -v OpenSSH_3.8.1p1, OpenSSL 0.9.7g 11 Apr 2005
---- user logging in remotely must have a valid shell to be able to do anything after they connect. If for example, as I normally do, give users invalid shells such as /bin/false...they could use ssh to connect, authenticate and get disconnected because they don't have a valid shell. Are you sure you have a valid shell?
Also - sometimes the initial connection will take some time as the sshd server will attempt to verify your hostname via dns
You shouldn't have to do any recompiling.
Craig
Yes, the accounts has been tested on different boxes. As to your second point about the dns. I tried two different computers using the same gateway, xp and os x. The worked like like a charm. I'll probably just end up, upgrading ver of ssh and see how it goes.
user logging in remotely must have a valid shell to be able to do anything after they connect. If for example, as I normally do, give users invalid shells such as /bin/false...they could use ssh to connect, authenticate and get disconnected because they don't have a valid shell. Are you sure you have a valid shell?
Also - sometimes the initial connection will take some time as the sshd server will attempt to verify your hostname via dns
You shouldn't have to do any recompiling.
Craig
On 11/19/05, Ryan Lum cow@launchpc.com wrote:
Sorry about being unclear.
The issue is I cannot create an openssh session from an tiger box to and centos box. The ssh connection actually connects because it will go ahead and add the id to known_host, however it takes very a long time. I have tested ssh from a xp/putty box and redhat box that lies out side of my network. Odd thing about the whole thing is it worked yesterday. I talked to the admin and he rest bash on the box, and the OS X box was able to connect, but it was still quite slow. After while the lag was long enough to timeout again. Another admin in the datacenter with a mac said he didn't have any problems. Besides recompiling any other ideas?
cow@supercow cow $ssh xxx.xxx.com -l xxx The authenticity of host 'xxxx.com (xxx.xxx.xxx)' can't be established. RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'xxxx.com,xxx.xxx.xxx' (RSA) to the list of known hosts. Connection closed by xxx.xxx.xxx cow@supercow cow $ssh -v OpenSSH_3.8.1p1, OpenSSL 0.9.7g 11 Apr 2005
It may be a dns issue. Check to be sure that the machine you're sshing from has an ip that can be resolved via external dns. If this is not the case, the USEDNS value of sshd (which defaults to enabled) will cause slowness, possibly to the point of timing out. You were very close on the ssh -v, but instead, do ssh -v host_you_want_to_ssh_to. this will show the connection attempt messages and any errors along the way. You can do ssh -vv or -vvv for even more verbosity in the reporting.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
On Sat, 2005-11-19 at 21:24 -0600, Ryan Lum wrote:
Sorry about being unclear.
The issue is I cannot create an openssh session from an tiger box to and centos box. The ssh connection actually connects because it will go ahead and add the id to known_host, however it takes very a long time.
Try NiftyTelnet (despite its name it does SSH) http://www.lysator.liu.se/~jonasw/freeware/niftyssh/
and see if it works.
On Sat, 19 Nov 2005, Ryan Lum wrote:
Anyone know any issue with OS X 10.4 and CentOS with ssh or any connectivity issue with: OpenSSH_3.8.1p1 vs OpenSSH_3.9p1?
When communicating with a CentOS box, the Tiger ssh client tries to do Authentication in the order of publickey, gssapi-with-mic, password. When communicating with a Tiger sshd, the Tiger ssh client tries gssapi-with-mic, publickey, gssapi, password, keyboard-interactive.
When communicating with Linux boxes, you'll have better luck by setting the PreferredAuthentications directive in ssh_config (or ~/.ssh/config) to "publickey,keyboard-interactive,password". That works well for me (Tiger client, lots of Linux servers)...
I did the ssh -vvv that jim suggested and seemed to reveal a lot. However, the problem has cleaned up on it's own. I'll have to talk to the unix admin and see if he tweaked anything. However, your gssapi with mic suggestion is correct, and the DNS problems is correct as well. Odd thing is it all works now. My guess is tomorrow it won't work anymore.
cow@supercow cow $ssh -vvv xxxx.com -l xxxx OpenSSH_3.8.1p1, OpenSSL 0.9.7g 11 Apr 2005 debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to papacow.com [xx.xx.xx.xx] port 22. debug1: Connection established. debug1: identity file /Users/cow/.ssh/identity type -1 debug1: identity file /Users/cow/.ssh/id_rsa type -1 debug3: Not a RSA1 key file /Users/cow/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /Users/cow/.ssh/id_dsa type 2 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.8.1p1 debug3: Trying to reverse map address xxx.xxx.xxx.xxx. debug1: An invalid name was supplied Cannot determine realm for numeric host address
debug1: An invalid name was supplied A parameter was malformed Validation error
debug1: An invalid name was supplied Cannot determine realm for numeric host address
debug1: An invalid name was supplied A parameter was malformed Validation error
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,r ijndael-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,r ijndael-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,hm ac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hm ac-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-hellma n-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,r ijndael-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,r ijndael-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,hm ac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hm ac-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(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 134/256 debug2: bits set: 524/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /Users/cow/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /Users/cow/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'papacow.com' is known and matches the RSA host key. debug1: Found key in /Users/cow/.ssh/known_hosts:1 debug2: bits set: 508/1024 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 debug2: key: /Users/cow/.ssh/identity (0x0) debug2: key: /Users/cow/.ssh/id_rsa (0x0) debug2: key: /Users/cow/.ssh/id_dsa (0x300740) debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-with-mic,password debug3: preferred gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we did not send a packet, disable method 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/cow/.ssh/identity debug3: no such identity: /Users/cow/.ssh/identity debug1: Trying private key: /Users/cow/.ssh/id_rsa debug3: no such identity: /Users/cow/.ssh/id_rsa debug1: Offering public key: /Users/cow/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password 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 papacow@papacow.com's password: debug3: packet_send2: adding 48 (len 62 padlen 18 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 debug2: channel 0: request pty-req debug3: tty_make_modes: ospeed 9600 debug3: tty_make_modes: ispeed 9600 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 127 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 20 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 1 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 1 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 0 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: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: channel 0: request shell debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Last login: Sun Nov 20 00:59:11 2005 from
On 11/19/05 10:32 PM, "Paul Heinlein" heinlein@madboa.com wrote:
On Sat, 19 Nov 2005, Ryan Lum wrote:
Anyone know any issue with OS X 10.4 and CentOS with ssh or any connectivity issue with: OpenSSH_3.8.1p1 vs OpenSSH_3.9p1?
When communicating with a CentOS box, the Tiger ssh client tries to do Authentication in the order of publickey, gssapi-with-mic, password. When communicating with a Tiger sshd, the Tiger ssh client tries gssapi-with-mic, publickey, gssapi, password, keyboard-interactive.
When communicating with Linux boxes, you'll have better luck by setting the PreferredAuthentications directive in ssh_config (or ~/.ssh/config) to "publickey,keyboard-interactive,password". That works well for me (Tiger client, lots of Linux servers)...
No problem for me...
CentOS : OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 Tiger: OpenSSH_3.8.1p1, OpenSSL 0.9.7g 11 Apr 2005
On 11/19/05, Ryan Lum cow@launchpc.com wrote:
Anyone know any issue with OS X 10.4 and CentOS with ssh or any connectivity issue with: OpenSSH_3.8.1p1 vs OpenSSH_3.9p1?
-- Howard Fore, howard.fore@gmail.com
Ryan Lum wrote:
Anyone know any issue with OS X 10.4 and CentOS with ssh or any connectivity issue with: OpenSSH_3.8.1p1 vs OpenSSH_3.9p1?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I had a similar problem at work, but any system (Windows, OSX, linux) with an IP address configured with DHCP would take 20 seconds to connect. The problem magically cured itself. IT claimed they didn't do anything before or after that could affect the connection, but I know they'd been upgraded all the switches.
Jeff Montagna jeff.montagna@mac.com wrote:
I had a similar problem at work, but any system (Windows, OSX, linux) with an IP address configured with DHCP would take 20 seconds to connect. The problem magically cured itself. IT claimed they didn't do anything before or after that could affect the connection, but I know they'd been upgraded all the switches.
Sounds like it was caused by DNS lookup (or lack of being able to do so).
-
Bryan J. Smith -
Craig White -
Howard Fore -
Jeff Montagna -
Jim Perrin -
Paul Heinlein -
Ryan -
Ryan Lum