LEAP 15.0: vncviewer unable connect to socket: Connection refused (111)

Hi.

I thought I got through the hard part and starting up vncviewer was going to be the easy, final step… but no…

client% vncviewer localhost:5900

produces this error:


DecodeManager: Detected 1 CPU core(s)
DecodeManager: Decoding data on main thread
CConn: unable connect to socket: Connection refused (111)

So, I try…

client% telnet localhost 5900

Trying ::1…
telnet: connect to address ::1: connection refused
Trying 127.0.0.1…
telnet: connect to address 127.0.0.1: Connection refused

client% telnet localhost 25

works as expected.

The firewall is off.

This was used to setup ssh tunneling…

client% ssh -L 5900:localhost:5900 remoteMachine

remoteMachine% x11vnc -many -threads -nap -modtweak -bg -display :0


The VNC desktop is: remoteMachine:0
PORT = 5900

remoteMachine% netstat -an | grep 5900

tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN
tcp6 0 0 :::5900 :::* LISTEN

which I believe means that the remoteMachine is ready and actively listening for the client vncviewer?

As noted earlier, the firewall is off on the client.

What am I missing?

Thanks!

Whenever a connection is actively refused, it’s almost certainly a firewall issue.

How are you disabing and verifying your firewall is off?

TSU

YaST2 - firewall

Start-Up

Current status: stopped

client% firewall-cmd --state

not running

I disabled the firewall to see if it was the problem. At some point, I’d like to turn it back on and put the port in the proper Zone.

I am sorry linuxvinh](https://forums.opensuse.org/member.php/28761-linuxvinh), but I do not understand the rational here. I think that you want to use “client” to login to remoteMachine using VNC via a reverse-SSH tunnel. If that is wrong ignore the following.

The “client” inbound firewall is irrelevant. It would be an unusual situation where a host could not access itself even with the network physically disconnected. The only thing that matters here is whether you can use SSH to login to remoteMachine from client, preferably using RSA key authentication. So the only firewalld configuration is that remoteMachine’s ssh daemon is listening on an open port (usually TCP:22).

Secondly, remoteMachine needs to be running a VNC server listening on e.g. TCP port 5900. You need to login to remoteMachine (via SSH from client) and make sure that this state of affairs is true.

Then to connect port 9900 on client (I am using a different port number to avoid confusion) to port 5900 on remote host
you need something like


$USERNAME@client: >    ssh -f -p22  $USERNAME@remoteMachine  -L 9900:remoteMachine:5900 &
$USERNAME@client: >   vncviewer  client:9900

I don’t remember the exact architecture and flow of how VNC works, but I seem to remember in some scenarios various proxies set up so could create hidden conflicts in your setup.
I notice you’re running a number of your tests referencing “localhost” which suggests your client and server are on the same machine.

Recommend instead that you set up at least one truly remote machine…
And this is where virtualization like VBox can be very helpful so that you can test your connections on a virtual network where all hosts are running on the same physical machine.

TSU

P.S.
I think that you are unable to connect to VNC (port 5900) on “client” because there is no VNC service running on “client”, only on “remoteMachine”.

But I had not considered Tsu’s interpretation: that you were doing all of this on a single machine.

And your post suggests another possible cause…
Although I’m slightly discounting because when a connection is actively refused, it typically isn’t caused by simply no service responding on that port, in that case the client isn’t actively denied but is actually successful initiating a connection attempt but then fails due to no response.

But it can also be considered that if you are trying to connect using localhost, your service must also be listening on that interface typically assigned with a 127.x.y.z IPv4 address and not the “network interface” which can be assigned an IP address with a NetworkID shared with other machines on the same network.

TSU

Hi. Thanks for all the responses so far!

Some clarifications…

I’m on a home machine, which I’m calling client. There’s an intermediate machine, which I have to use to connect to remoteMachine. This is a work requirement. I’m not testing this on a single machine nor on a single network. It is going over the internet. It looks something like this:

client <-> internet <-> intermediateMachine <-> local network <-> remoteMachine

I start with client and ssh into the intermediateMachine…

client% ssh -p <port> -l <login> <intermediateMachine>

Once logged onto intermediateMachine…

intermediateMachine% ssh -L 5900:localhost:5900 <remoteMachine>

Once on the remoteMachine…

remoteMachine% x11vnc -many -threads -nap -modtweak -bg -display :0

to start up the vncserver. I’ve verified that it’s listen…

remoteMachine% netstat -an | grep 5900

tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN
tcp6 0 0 :::5900 :::* LISTEN

I know for sure that this setup, going through an intermediateMachine, works, as I have co-workers who use Windows to make the connection. They use PuTTY to set up ssh connections and port forwarding. I’ve basically mimicked what was done with PuTTY, or at least I think I have. I’ve seen some generic docs regarding using PuTTY on Windows and it doesn’t vary much from what the work docs show.

I am sorry, but you still expect us to guess from snatches of narrative and what might be pseudo commands. Now we might be dealining with at least three machines, some of which might be using Microsoft software.

Please explain what operating system each machine is using (and why the now deprecated Leap-15.0), how they are connected, and what you are trying to achieve.
The best way to show what you have done is to copy the command (including prompt) and its output and paste within the CODE tags (the “#” icon above the web text entry box). Just typing stuff does not help us to spot mistakes (surprisingly common) and one thing that we have established is that whatever you are doing is unsuccessful.
The use of “localhost” is confusing when it may refer to any one of three machines. It is not used in the SSH man pages. The actual host name would be more obvious.

This scenario may be analogous to one of the ites that I administer remotely. A couple of years ago it moved into a campus that supplies internet access, ethernet cabling, etc. As well as our own private LAN addresses each machine is given a DHCP IPv4 address by the campus router and two machines (identified by MAC) were allocated public addresses. The only inbound ports open on our machines are SSH. I use ssh (RSA key authentication) to connect to the two gateway machines and then relay to the other machines on our private LAN. Is this what you are trying to do?

If the gateway/intermediate machine is shared, you will not all be able to simultaneously use the same local port. The intermediary can be taken out of the loop altogether if you create the SSH tunnel from the remote machine to your home desktop (You may need to use port forwarding on your home router or use IPv6).

All three machines are using a flavor of GNU/Linux. Mine is openSUSE Leap 15.0 because I haven’t had the opportunity to update it to 15.1. (I need to do a backup first.) That shouldn’t matter. The reason I brought up PuTTY and Windows is that a Windows machine with PuTTY has already been proven to work with this setup, with the client being the Windows machine. This looks like:

Windows client using PuTTY <-> internet <-> GNU/Linux intermediateMachine <-> local network <-> GNU/Linux remoteMachine

I’ve posted as much detail as I could, including output, obscuring private info.

The use of “localhost” is in many of the docs I’ve found when I search for “vncviewer ssh tunneling”…

http://www.karlrunge.com/x11vnc/ - see Tunnelling x11vnc via SSH
linux - vncserver -localhost and ssh tunneling - Super User
https://www.techrepublic.com/article/how-to-connect-to-vnc-using-ssh/
How to Install and Configure VNC Server on Ubuntu
TightVNC and SSH tunnels | tjansson.dk
Connect to VNC Server via SSH Tunnel - kifarunix.com

The scenario you describe sounds like what I’m trying to achieve. Client, my machine, is on the internet. intermediateMachine, gateway, has connection to the world via ssh. Other machines are connected to intermediateMachine via private LAN.

When you say not use the same local port, do you mean 5900? I should make up a port, so my command looks more like this?

intermediateMachine% ssh -L 9900:localhost:5900 <remoteMachine>

The 9900 is to prevent conflicts?

I’ve now tried:

intermediateMachine% ssh -L 9900:localhost:5900 <remoteMachine>

client% vncviewer localhost:9900

No luck.

intermediateMachine% ssh -L 9900:<intermediateMachine>:5900 <remoteMachine>

client% vncviewer localhost:9900

No luck.

Point well taken about ssh tunneling using localhost… Slipped my mind.
Will think about your setup further, it should be fairly straightforward although I seem to remember you can also set up your intermediate machine to support remote tunneling to your MSWindows target machine.

Will post again when I have something specific…

TSU

I have been thinking about this all day, but still do not fully understand the layout or what is wanted (and hoping someone would elucidate). I think that the target is a Linux desktop – but we are not told what type. The MS Windows machine seems to be an alternative “client” that may, or may not, be able to connect to a VNC session on the “remoteMachine”.


linuxvinh,
Your list of blog posts may be very interesting and informative, but the real documentation is the man pages for SSH (which include tunnel examples ) and VNC on the machine running the software.

Can you verify that you have a MS Windows machine that successfully connects to a VNC session on “remoteMachine” from your home?
I am assuming that “remoteMachine” is your work desktop (if it was a server it would not need a GUI). If so it probably has internet connectivity and you could avoid the intermediate machine by creating an SSH tunnel from “remoteMachine” to “client”.
If “remoteMachine” and “intermediateMachine” are on the same private LAN, is there a reason that you need an SSH tunnel between them? Could “intermediateMachine” not directly access e.g. tcp port 5900 on “remoteMachine”?

You seem to be trying to create a tunnel between “intermediateMachine” and “remoteMachine”. Should you not first be trying to create a tunnel between “client” and “intermediateMachine”? Once you have achieved that, you can connect your personal “intermediateMachine” port to the VNC session on “remoteMachine” using either a second SSH tunnel or rinetd port rediredtion.

Please, please copy and paste (in CODE tags and including shell prompts and output) what you actually type on the command line instead of typing here what you meant to enter.
The “localhost” thing is really confusing when you have three machines interacting. In your cited web instructions, it is convenient because the authors will only be concerned to initiate the tunnel on a single machine, with less room for misunderstanding.

All machines are GNU/Linux boxen.

Here’s setup:

GNU/Linux client <-> internet <-> GNU/Linux intermediateMachine <-> private LAN <-> GNU/Linux remoteMachine

I haven’t tried using a Windows machine as a client as my only Windows machine at home is a netbook with Windows 7 Home running in VirtualBox. I may try the netbook next, though, just as an exercise. My coworkers have Windows as a client and it works.

remoteMachine has graphics and I want to view the X11 desktop, thus vncviewer.

remoteMachine is not directly connected to the internet. It’s the same scenario you had described. The intermediateMachine serves as a gateway to the internet, for security purposes.

The localhost thing is literally using the keyword “localhost”, not as a placeholder for the hostname of a local host.

In a client shell:

client% ssh -p 9000 -l linuxvinh intermediateMachine.domain.com
Password:

intermediateMachine% ssh -L 9900:localhost:5900 remoteMachine
linuxvinh@remoteMachine's password:
Last login: Wed Mar 4 time from intermediateMachine.domain.com

remoteMachine% x11vnc -many -threads -nap -modtweak -bg -display :0

<lots of text>
The VNC desktop is:      remoteMachine:0
PORT=5900

In another shell on client:


client% vncviewer localhost:9900

I am not just being grumpy (but I am quite busy just now and don’t like wasting time. and to be honest am often grumpy). The reason for asking which OS/distributions you are using is because stuff sometimes behaves differently. In this instance especially firewalls (even in Leap we went fro SuSEfirewall2 to firewalld), the version and configuration of VNC.
I do not think that you should disable firewalls, just make sure that your normal ssh connections are working.

I haven’t tried using a Windows machine as a client … My coworkers have Windows as a client and it works.

To the same remoteMachine? Because then, hopefully, we do not have to worry about the VNC server configuration.

The localhost thing is literally …

There are several ways of writing the parameters after the ssh -L option. I have been using one dialect for years and have to translate from another variety. Localhost just leaves room for confusion, especially when daisy-chaining from one tunnel to another. Also ‘localhost’ does not always behave the same as “$hostname”, especially if IPv6 is enabled. I must apologise; “localhost” does appear in the TCP forwarding section of the ssh man page (starts on line 471, -L is at line 118)

I just feel that you have a syntax/logic error in the ssh daisy-chain.

We have laptops that use ssh tunnels for secure access to their mailserver on port 443 (on ferries normally only connections on ports 80 and 443 are allowed). They also have a script to create a tunnel back to one of our internal gateway machines so that we can supply remote support to anywhere. However a grphical interface is rarely needed. When a user messes up their desktop we just overwrite “~/.config” files with known good ones.

I notice that you do not provide the “-f” option or a sleep to give time for the connection to be started.
I prefer to disable SSH password authentication and use RSA key pairs; much easier in scripted connections.

This evening, after the office workers have finished I will try to set up remote VNC server with a daisy-chained tunnel connection from my laptop. This will be all Leap-15.1, but hopefully it should provide you with a more or less useful template.

I found another coworker that uses GNU/Linux as a client!

Three shells on client are used:

-X X11 forwarding
-C compression
9000 intermediateMachine port open to the internet
3456 intermediate port to use for relay, could be any number
22 ssh port on remoteMachine


client% ssh -X -C -p 9000 -L 3456:remoteMachine:22 linuxvinh@intermediateMachine.domain.com
Password: <password for intermediateMachine>

5678 port to use with vncviewer, could be any number
3456 intermediate port to use for relay, needs to match above
5900 vnc port on remoteMachine


client% ssh -p 3456 -L 5678:localhost:5900 linuxvinh@localhost
Password: <password for remoteMachine>
remoteMachine% x11vnc -many -threads -nap -modtweak -bg -display :0

5678 port to use with vncviewer, needs to match above


client% vncviewer localhost:5678

I think this translates to…

client <-> port 5678 <-> port 9000 <-> intermediateMachine <-> port 3456 <-> port 22 <-> remoteMachine vnc port 5900

Sorry for the delay. I stupidly managed to poweroff the remote machine and had to leave a message for somone on-site to restart it.
There must be a lot of ways to create a multi-hop ssh tunnel, but this is what I have done.

I have a one-liner in all of my “~/bin/” directories that is hard linked to the host names that I regularly connect to.

#!  /bin/sh
ssh -p9022 -o TCPkeepalive=yes  sysman@${0##*/}  $*

This is just a convenience to login to or run a command on a remote machine.

The following min script sets up a tunnel from my laptop to the remote VNC server via a gateway (or jump host in ssh parlance) and opens a vncviewer window:


rayh@yoga3:~> cat bin/vnc-mint
#! /bin/sh

#   ~/bin/vnc-mint
## connects local vncviewer to mint (target VNC server)
##   via fennel as the Belfast gateway.
## all machines openSUSE Leap-15.1
## assumes local user's ssh public key is in users .ssh/authorized_keys,
##   gateway user's public key is in mint user's authorized_keys,
##   and mint user's public key in fennel user's authorized_keys.
##
##  mint VNC server configured with YaST2 for
##    Remote Administration With Session Management
##  firewalld enabled.
##    open ports on fennel and mint TCP/9022 (sshd)
##    all other ports also blocked by campus router-firewall.
##  
##  
## reverse tunnel the vnc port from server to gateway
fennel -t mint ssh -p9022 -fN -R 15901:mint:5901 fennel
##  test port # fennel -t  nc -zv4 localhost 15901

##  tunnel forwards local port to gateway 
ssh -p9022 -4 -f -L 5501:localhost:15901 sysman@fennel sleep 10 
##  test port #   nc -zv4 localhost 5501 

##  open vncviewer on local port before sleep timeout
vncviewer localhost::5501


rayh@yoga3:~>

I make no claims that this is a particularly good solution, only that it was quick and works. It might give you some ideas for your own situation.

Thanks again for the help!

I haven’t had the chance to try out your alternative method. I don’t know how automated I can make things work, as there’s two-factor authentication involved. Perhaps the script will just pause until the verification is done? I’ll have to see.

More compact:

Shell 1:

9000 intermediateMachine port open to the internet (gateway)
5678 port to use with vncviewer, could be any number
3456 intermediate port to use for relay, could be any number
5900 vnc port on remoteMachine

client% ssh -t -p 9000 -l linuxvinh -L 5678:localhost:3456 intermediateMachine.domain.com ssh -L 3456:localhost:5900 remoteMachine.domain.com
Password: <password for intermediateMachine>
Password: <password for remoteMachine>
remoteMachine% x11vnc -many -threads -nap -modtweak -bg -display :0

Shell 2:

client% vncviewer localhost:5678

Thankfully this got sorted just before Shelter-In-Place, so I can work from home!