I have a VCN server set up on my host, let's call it 'jim'. This host has been running Ubuntu 16.xx for around 6 months now. I have had VNC server and ssh working on it ok in the past. Today I found that a co-worker could not use a VNC viewer to look at my desktop and when I tried from a different host on my intranet, VNC viewer failed for me also.

In looking at my intranet, I found that I can ssh from any host to any other host, except 'jim'. When I enter 'ssh -l jja jim' and hit return, the command hangs until I interrupt it. This command hangs from any other host on my network. If I try to run 'sudo rpcinfo -p jim' from any host, the command not only hangs, but I cannot interrupt it.

If I ping 'jim' from any host, I do get a positive response. If I try to ssh from 'jim' to any other host, everything works fine.

I have tried 'apt-get remove openssh-server' and reinstalled it, but no change in behavior.

Can anyone help with suggestions on what to try to get 'ssh jim' to work?

Jim Anderson

NOTE: I had posted this thread in 'networking', but moved it to the 'software' forum because it did not look like it was at a low enough level on the OSI model to be considered a 'networking' problem. I did get the following response from 'lazydog' to the original post.

___________________________________________________________________________
First thing to do when a service is not working is to ensue the service is started. If the service is started then the next thing to look at is your firewall and either make sure it is turned off or that the ports are opened on it that are required to get things connected.
__________________
Regards
Robert

Well, since you have access to both machines, you can try several things.

One, from the client side, you can increase the verbosity.

Look carefully at each level to see if you get some kind of indication as to what's going on.

On the server, there are two thing to try. First, you can look at the configuration file and see if that's any clue.

Substitute in the ip address of the client machine that is having the trouble there in the second line.

Second, you can try running an extra copy of the daemon and watch what it says about the connection. The following is good for one connection attempt (vary the number of -d from one to three for more details):

Then you can connect once on port 22222 and see the connection information from the server side without disturbing the other users:

Thank you turbocapilalist. I actually resolved the problem last week, but I have added your suggest to my
'useful commands for debugging network problems'. It has been a busy week, but I finally got back to
record my solution today.

'lazydog' made the suggestion to look at my firewall. I looked an 'iptables howto' and it gave an
example of making sure that the ssh port is open:

>>> iptables -A INPUT -p tcp --dport ssh -j ACCEPT

and that worked. It is interesting to note that ssh from and to the computers in questions had worked
previously. That raises the question of how the firewall got blocked in the first place. But all is
well that ends well.

Jim Anderson

At a guess you had it open in iptables in memory but had never updated the saved iptables file that gets reloaded on boot so when you last booted it simply didn't have the rule. (Or alternatively along the same lines you never had iptables running and/or had disabled it but on last reboot it restarted and didn't have the rule.)

Make sure any rules you have in memory are saved to the file that gets reloaded on boot. You can do that manually and I usually do any time I update rules on the fly. Many systems do this automatically on graceful shutdown but wouldn't do it on a crash. Also make sure the rules you've saved are in fact being loaded when you boot.