[Solved] SSH not connecting

[philld]

I was trying to connect to one of my DNS-323 machines today via SSH and got the message ssh: "connect to host 192.168.0.xx port 22: Connection refused".  In trying to diagnose the problem, I tried to login to the second DNS-323 and got the same error.  There have been no changes on the DNS-323 machines in months and the last time I logged in via ssh to either of the DNS-323s was about a month ago.  I checked in PCC to ensure that the sshd process was running (stopped and started it just to be sure) but still the same problem.  Also restarted the DNS-323.  The PC is up to date with the updates.  Since I have made no updates on the DNS-323s, my thinking is that the problem is at the PCLinuxOS side of the operation.  Anybody else having a similar problem and or suggestions on what else to check?

[AS]

Hello philld,

I normally use ssh even for short transfer between host PCLinuxOS and VirtualBox guest PCLinuxOS, my systems are fully updated and did't notice any issue.
You should try ssh -v, or even ssh -vv to obtain some info about the ssh connection, at least you should notice where it fails/stop.

A "connection refused" should result when sshd is not running or when firewall is blocking the connection.

AS

[philld]

Thanks AS for the suggestion.  Give it a try and got the following:
OpenSSH_5.8p1, OpenSSL 1.0.0d 8 Feb 2011
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.xx [192.168.0.xx] port 22.
debug1: connect to address 192.168.0.xx port 22: Connection refused
ssh: connect to host 192.168.0.xx port 22: Connection refused

Your suggestion re the firewall got me wondering about my router so tried reloading an earlier config that was installed on it but no luck.  While I'm typing here, I just realized that there has been a new "firewall" icon on my desktop since one of the upgrades a few weeks back so am going to take a look there to see if there might be something.

[AS]

Thanks AS for the suggestion.  Give it a try and got the following:
OpenSSH_5.8p1, OpenSSL 1.0.0d 8 Feb 2011
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.xx [192.168.0.xx] port 22.
debug1: connect to address 192.168.0.xx port 22: Connection refused
ssh: connect to host 192.168.0.xx port 22: Connection refused

Your suggestion re the firewall got me wondering about my router so tried reloading an earlier config that was installed on it but no luck.  While I'm typing here, I just realized that there has been a new "firewall" icon on my desktop since one of the upgrades a few weeks back so am going to take a look there to see if there might be something.

You are using the xx to hide your machine IP ?
really there is no reason to hide this, no one can access your private LAN from outside. However it let me think about a possible address changes...
be sure that's the correct IP address of your remote machine. 

AS

[Archie]

Or perhaps sshd wasn't turned on in the other machines?

[pags]

Try running the following from the PC your trying to ssh from:

Code: [Select]

nmap -p 22 192.168.0.1-254 | grep open -4

This should indicate what IP's this machine can see that are running sshd on its standard port.  The results will be similar to:

22/tcp closed ssh

Interesting ports on 192.168.0.12:
PORT   STATE SERVICE
22/tcp open  ssh

Interesting ports on 192.168.0.103:
PORT   STATE SERVICE
22/tcp open  ssh

Interesting ports on medea (192.168.0.104):
PORT   STATE SERVICE
22/tcp open  ssh

Interesting ports on 192.168.0.106:
PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 254 IP addresses (5 hosts up) scanned in 23.04 seconds

You can see, on this particular subnet, I have four machines I could ssh into (one of which is the machine I'm running this from).
192.168.0.12
192.168.0.103
192.168.0.104
192.168.0.106

See if the IPs you get match the IPs you're trying to use...

If you confirm that sshd is running on the targets, and you can't see them here, it is most likely a network/firewall type issue...

[philld]

Thanks for the suggestions - further investigation into the problem indicated there were some corrupt files which prevented the services from starting on the DNS-323.  Re-installed the offending components and all is now as it should be.  Appreciate the feedback, gave me a few new tricks for checking things should it happen in the future.