Can't ssh from linux, but can from windows?
 

I have a windows pc and a linux pc connected to the same router. I also have a remote linux web server.

On the windows pc I can run putty and connect to my remote webserver, no problem.

If I try to do the same on the linux pc, it times out.

1. The linux pc can ssh to other remote servers, no problem.
2. I ran a dig on the domain name, from the linux pc, and it has no problem resolving the remote server's address. (I also tried sshing directly to the ip address, no good.)
3. The linux pc is able to ping the remote server, 64ms response time.
4. There is nothing in the hosts.allow / hosts.deny on the remote server (it was just set up this week), and even if there was- both my pc and my local linux server are behind the same router on my desk.

Bizaarrre????

Could it be some kind of version thing between the ssh client and the ssh daemon on the remote server?

(local linux pc)# ssh -V
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

The remote server is running CentOS 4.3

Help!

That is bizarre. It could be a version problem, or perhaps a protocol problem. Try connecting with the verbose option (ssh -v hostname.remote.machine) and see what kind of output you get.

Do you have anything on the local linux machine that might prevent the connection? Any rules set up in iptables? Can you ssh with putty from the Windows box to the local linux box?

oh good idea, here is -v :

# ssh -v lt.(mydomain).com
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to lt.(mydomain).com [(server's ip address)] port 22.
ssh: connect to host lt.(mydomain).com port 22: Connection timed out

Yes I can ssh with putty from the windows box to the linux box (actually thats thats the only way I use the linux box at all, no monitor/kbd plugged into it).

I can't imagine what I could have in ip tables to stop the local linux box from connecting. I actually ssh to remote servers all the time, I never had to set anything special up for them.

Hmmm. Assuming your router is forwarding traffic on port 22 the same to both PCs (which you should check), it would appear that the connection ought to be possible.

How about a look at /etc/ssh/sshd_config on the remote server? Do you have access to that?

Well port forwarding is for opening inbound connections. But in any case, I can ssh to other remote servers, from either putty or the linux box, no problem. So I figure my router isn't generally getting in the way of ssh?

Here is the stuff in /etc/ssh/sshd_config on the remote server that's not commented out:


SyslogFacility AUTHPRIV
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server

Do you have ssh set up to deny hosts or only accept from certain IPs? I think you can set the /etc/hosts.allow file for incoming connections, although that may be just for telnet and r* commands. Have you tried using the IP address instead of the hostname? I see your verbose ssh has both hostname and IP but I'm wondering if taking the name resolution out fixes anything. I've also had a problem with *nix boxes caching keys then having problems connecting if anything changes on the other end, like a new key generation or a hostname/ip address change. I can't remember where the file is but if you try to scp to a box with this problem it gives the location of the caching file.

Fwall setting on your Linux client are?

Should I do this:

iptables --list

Good point there--if you can SSH to other remote hosts it wouldn't be your router set up.

It's got to be something on the local linux box. Check that the remote host's packets are being dropped by iptables (yep, iptables --list). If that is not the cause, then...hmmm...

Woa, I ran iptables -F and the box froze. it killed my ssh session and wouldn't let me back in. Maybe it just blocked the ssh port or something.

So after I rebooted I put a different iptables script into /etc/init.d/iptables and rebooted again.

And then it still wouldn't let me ssh to that server so I manually ran the /etc/init.d/iptables script and now it works!

Trouble now is how to find out what else is changing my iptables after /etc/init.d/iptables runs at boot... myabe I can grep for something...

Firestarter. I installed firestarter two years ago and then removed it same day. but it lingered...

/etc/rc.d/init.d/firestarter

I could maybe track down whatever wierd rule it created to block the ip range... I didn't create rules like that manually..