Today, as usual, I ssh’ed to another computer and updated their packages (urpmi --wget --auto-update). Given the installation of new nvidia proprietary drivers, I reboot the computer.
After that, I can no longer ssh from one computer to the other. Both computers have sshd.socked active and listening. I turned the rooter off and on with no help.
Did anybody else experimented this? Is there a reason for that?
Two different messages that might lead to two different kind of issues.
In the second case, I suspect a misconfiguration of your router. But the exact description of your network is needed to get a clue.
Anyway, if it works now that’s good.
Few (or none) clues to follow! From googling around, I changed permissions of
ssh_host_ed25519_key to 600 (at /etc/ssh). No help. If this problem has nothing to do with the rooter (I turned it off an on) it certainly was caused by some recent system update. However, since this problem appeared and disappeared, although for just one day, without a reasonable explanation, I tend to think that my rooter has problems.
It could help, anyway, if I could do something else for diagnosing the problem but I don’t know what.
I didn’t reserve IP’s for other clients than the printer, the router is (always) 192.168.0.1, the server is between 192.168.0.100 and 192.168.0.102, the client usually gets 192.168.0.103 to 192.168.0.106. Now, the server is 192.168.0.100 and the client has 192.168.0.106. Access to the router is allowed from the server and the client. The list of DHCP clients is
ID Client name MAC address IP Renewing time
1 pc-central 00-22-4D-A7-2C-2D 192.168.0.100 01:47:51
2 Unknown 1C-C6-3C-48-33-DB 192.168.0.101 01:17:10
3 pc-local 74-2F-68-A9-59-8E 192.168.0.105 01:57:29
4 pc-local C0-4A-00-1D-C1-D7 192.168.0.102 01:59:19
That might be the cause of the message: no route to ...
You need to know the exact ip of the server when you launch ssh 192.168.0.xxx
So let’s say the server’s ip is 192.168.0.100, what is the output of ssh 192.168.0.100
?
(adjust the ip accordingly to the actual server’s ip)
If the message no route to ... occurs, what’s the output of: ping 192.168.0.100
?
Normally the same kind of message should be displayed.
In that case, you should check the real server’s ip.
If the server gives an answer, that could mean that the port isn’t the default (22). In that case you should check the setting Port in the server’s /etc/ssh/sshd_config
If the message connection refused appears, then you should check the content of /etc/ssh/sshd_config in the server, especially the settings of: ListenAddress and Port
I had this problem as well. It turned out it was a firewalld issues. Try running systemctl stop firewalld and see if ssh starts working. The default zone was empty so I set it to public but the permanent rule was set to allow ssh and the runtime was not allowing it. After making sure sshd was running and restarting firewalld things started working. I does fail again after some time.
Well, I usually know what is the current server’s address. Anyway, if I’m wrong, I try the next IP.
Now, server is 192.168.0.100 and
$ ssh 192.168.0.100
ssh: connect to host 192.168.0.100 port 22: No route to host
Ping gives,
$ ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
From 192.168.0.100 icmp_seq=3 Destination Host Prohibited
From 192.168.0.100 icmp_seq=4 Destination Host Prohibited
From 192.168.0.100 icmp_seq=5 Destination Host Prohibited
^C
--- 192.168.0.100 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4032ms
If I understood correctly, CLB succeeded in recovering ssh services but it failed again after some time.
I’m tending to think it may be some kind of hardware problem because I also had a similar experience here when I reset the router, in the next few minutes (seconds?) ssh was working and then stopped again.
Yes, that’s the default value: listening any address at port 22.
If there is no firewall server side, you might have to look into the router’s settings. It might disallow the communications between local hosts, only enabling the output to the Internet.
But, since sometimes it works, you’d better to try with another router if you can get one.
Did you try doing a systemctl stop firewalld on 192.168.0.100 and trying to ssh in from another machine? I was seeing the exact same two error messages and the cause was the firewall on the machine I was trying to ssh into.
Mine is a two way connection problem. Two hosts: pc-central (usually the server) and pc-local(my laptop). I cannot connect from each other via ssh. Thus, I think I should change firewalld configurations although everything was Ok with this very firewalld a couple of weeks ago, before a certain update.
I still have an old router that I used to test for hardware problems. I got no connection at all at my laptop, neither internet nor ssh with this old router.
I also took my chances with om-control-center=>firewall but I don’t know much about everything.