Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Terminal SSH connects but no password prompt [OS X 10.5.6] -2 support lines can't fix

G

GloStix

macrumors member
Original poster
Jan 8, 2008
38
0
OS X 10.5.6
OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007


Okay, here's the very weird problem.
I need to ssh my server to create some symlinks.
I do ssh user@host
and you'd usually get a password prompt.
I don't get one. it just hangs.

It's not my firewall. I've turned it off and tried.
I've portforwarded port 22 and it doesn't work.
I've tried using a fresh ssh client via macports and it does the same thing.
I've tried deleting my ssh profiles and restarting the daemon and it does the same thing.
Little Snitch shows a connection but it doesn't show a prompt. I don't understand it.

It's not the server because it works on my other mac with the same OS

I've phoned Apple Care Support, First person couldn't give me an answer and transferred me to a 'product specialist' whom told me that he couldn't fix it and suggested that reinstalling my OS might fix it.
I've gone through the my web host support lines and they told me they couldn't fix it either.

I don't know who else to ask. I hope someone here can help.

Screencaptured Video of me trying it:
http://www.screencast.com/t/GwzYlAkqt56

ImageCapture of the end result if you don't like videos:
http://img9.imageshack.us/img9/2204/picture1cvj.png

Here is debugged version of the SSH: (the first password prompt is my sudo)
http://pastie.org/private/w91ajywanpagsailxotnsw
 
Looking at this thread, it suggest deleting the key.

You can also trying adding the v argument to see if it gives any more details,
Code: 
ssh -vvv user@server.com
(with your credentials of course) You can use just one v as well. Each v adds another level of verbosity to the output.

As another note, forwarding port 22 only effects incoming traffic, not outgoing, which is what your ssh command is doing.
 
angelwatt said:
Looking at this thread, it suggest deleting the key.

You can also trying adding the v argument to see if it gives any more details,
Code: 
ssh -vvv user@server.com
(with your credentials of course) You can use just one v as well. Each v adds another level of verbosity to the output.

As another note, forwarding port 22 only effects incoming traffic, not outgoing, which is what your ssh command is doing.
Click to expand...

View the pastie link. I already did that.
 
GloStix said:
Just tried that. Same outcome..
I think it has to do with the actual ssh.
Click to expand...

Check DNS I know you can run into time-out problems if the host you are connecting to is unable to do a reverse name lookup from the system you are connecting from.

Edit: From http://www.openssh.com/faq.html

"3.3 - ssh(1) takes a long time to connect or log in

Large delays (more that 10 seconds) are typically caused a problem with name resolution:

Some versions of glibc (notably glibc 2.1 shipped with Red Hat 6.1) can take a long time to resolve "IPv6 or IPv4" addresses from domain names. This can be worked around with by specifying AddressFamily inet option in ssh_config.
There may be a DNS lookup problem, either at the client or server. You can use the nslookup command to check this on both client and server by looking up the other end's name and IP address. In addition, on the server look up the name returned by the client's IP-name lookup. You can disable most of the server-side lookups by setting UseDNS no in sshd_config."
 
lostngone said:
Check DNS I know you can run into time-out problems if the host you are connecting to is unable to do a reverse name lookup from the system you are connecting from.

Edit: From http://www.openssh.com/faq.html

"3.3 - ssh(1) takes a long time to connect or log in

Large delays (more that 10 seconds) are typically caused a problem with name resolution:

Some versions of glibc (notably glibc 2.1 shipped with Red Hat 6.1) can take a long time to resolve "IPv6 or IPv4" addresses from domain names. This can be worked around with by specifying AddressFamily inet option in ssh_config.
There may be a DNS lookup problem, either at the client or server. You can use the nslookup command to check this on both client and server by looking up the other end's name and IP address. In addition, on the server look up the name returned by the client's IP-name lookup. You can disable most of the server-side lookups by setting UseDNS no in sshd_config."
Click to expand...
This is not a server problem.
I can connect to the same server with the same command with another computer with the same OS.
 
GloStix said:
This is not a server problem.
I can connect to the same server with the same command with another computer with the same OS.
Click to expand...

On/from the server just make sure you can do name look-ups on both clients the same way, forward AND reverse.
 
lostngone said:
On/from the server just make sure you can do name look-ups on both clients the same way, forward AND reverse.
Click to expand...

Well if you look at the verbose debugs(pastie link), it shows that it can resolve the domain to an IP so I think it works. Plus if it helps my case. I can Telnet to my server easily.
 
Do the "ssh -vvv" from the client the ssh connection works from and compare the output to the output of the connection that fails.

What, if anything, is different?

S-
 
sidewinder said:
GloStix,

Uh, you compare them.....this isn't my problem.

S-
Click to expand...

Okay, Well I compared them and I found the spot exactly that MY computer DOESNT have...

Code: 
debug2: key: /var/root/.ssh/identity (0x0)
debug2: key: /var/root/.ssh/id_rsa (0x0)
debug2: key: /var/root/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred 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: /var/root/.ssh/identity
debug3: no such identity: /var/root/.ssh/identity
debug1: Trying private key: /var/root/.ssh/id_rsa
debug3: no such identity: /var/root/.ssh/id_rsa
debug1: Trying private key: /var/root/.ssh/id_dsa
debug3: no such identity: /var/root/.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
glostix1@jameswmann.com's password: 
debug3: packet_send2: adding 48 (len 65 padlen 15 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: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: tty_make_modes: ospeed 9600
debug3: tty_make_modes: ispeed 9600
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 131072
debug2: channel_input_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Wed Mar 25 23:14:35 2009 from modemcable085.118-59-74.mc.videotron.ca
glostix1@jameswmann.com [~]#


Any ideas?
 
I just compiled my own SSH from the source code and it still doesn't work. I don't know what's going on.
 
sidewinder said:
Have you tried forcing version 1 and version 2 to see what happens?

ssh -1

ssh -2


S-
Click to expand...

Doing -1 results in a output of
"Protocol major versions differ: 1 vs. 2"
So I can't use that

and -2 results in the same problem.
 
GloStix said:
Well if you look at the verbose debugs(pastie link), it shows that it can resolve the domain to an IP so I think it works. Plus if it helps my case. I can Telnet to my server easily.
Click to expand...

I did and all I can see from that log is the client can do a forward lookup(name to ip) of the server.

First: You need to do a reverse lookup of the server from the client.

Second: Try an nslookup of the client's name/address from the server(both forward AND reverse lookups).

The only other thing I know of is IPV6 interfering with ssh check the IPV6 settings on both working and non-working clients.
 
I just reinstalled OS X 10.5 with an archive and install option.
It works fine now.
Thanks guys.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back