0

So I have done the same process over and over again and everytime worked perfectly, but on thie particular server it just won't work.

I've tried any written suggestion on the Internet + serverfault but nothing is working.

So shortly I need to clone a git repository in another server from the original server, but the ssh connection won't work. I tried to fix, but nothing worked.

Even without a key the same errors occurs:

ssh -p **** -vvv git@*host.domain*
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to *host.domain* [***.***.***.***] port ****.
debug1: connect to address ***.***.***.*** port ****: Connection timed out
ssh: connect to host *host.domain* port ****: Connection timed out

Also, something weird I've noticed after searching for fixes over the internet: I can't restart the ssh as it appears normally with sudo service ssh restart, only with sudo service sshd restart. Not sure if anything relevant.

11
  • Are you sure there is something listening on that port and that it's not blocked by some firewall in between?
    – Sven
    Feb 12, 2013 at 10:28
  • @SvenW and how can I check that?.. I'm sure that the server and the port combination is valid, because on other servers it works normally. Feb 12, 2013 at 10:33
  • can you ping or wget something from that remote machine? Feb 12, 2013 at 10:49
  • @zwarag both work perfectly Feb 12, 2013 at 10:51
  • @zwarag I get the short non-verbose version of the above. if I run with the port at then end it says Name or service not known - it's not the right syntax Feb 12, 2013 at 10:57

4 Answers 4

4
+50

If the connection is timing out rather than being refused immediately, this is most likely some kind of firewall problem. Obviously I can't know what devices are sitting between your client and server, so this answer is limited to the firewall on the server itself.

If you don't mind temporarily disabling your host firewall, you can test this by doing

# iptables-save > /tmp/ipt
# iptables -F
...try your ssh connection again...
# iptables-restore < /tmp/ipt

If that fixes it, you'll have to look at the output of iptables -nvL to work out which rule is blocking your connection.

If you still have problems, it's possible that sshd itself is dropping the connection for some reason. You could try running on the server

# tcpdump host [address of client] and port 22

while you try connecting to see if the traffic actually arrives. If you don't see anything appearing while you're trying to connect and you've done an iptables -F, it's likely that some intervening device is responsible for dropping the traffic.

0
1

Temporarily place in your /etc/sysctl.conf on said server the following line

net.ipv4.tcp_window_scaling = 0

which disables TCP window scaling. Try this, particularly if tcpdump (as suggested by Flup) shows that the first three packets that initiate the TCP connection are exchanged.

0

There may be multiple firewalls between your session and the host on the other side. You might wish to confirm that the port in question is reachable.

One way to do that is to run nmap

nmap host.domain

The output will look like this:

Starting Nmap 5.51 ( http://nmap.org ) at 2013-03-13 07:32 EDT
Nmap scan report for host.domain (10.10.10.10)
Host is up (0.00023s latency).
rDNS record for 10.10.10.10: host.domain
Not shown: 998 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
111/tcp open  rpcbind
MAC Address: E0:DB:55:00:00:01 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.21 seconds

In this example, you can see that two ports are open and one of them is 22, the port usually associated with ssh.

This will allow you confirm that there is a path from your server to the other host.

More information can be found at nmap's website

As an aside, sshd is the name of the ssh daemon and the script that manages the sshd deamon found in /etc/init.d . The service command uses the names of scripts found in /etc/init.d on redhat, centos and similar distros, hence:

service sshd restart
-1

On the SERVER edit /etc/ssh/ssh_config

insert following:

Host *
    ServerAliveInterval 300
    ServerAliveCountMax 2

This will send evry 300 seconds a keep alive signal for a maximum of 2 times. If you like to have it to the infiniti set ServerAliveCountMax to 0

If you wold like to keep alive FROM the client,
do exactly the same but without "Host *"

2
  • He can't connect to begin with, how is this helping?
    – Sven
    Feb 12, 2013 at 10:36
  • Ohh damnit, i read to fast.. But it could be that the Interval is set to 0 so nobody might ssh to that server. Feb 12, 2013 at 10:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .