Link to home
Start Free TrialLog in
Avatar of shambright
shambright

asked on

SSH times out before making connection

I am trying to SSH into a new Cent OS 5 server from my home office, and the connection times out before completing.

I have done the following:

* Assigned the server an IP on the block where it sits
* Made sure that /etc/resolv.conf points to valid DNS servers
* Assigned the firewall to allow SSH on this IP (port 22)

I can remotely SSH into other servers in the block, and then SSH to this one.
But if I attempt to remotely SSH directly to this server, I get
"ssh: connect to host XXX.XXX.XXX.XXX port 22: Operation timed out

/var/log/secure has no indication it ever SAW the connection attempt.


Avatar of namol
namol

Are there any messages showing up in /var/log/messages from iptables? Also what commands did you use to add the rules to allow ssh to iptables? These will allow incoming and outgoing ssh communications on the server:
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
Avatar of shambright

ASKER

There is nothing in /var/log/messages regarding iptables

I can connect via SSH from another server in the network (behind the firewall) but not from the outside.


does your firewall allow for ssh to come in? If not you'll have to open it up for port 22 to forward traffic to the correct hosts.
I currently have all ports open for that particular IP. Port 22 was specified in my original post and while troubleshooting, I opened all ports on the router.

Further, I can ping the server with no problem from the router itself.

I added your "iptables" suggestions, but nothing changed. Besides, I was able to SSH from inside the firewall, so it is not a question of the server not allowing it.

I am now thinking it is a problem with CentOS - or a problem communicating with my Mac Laptop.

So you setup a forward for port 22 to the centos machine? If you can hit it internally then there is something externally or between the outside and the server that is blocking the connection.
Right...

I will wait and see if anyone else has any suggestions for where to look.
can you hit any of the other servers from outside of the network?
Namol,

With all due respect, you keep asking questions and making comments that I answered in my posts.
I can remotely SSH to all of the other servers, just not the one I need.
Try to connect to port 22 on this machine without having SSH listening on this port.
To do this, SSH into this machine via another machine in this block (you said that this works for you already), stop the SSH server (the SSH session you're currently connected with won't quit when the server is down) and start nc (the TCP/IP swiss army knife) on this port by running the following command as root on this machine (you might need to install "nc", but usually it's installed on all common linux distributions by default):

nc -l -p 22

Now try to connect to port 22 from outside with telnet, e.g.:

telnet 123.234.232.132 22

and see if you can get a connection.
Try to type text into the telnet window and you should see this text appear on the terminal where you started nc.

If this works, you can at least be sure that the firewall/NAT/PAT rule is working properly.

After you've done this, you can quit nc with CTRL-C and don't forget to restart your SSH server, otherwise no future connection attempts can be made to this server.
Thanks for the reply.

Your command did not work as written.

Trying

nc -l -p 22 22

says 'Cannot use -p and -l'

I tried just

nc -l 22

...and this did not show any result with telnet from the remote site.
BUT I did try it from INSIDE the firewall, and it worked as you described.

I guess the problem is still at the firewall.

Out of my `man nc` (version 1.10-32 on Debian):

NC(1)                                                                    NC(1)

NAME
       nc - TCP/IP swiss army knife

SYNOPSIS
       nc [-options] hostname port[s] [ports] ...
       nc -l -p port [-options] [hostname] [port]

So either your netcat version is newer or older than mine, because mine supports -p and -l on one command line.

I just looked at the previous replies and saw namol suggesting:

iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

Do you have iptables rules running on this host? If so, read on:

This won't work for outgoing connections, because new SSH sessions established from this host will not be generated at source port 22, neither will the replies to incoming ssh connections be initiated from source port 22.

If you have stateful filtering enabled in your iptables configuration, make sure to add the following iptables rule before all other rules:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

If you're limiting your machine in terms of outbound connections, make sure to add the related rule to the output chain too:

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

But personally, I wouldn't apply rules to the OUTPUT chain if there's no really good reason for it.

Could I see the output of `iptables -L -n -v` on the CentOS box that doesn't accept SSH connections?
ASKER CERTIFIED SOLUTION
Avatar of shambright
shambright

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial