SSH Connection refused

Latest response

We had a RHEL server running well for almost two months and then, suddenly after a power outage, we cannot ssh in. Of course, the power is back, and we can log in locally, however, we keep getting a "Connection refused" message when trying to ssh in. Note, we typically log in via password, not via keys.

Here is what we've tried:
- restarting the ssh service (didn't work)
- restarting the machine (didn't work)
- deleting known hosts (in case something got corrupted) (didn't work)
- deleting all retained keys (in case something got corrupted) (didn't work)
- passing in password via command line

here are the outputs we keep getting:
$ ssh -vvv
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to [] port 22.
debug1: connect to address port 22: Connection refused
ssh: connect to host port 22: Connection refused

Why would ssh suddenly stop working? What can we do to get a better idea of what is failing?


If you try to login from localhost what error do you get?


The session failure message is consistent with sshd not running. Perhaps it was not enabled to start up on system start. Try:

systemctl status sshd
systemctl start sshd
systemctl enable sshd

BTW, if the port was not open, you would see: No route to host

Could you tell us which OS version you are using? From the OpenSSH version it looks like Red Hat Enterprise Linux 7 but I do not recognize the SSL version.

As Stephen said this indicates that the sshd service is not up or blocked by firewall, but you said 'we can log in locally', do you mean to say that login via terminal using ssh works? Please clarify.

I'm sure that you might have checked all these, sometimes we forget a simple step in troubleshooting, hence, i thought of putting these points here:

- Make sure sshd is up, you could check if it is listening using netstat command.
- If there is iptables/firewalld setup then make sure sshd (22) is allowed.
- If sshd is up and not blocked by firewall then running command "nc -z <RemoteHostIP> 22 -v" from another system would show up a successful connection.

Probably silly questions, but: - nobody or no process recently changed either the SELinux state on your systems (or might have dorked-up SEL labels)? - nobody or no process would have come through and nuked your ssh-related users and groups? - nobody or no process would have altered your iptables/firewalld configuration?

The first two can cause the SSHD service to straight-up fail to start. The latter can make it unreachable (particularly if you had any profiles associated to a particular network interface since a power-blip might cause your device-graph to change).

ssh working communication working on A & B server but when try rsync & scp between these two server connection refuse due port 22

If ssh works then scp should also work, because scp is a client end program of openssh. You may try running scp in verbose mode and check. The command "rsync" would also use ssh unless configured to use different shell such as rsh.

A snip from the man page of rsync...

       See the file README for installation instructions.

Once  installed,  you can use rsync to any machine that you can access via a remote shell (as well as some that you can access using the rsync daemon-mode protocol).  For remote transfers, a modern rsync uses  ssh  for  its  communications,  but  it  may  have  been configured to use a different remote shell by default, such as rsh or remsh.

run this first to see if sshd listening on port 22

netstat -anp | grep 22

Also, if you are running RHEL 7, do;

firewall-cmd --list-all to check the current active zones and their open ports and services.

If Selinux is enabled, it might work. Kindly checkout.

for SELinux - cat /etc/selinux/config getenforce (enforcing means selinux is enalbed, or disabled if its not enabled)

try disable and check the putty access.

We had the same issue. Someone added the line:


To /etc/hosts.deny

Once we removed that line everything started working.


Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.