Ssh connection refused

Now, two computers with OMV LX 3.0 in a network. Both updated from 2014.2.

SSH used to work until I update the second computer to OMV LX 3.0.

Now, I can ssh from the new installation of OMVLX3 to the old but not reverse, the new installation refuses outer connections:

$ ssh
ssh: connect to host port 22: Connection refused

Port 22 TCP is in firewall for ssh in the computer that refuses connection.

What can be wrong?


Is sshd running on the server side?
There is a way to purge the old settings in ~/.ssh/know_hosts client side, how I don’t know.
I remove this file (I don’t have that many ssh connections)

You might get some useful infos with the verbose option:
ssh -v


The daemon sshd is not running neither in the server(desktop) nor in the laptop. But ssh works if launched in the server to connect to the laptop.


I’ll try this command.


You might check if the sshd.socket is running:

systemctl status sshd.socket

on the host to which you send a request.
Systemd is listening the requests on port 22 through this socket. If needed, it launches sshd. When the connexion is closed, sshd is stopped.

If sshd.socket isn’t active, check also system-sshd.slice:

systemctl status system-sshd.slice

None of them were running int the desktop.

Without knowing exactly what to do I decided to experiment the service sshd.socket because it was your first mention and because this was running at the laptop side, the one that was already accepting ssh.

I did,

systemctl enable sshd.socket

systemctl start sshd.socket

Then I checked for sshd.socket and it was OK and the ssh from laptop to the desktop was possible.

I’m still wondering how sshd.socket got stopped at first place, if sshd.socket will be started next boot and what, if any, are the vulnerabilities of having sshd.socket running in all OMV 3.0 installations.


Does the command

$ systemctl enable sshd.socket

guarantees that sshd.socket will start at next boot? If so, there is something wrong in the desktop side since I had to restart sshd.socket after boot. What could be wrong?


I guess yes :slight_smile:
To be tested however.

I don’t really know.But as the hosts were upgraded from 2014.2, I imagine that there was not exactly the same config in both. You could check the hypothesis from an eventual backup.

The update 2014.2 => 3.0 was done in both computers but only the last one, the desktop, seems not to start sshd.socket at boot. Anyway, I still have to confirm the problem …


It is confirmed! The system does not start sshd.socket at boot. It did not worked to issue,

$ systemctl enable sshd.socket

Many problems with that OMV LX 3.0! I am facing problems like,

  • No line for the Windows 8 at grub’s boot
  • Inactive Swap
  • Freezing often
  • No nvidia proprietary support (incompatible with Xorg 1 19)

among others…

My mistake! I have edit OMCC so to have the sshd.service started at boot. Since sshd.socket conflicts with sshd.service, the command,

$ systemctl enable sshd.socket

did not guaranteed that it would start at boot. Thus, to solve I did,

$ systemctl disable sshd.service
$ systemctl enable sshd.socket

and at least this problem is solved.

I just think that there should be some error message since the conflict would prevent sshd.socket to start at boot.