Rfb protocol error bad rectangle

UltraVNC

1.1.8.0 protocol error

1.1.8.0 protocol error

Post by Rudi De Vos » 2013-01-08 21:47

rfb proto error found in 1.1.8.0

Re: 1.1.8.0 protocol error

Post by jbcollins » 2013-01-25 21:41

Re: 1.1.8.0 protocol error

Post by Rudi De Vos » 2013-01-28 12:18

Have you set an empty server passwd ?

Source was aleady modified, i will compîle some test version with fix and try
to upload it before the weekend

Re: 1.1.8.0 protocol error

Post by jbcollins » 2013-01-28 14:42

No i am using a set password.

It seems to work on the first connection i make but then if i close and make another connection to the same viewer i get this error.

Second time trying to connect i get the error: RFB protocol error: bad xrle data

Third time trying to connect i get this error: RFB protocol error: unknown message type 24

Re: 1.1.8.0 protocol error

Post by Rudi De Vos » 2013-02-04 21:57

Re: 1.1.8.0 protocol error

Post by jbcollins » 2013-02-07 09:05

Tried using the update executable (product version 1.1.8.1) and still getting the same thing. The very first connection from a windows 8 machine comes through ok but then any other connections from the same windows 8 machine fail with the following errors.

RFB protocol error: unknown message type 24

RFB protocol error: bad rectangle: 65280×6148 at 33316,1 exceeds 1920×1080

• Board index
• All times are UTC
• Delete cookies

Powered by phpBB® Forum Software © phpBB Limited

Источник

Rfb protocol error bad pixel format

RealVNC, RPi3, ESXi and Windows 7 VM — Bad Rectangles

I have an ESXi server on which I run a few VMs, one of which is the only Windows machine in the house, effectively. My MacBook is being repaired and whilst it is away, I thought I would try getting VNC working on my RPi3 so I can still use the Windows 7 VM when I need to.

The RPi3 is attached to a Motorola Laptop and is working fine.
I got RealVNC installed.
The VM has its desktop size set to 1366×768.

What I found was the first time i got it working it was great, after several connection attempts failed with RFB protocol error — bad rectangle

Since then I have not been able to get rid of the error and it has been unusable.

The VNC viewer window shows a double ghost image of the W7 VM desktop below which it says:
Attempting to reconnect to VNC server.
RFB protocol error: Bad rectangle: 16448×0 at 0,0 exceeds 1366×768

Bear in mind here that the VNC server is not actually running on the Windows machine, it is a function within the ESXi server, so pretty basic. It does however work flawlessly with Apple Remote Desktop and with the Remoter VNC client I have on my iPad. And as I said it did work once with RealVNC on the RPi3.

Has anyone come across this and worked out a work around or solved it?

Re: RealVNC, RPi3, ESXi and Windows 7 VM — Bad Rectangles

I gave up on RealVNC. And they won’t even speak to you unless you are trying to connect to a RealVNC server.

Xtightvncviewer works. sort of! Its a bit clunky to get a connection, but that’s OK. I don’t like not being able to have a full screen view. It has the option (allegedly!) as pressing F8 brings up a menu with a «Full screen» option but clicking it crashes/closes the viewer completely. Also trying to change the desktop resolution of the Windows VM at the other end causes the viewer to crash or close too.

Are there any recommendations for VNC viewers I might try instead?

Re: RealVNC, RPi3, ESXi and Windows 7 VM — Bad Rectangles

Result! I wanted to see what VNC related packages were installed on the Pi.
Found something installed called xvnc4viewer! Which works perfectly and yet claims to be RealVNC. When I tried starting the RealVNC viewer from the Raspbian GUI I couldn’t make it work. I don’t know if by started xvnc4viewer from the command line starts the same client in a different way, but it works, so I am happy now.

In comparison xtightvncviewer is just nasty.

Источник

TightVNC Bugs

Group

Searches

#1237 TightVNC 2.7.1, Windows 2008r2, RFB error, bad screen size

Hi,
I have problem with TightVNC 2.7.1 x64bit on Windows 2008 r2.
System:
— debian box, kvm-qemu
— clean install Windows 2008 r2
— all updates include optional
— TightVNC 2.7.1
— DFMirage Driver 2.0.301

Problem:
Before windows update everything was ok. After windows optional update I can no longer connect to the TightVNC server. From RealVNC Viewer I get error «RFB error: bad screen size 0x0». With TightVNC Viewer I get only toolbar from client, but without image.
It become independent of the two clean installed servers.

Discussion

We are seeing this same issue as well on almost identical configuration

Brand new machine, Windows 2008 r2
Initially setup with TightVNC 2.7.1 dn DFMirage. VNC was working fine.

We ran Windows Update to get current, and vnc no longer worked, would report Screen geometry of 0x0

We uninstalled 2.7.1, and installed 2.6.4 and VNC works

Attached is a log file from 2.7.1 when VNC was not working

[ 3560/ 476] 2013-04-29 11:29:09 + TightVNC Server Build on Apr 24 2013 at 15:15:50
[ 3560/ 476] 2013-04-29 11:29:09 + Stopping main RFB server
[ 3560/ 476] 2013-04-29 11:29:09 + Starting main RFB server
[ 3560/ 476] 2013-04-29 11:29:09 + Rfb server started at 0.0.0.0:5900
[ 3560/ 476] 2013-04-29 11:29:09 + Need to reconfigure extra RFB servers
[ 3560/ 476] 2013-04-29 11:29:09 + Stopping HTTP server
[ 3560/ 476] 2013-04-29 11:29:09 + Starting HTTP server
[ 3560/ 476] 2013-04-29 11:29:09 + Http server started
[ 3560/ 476] 2013-04-29 11:29:09 + Stopping control server
[ 3560/ 476] 2013-04-29 11:29:09 + Starting control server
[ 3560/ 476] 2013-04-29 11:29:09 + Control server started
[ 3560/ 3404] 2013-04-29 11:29:42 + Incoming rfb connection from 74.95.78.33
[ 3560/ 3592] 2013-04-29 11:29:46 ! write() function stopped because transport has not been initialized yet.
[ 3560/ 3592] 2013-04-29 11:29:46 + File transfer request handler created
[ 3560/ 3592] 2013-04-29 11:29:55 + Connection has been closed
[ 3560/ 3592] 2013-04-29 11:29:55 + File transfer request handler deleted
[ 568/ 4060] 2013-04-29 11:29:55 ! AnonymousPipe::read() failed (m_hRead = 0000000000000008)
[ 568/ 4060] 2013-04-29 11:29:55 ! The DesktopServerApplication dispatcher has failed with error: The Pipe’s read function failed after ReadFile calling (The pipe has been ended. (109))
[ 568/ 4060] 2013-04-29 11:29:55 ! An error has been occurred in the desktop server. Application will be closed.
[ 568/ 4060] 2013-04-29 11:29:55 + The DesktopServerApplication dispatcher has been stopped
[ 3560/ 1460] 2013-04-29 11:29:55 ! AnonymousPipe::read() failed (m_hRead = FFFFFFFFFFFFFFFF)
[ 3560/ 1460] 2013-04-29 11:29:55 ! The Pipe’s read function failed after ReadFile calling (The pipe has been ended. (109))
[ 3560/ 1460] 2013-04-29 11:29:55 ! The DesktopServerApplication dispatcher has failed with error: The ReconnectingChannel::read() function failed.
[ 3560/ 1460] 2013-04-29 11:29:55 ! onAbnormalDesktopTerminate() called
[ 3560/ 1460] 2013-04-29 11:29:55 ! Forced closing of pipe conections
[ 3560/ 1460] 2013-04-29 11:29:55 + The DesktopServerApplication dispatcher has been stopped
[ 3560/ 3064] 2013-04-29 11:29:55 + Connection has been closed
[ 3560/ 3404] 2013-04-29 11:30:26 + Incoming rfb connection from 74.95.78.33
[ 3560/ 3492] 2013-04-29 11:30:29 ! write() function stopped because transport has not been initialized yet.
[ 3560/ 3492] 2013-04-29 11:30:29 + File transfer request handler created
[ 3560/ 3492] 2013-04-29 11:30:41 + Connection has been closed
[ 3560/ 3492] 2013-04-29 11:30:41 + File transfer request handler deleted
[ 3264/ 4016] 2013-04-29 11:30:41 ! AnonymousPipe::read() failed (m_hRead = 0000000000000008)
[ 3264/ 4016] 2013-04-29 11:30:41 ! The DesktopServerApplication dispatcher has failed with error: The Pipe’s read function failed after ReadFile calling (The pipe has been ended. (109))
[ 3264/ 4016] 2013-04-29 11:30:41 ! An error has been occurred in the desktop server. Application will be closed.
[ 3264/ 4016] 2013-04-29 11:30:41 + The DesktopServerApplication dispatcher has been stopped
[ 3560/ 252] 2013-04-29 11:30:41 ! AnonymousPipe::read() failed (m_hRead = FFFFFFFFFFFFFFFF)
[ 3560/ 252] 2013-04-29 11:30:41 ! The Pipe’s read function failed after ReadFile calling (The pipe has been ended. (109))
[ 3560/ 252] 2013-04-29 11:30:41 ! The DesktopServerApplication dispatcher has failed with error: The ReconnectingChannel::read() function failed.
[ 3560/ 252] 2013-04-29 11:30:41 ! onAbnormalDesktopTerminate() called
[ 3560/ 252] 2013-04-29 11:30:41 ! Forced closing of pipe conections
[ 3560/ 252] 2013-04-29 11:30:41 + The DesktopServerApplication dispatcher has been stopped
[ 3560/ 3064] 2013-04-29 11:30:41 + Connection has been closed
[ 3560/ 2880] 2013-04-29 11:40:27 ! Exception in control client thread: «The Pipe’s read function failed after GetOverlappedResult calling (The pipe has been ended. (109))»

I have encountered exactly the same error described here on a Win7 64-bit Pro system. TightVNC 2.7.1 worked fine initially (with or without mirror driver) but after windows updates it would exhibit the 0x0 screen size error. Multiple re-installs and wipes of TightVNC settings had no effect, but downgrading to 2.6.4 resolved the issue immediately.

Источник

vncviewer fais vith «Rect too big»

Bug Description

Binary package hint: xvnc4viewer

package: xvnc4viewer 4.1.1+xorg1. 0.2-0ubuntu4

how to reproduce:

1. server is run on remote kde desktop using krfb with or without authentication . screen size: 1024×768
2. vncviewer is set to use xvnc4viewer backend though update- alternatives. client screen size 1440×900

Connecting to the server let you see the remote host screen and then crash with

VNC Viewer Free Edition 4.1.1 for X — built Jan 7 2007 17:30:38
Copyright (C) 2002-2005 RealVNC Ltd.
See http:// www.realvnc. com for information on VNC.

Sun May 27 19:02:43 2007
CConn: connected to host surya port 5900

Sun May 27 19:02:44 2007
CConnection: Server supports RFB protocol version 3.3
CConnection: Using RFB protocol version 3.3

Sun May 27 19:02:47 2007
TXImage: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding

Sun May 27 19:02:48 2007
CConn: Throughput 1957 kbit/s — changing to full colour
CConn: Using pixel format depth 24 (32bpp) little-endian rgb888
Rect too big: 2602×45584 at 25104,11138 exceeds 1024×768
main: Rect too big

same problem here :
server : 1024 x 768
client : 1680 x 1050
$ vncviewer 192.168.1.150

VNC Viewer Free Edition 4.1.1 for X — built Apr 16 2008 13:23:14
Copyright (C) 2002-2005 RealVNC Ltd.
See http:// www.realvnc. com for information on VNC.

Wed Oct 29 23:03:43 2008
CConn: connected to host 192.168.1.150 port 5900

Wed Oct 29 23:03:45 2008
CConnection: Server supports RFB protocol version 3.3
CConnection: Using RFB protocol version 3.3
.
authorization given for access on server
.
Wed Oct 29 23:03:45 2008
CConnection: Server supports RFB protocol version 3.3
CConnection: Using RFB protocol version 3.3

Wed Oct 29 23:06:04 2008
TXImage: Using default colormap and visual, TrueColor, depth 24.
CConn: Using pixel format depth 6 (8bpp) rgb222
CConn: Using ZRLE encoding
Rect too big: 31349×28192 at 0,0 exceeds 1280×1024
main: Rect too big

Had this exact problem on Gutsy, Hardy, and now Intrepid, using «xvncviewer -ZlibLevel 7 [vnc_display]».

Most of the VNC displays I’m connecting to are Windows 2003 running on Xen (SuSE Linux Enterprise Server 10 SP2). The display sizes range from 640×480 to 800×600. I typically access them through SSH port forwarding, but that may be irrelevant.

Anyway, long story short, I moved over to xtightvncviewer (based on the post I found at http:// ubuntuforums. org/showthread. php?t=695273 ). The problem completely went away, but the speed of the session was abysmally slow (VNC Displays are at a remote data center, accessed through a VPN tunnel). It turned out I needed to specify the encodings. The command that I’m running now is:
xtightvncviewer -compresslevel 7 -encodings «copyrect tight hextile zlib corre rre raw»
I just put that in my .bash_aliases as the command ‘vnc’. So all I need to type is ‘vnc [vnc_display]’.

Works like a charm.

Interesting idea with xtightvncviewer, but I end up getting a similar problem with it too. Here I was connecting to a QEMU session booting OpenSolaris:

]$ xtightvncviewer -compresslevel 7 -encodings «copyrect tight hextile zlib corre rre raw» localhost:1
Connected to RFB server, using protocol version 3.8
No authentication needed
Authentication successful
Desktop name «QEMU»
VNC server default format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor. Pixel format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using shared memory PutImage
Rect too large: 720×400 at (0, 0)
ShmCleanup called
[mhicks@ accra][

Well, that’s a different package, and I don’t want to file bugs for that here.

I seem to have the biggest problems in xvnc4viewer when the emulated system is changing video resolution, which happens multiple times in the process of booting a guest. In QEMU or KVM, the resolution also usually changes when accessing the built-in management console by pressing Ctrl+Alt+2 and then change resolution again to go to the emulated VGA by pressing Ctrl+Alt+1.

One potential problem is that xvnc4viewer seems to destroy and re-create a window whenever the resolution changes (well, my compiz window manager thinks it’s doing that anyway — I’m getting the window open/close effects to trigger at these times). I’m suspicious that there may be a timing issue where the client may be trying to draw an image at the new resolution before the window has switched, or in that instant between the old window being destroyed and the new one being created.

Of course, there’s a decent probability that there are bugs in the bulit-in VNC servers on QEMU and KVM, but the client should be more tolerant of bogus data coming down the pipe.

Источник

Remote desktop (or screen sharing) is an operating system feature that allows users to connect to another computer in a distant physical location and interact with that computer as if it were local to them. A remote desktop is generally operated using a graphical user interface.

The remote desktop feature is useful if you need to access your Ubuntu desktop computer with a graphical user interface from a remote location, if you want to provide remote support to someone else, for certain work requirements, etc.

In this article we’ll go step-by-step in enabling the remote desktop feature (or screen sharing) on a remote Ubuntu computer running either 22.04 or 20.04, and we’ll look at how to connect to them.

We will look at other remote desktop methods and technologies that work for Ubuntu. We have already written detailed tutorials on these methods, so we’ll provide an overview of each one, and link to their corresponding article.

How to Use Ubuntu as a Remote Desktop: Prerequisites

To get started with using an Ubuntu remote desktop, you’ll need to have the following things:

• An Ubuntu computer that you want to use as a remote desktop (this can be another computer or laptop, a server, or a virtual machine).
• A second computer from which you will access the remote desktop (this can be another computer or laptop, a tablet, or a smartphone, with any popular operating system like Windows, macOS, Linux, Android, iOS).
• An Internet connection or just a local network connection between the two computers/devices.
• The IP (or hostname) of your remote computer. All the methods listed in this article require you know your remote computer’s IP address or hostname.

We’ll start by making sure we know our remote computer’s IP address.

Get the IP Address of Your Remote Computer

To connect to a remote computer, users need to enter the IP address (or hostname) of the remote computer into the Remote Desktop Connection client.

• A hostname is a human-readable form of an IP address. For example, the hostname for Google’s website is www.google.com, while the IP address for Google’s website is 142.251.33.100.
• A client is a program that connects to a server. The server is the program that is being connected to. In this case, the server is the remote computer and the client is the Remote Desktop Connection program.

There are multiple ways to find your remote computer’s IP address. A very simple way is by using Ubuntu’s command-line.

To find our remote computer’s IP launch a terminal and run the command:

hostname -I

Example Output

106.87.156.59 10.0.0.1 10.1.0.1

So in our example, 106.97.156.59 is our remote computer’s primary IP address that we’ll use to connect to it.

hostname -I displays all of the IP addresses assigned to the computer. The first IP address in the list is typically the primary IP address. The other IP addresses are typically assigned to secondary network interfaces or used for other purposes (e.g., 10.0.1.1 might be the address of a network printer).

Enable Native Ubuntu Remote Desktop

This method is the most common way to set up a remote desktop on Ubuntu. By default, Ubuntu comes with a very easy way of enabling remote desktop functionality. You’ll just have to click a few buttons to enable the remote desktop functionality, reboot the Ubuntu computer, and it’s ready to be connected to.

This method also assumes you’re using the GNOME desktop environment, which is the default Ubuntu desktop environment. A desktop environment is a collection of software that provides a graphical user interface and makes your computer look and feel a certain way. GNOME is one of the most popular Ubuntu desktop environments.

Ubuntu 22.04’s native method differs a little from Ubuntu 20.04. We will cover both versions.

Enable Native Remote Desktop in Ubuntu 22.04 (RDP and VNC)

Ubuntu 22.04’s native remote desktop functionality uses Remote Desktop Protocol (RDP) by default, but Ubuntu 22.04 also allows Virtual Network Computing (VNC). VNC is a popular remote desktop system, that uses a different protocol, called Remote Framebuffer (RFB).

VNC is considered a legacy method – it is still supported, but RDP is preferred in this case.

A difference between RDP and VNC is that VNC uses a different protocol. RDP used by Ubuntu is an open-source implementation of the Microsoft Remote Desktop Protocol (RDP) while VNC uses RFB (Remote Framebuffer). RDP is more efficient than VNC because it uses a different compression algorithm that is optimized for video and audio streaming.

We will mention both methods.

To enable native remote desktop connection on Ubuntu 22.04:

1. Launch the Settings application and open it.
   
2. In the left sidebar click on Sharing. After clicking it you should see a button for Remote Desktop. Click it and it will take us to our configuration screen.
   
3. Where it says Remote Desktop flick the switch at its’ right. By default you can only view the screen. To also control it click on the switch next to Remote Control.
   
4. Optional: You can set a different user and/or password. We’ll use this to log into the remote desktop.
5. Optional: If you’d like to also enable VNC as a remote desktop method, check the Enable Legacy VNC Protocol box. You can also click on the three dots ⋮ and there you can select whether you want to authenticate by requiring new remote desktop connections to ask for access or by using a user name/password. If you choose for new connections to ask for access, this means that the remote Ubuntu desktop will show you a prompt when someone tries to connect, and someone has to click that they approve this connection.
   
6. Close all windows (the settings will stay saved) and reboot the computer. After rebooting, the remote desktop should be enabled.

Enable Native Remote Desktop in Ubuntu 20.04 (VNC)

Ubuntu 20.04 uses VNC (Virtual Network Computing) as its native remote desktop system.

We can very easily enable it from Ubuntu’s settings. This method assumes that you’re using GNOME as your remote Ubuntu computer’s desktop environment.

To enable the remote desktop feature via VNC in Ubuntu 20.04:

1. Launch your Settings application.
2. In the left sidebar click on Sharing. At the top right of the window you should see a small switch you can click to enable sharing.
3. In the new screen you should have a button called Screen Sharing. Click on it and a small window should pop up.
4. In this window, at the top left of it you should see a switch to enable screen sharing. Click on it. Now you can configure a few other things – whether you want to allow the remote desktop connection also to control the screen, whether you want any new remote desktop connection to have to wait to be granted access, or if they can authenticate using a username/password without waiting to be granted access.
   
5. Reboot the computer. After it has rebooted, remote desktop sharing should be enabled.

Connect to Your Ubuntu Remote Desktop

Now that we have enabled screen sharing on our Ubuntu computer, we can connect to it from our local computer.

As mentioned earlier, there are 2 remote desktop technologies that we can use.

• On Ubuntu 22.04 we can connect using RDP by default (the open-source implementation of Microsoft’s Remote Desktop Protocol), or by using the legacy VNC method (if we enabled it).
• On Ubuntu 20.04 we only have VNC by default.

1. Ubuntu Remote Desktop Using RDP (Remote Desktop Protocol)

To connect to your Ubuntu machine using RDP, we have a dedicated section on how to do that in a related tutorial.

We cover in detail how to connect to an Ubuntu remote desktop from Windows, Linux, macOS, and Android.

1. Check our tutorial here – in the section on how to connect to your remote desktop.
2. In the next section of the above mentioned tutorial, we cover how to optimize your remote desktop connection in case it’s slow or laggy. This can be very useful if you have a slow internet connection. It covers things like setting process priority and reducing image quality to use as little bandwidth as possible.

2. Ubuntu Remote Desktop Using VNC (Virtual Network Computing)

This method assumes you enabled Legacy VNC Protocol if you’re using Ubuntu 22.04. If you’re using Ubuntu 20.04 then it’s the default method for remote desktop.

To connect to your remote Ubuntu desktop computer using VNC you will need to install a VNC remote desktop client on your computer. As mentioned before, in computing, a client is a computer program that accesses a service made available by a server.

You will need to use a VNC remote desktop client software depending on your computer’s operating system. From my experience, I recommend the following:

• Linux: Remmina. If you’re using any of the major Linux distributions on your local machine, I recommend Remmina. It’s a remote desktop client that supports VNC and a lot more. You can find a detailed installation guide on the official website.
• Windows, macOS, Linux, Android, iOS: RealVNC Viewer. It’s among the most popular VNC viewers.
• Windows, macOS, Linux: TightVNC Viewer. It’s also a very popular VNC viewer that I use. For any OS that supports Java, you can just (1) download the TightVNC Java Viewer JAR in a ZIP archive, (2) extract the archive, and (3) run tightvnc-jviewer.jar

To connect to your remote computer just open your VNC viewer software and input your remote computer’s IP address (or hostname) followed by :5900, which is the default port on which the VNC server is running.

• A port is like a door to your computer. You can have many doors open at the same time, and each door can be used for a different purpose. The VNC server is a program that is listening on port 5900 for connections from a VNC client.

Here is how it looks like when I input my remote computer’s ip_address:5900 in RealVNC Viewer, TightVNC Viewer for Windows, and TightVNC Java Viewer (which is compatible with any OS that supports Java).

This is how it looks like when you connect to your Ubuntu desktop via VNC. In the background, we have the computer to which I connected, and in the foreground we have TightVNC Viewer. When I move the mouse in my TightVNC Viewer window, the mouse also moves on my Ubuntu remote desktop computer.

Ubuntu Remote Desktop via Other Methods & Technologies

There are a number of other very popular methods and technologies that can be used to remotely access an Ubuntu desktop. Earlier we covered the most common and convenient method, since it’s typically included in Ubuntu.

The screen sharing method presented above is specific to the GNOME desktop environment. Using the technologies presented below we can use multiple desktop environments as well. Some other popular desktop environments for Linux include KDE, Xfce, and LXQt, MATE, or Cinnamon.

In the next sections, we’ll present an overview of each remote desktop method and a quick preview of how it looks like when we connect to an Ubuntu desktop with it.

From there you can follow the links to our individual tutorials for each method.

Ubuntu Remote Desktop Using RDP via xRDP

xRDP is an open-source implementation of the Microsoft Remote Desktop Protocol (RDP) that allows you to control a remote system graphically. It is available for most Linux distributions.

This method is very similar to the native way of connecting to Ubuntu 22.04, since they use an open-source implementation of Microsoft’s Remote Desktop Protocol.

However, you can use this to connect to any version of Ubuntu, whether it’s 22.04 or 20.04.

The end result will look the same as above, in our Ubuntu 22.04 native remote desktop section.

Ubuntu Remote Desktop Using X2Go

X2Go is an alternative to xRDP that uses the NX technology protocol. NX is a more efficient way of handling RDP traffic and results in a faster, more responsive experience. X2Go is available for most Linux distributions, and is commonly used to provide remote access to systems running Ubuntu.

This is also my preferred method to connect to my remote desktops. I haven’t thoroughly researched the pros/cons of each remote desktop technology, to determine which is objectively the best. So I’ll just say it’s personal preference.

A downside of X2Go is that it doesn’t work with the GNOME desktop environment, which is the one Ubuntu desktop typically has installed by default.

Here’s a screenshot of my remote desktop server. It’s a Cloud VPS M from Contabo.com. It has €8.99/month and 16GB RAM, and I highly recommend it if you want a remote workstation for whatever reason. I’ve been a customer for almost 10 years.

Ubuntu Remote Desktop Using VNC (via TigerVNC Server)

Another option is installing your own VNC server on Ubuntu and connecting to it from another computer.

This is a great option if for whatever reason you can’t use the native screen sharing option or if you’re using some other desktop environment, other than GNOME, that doesn’t come with the screen sharing option natively.

Additionally, this method is more secure than typical VNC access. Because VNC is a popular remote desktop solution, it’s likely that vulnerabilities will often be found for it. This may lead bad actors to trying to exploit this. A good way to mitigate this is by using SSH authentication as an additional measure of security. In our related tutorial you’ll also use an SSH tunnel, which will require you to authenticate with your SSH credentials, on top of authenticating with your VNC user/password.

In our tutorial we cover how to set up a using TigerVNC, which is a very popular VNC server, and how to use it with 9 of the most popular desktop environments.

Here’s how remote desktop via VNC looks like with multiple desktop environments that we cover in the above tutorial.

Ubuntu Remote Desktop Using Chrome Remote Desktop

Chrome Remote Desktop is a cross-platform application that allows users to remotely control another computer using the Chrome web browser. It is available for all major operating systems.

The above tutorial mentions a headless server. A headless server is essentially a computer that has been configured to run without a monitor, keyboard, or mouse. Headless servers are often used for remote administration or running server applications that do not require a graphical interface.

Setting up Chrome Remote Desktop is easy when you install it on a computer that already has a desktop environment installed. It’s a little more challenging when dealing with a headless server, but it’s pretty much same procedure.

Here is how a remote desktop looks like when using Chrome Remote Desktop.

Ubuntu Remote Desktop Using Xpra

Xpra is an open-source tool that allows you to forward the graphical output of one computer to another, much like VNC or RDP. Xpra is designed for high-performance and low-latency forwarding of applications and desktops.

Using Xpra you can basically individually forward any application window or your whole desktop from one computer to another.

Here’s what I mean:

With Xpra you can also access your remote desktop through the Xpra client, and also through a web browser. It is a very interesting software.

Other Remote Desktop Methods Using Third Party Applications

There are other ways to connect to an Ubuntu remote desktop, such as by using applications like AnyDesk, Team Viewer, Splashtop, and many others. We cannot cover all of these methods in this article, but should we cover them in separate articles, we’ll update this article to link to those tutorials.

Troubleshooting

Here we’ll address some issues you may encounter.

Real VNC Viewer Error: RFB protocol error: Bad rectangle

If you get an error saying RFB protocol error: bad rectangle with RealVNC in Windows 10, you can try TightVNC.

Conclusion

In this article, we covered two methods to enable screen sharing and connect to an Ubuntu remote desktop using RDP and VNC. We also mentioned a few other very popular remote desktop alternatives for Ubuntu. We hope this guide helped you in some way. If you encounter any issues or have any questions, feel free to leave a comment, and we’ll get back to you as soon as possible.

Remote access to a Linux host’s desktop with VNC

The following article explains how to access the desktop of a Linux host residing inside the ETH network from another host on the in- or outside by using Virtual Network Computing (VNC)¹. Throughout his article, the following placeholders are used:

• current_host: This is a remote host in- or outside the ETH network, i.e. your office computer or home computer; the host you are currently working on. It will run the software to view a remote Linux desktop, the VNC viewer.

• gateway_host: This is the entrance gateway to the ETH network to bypass the firewall restrictions for connections from the outside, by the name of login.ee.ethz.ch. It is used to tunnel SSH connections in case you choose not to use VPN.

• internal_host: This is the fully qualified DNS name of the target host you intend to connect to, as shown by the command hostname -f on the target host. Students can use an arbitrary shared student room PC like tardis-d12. If you’re using a shared student PC, check it’s availability at login.

• eth_username: This is the username you use to log in anywhere on an ETH provided IT service.

• eth_password: This is your password used in combination with your eth_username which lets you access ETH provided IT services, except for network authentications (see below).

• eth_network_password: This is your password also used in combination with your eth_username which is used for authentication to network services like Wifi and VPN. It is different from your eth_password.

• L: This variable is used as a placeholder for the local port on current_host where VNC connections will be made to. Set it to 1 unless you have other plans.

• R: This variable is used as a placeholder for the remote port on internal_host where a VNC server will be listening after a successfull startup. Set it to 1 unless you have other plans.

Quick Help for fast access

If you wanna have fast access by using VNC, do this. If you wanna get into more deeply, read next paragraphs.

 1. Establish a connection to ETH network with VPN

 2. SSH to your machine at ETH just like:
    $ ssh <username>@<machine>.ee.ethz.ch

 3. Start VNC server on <machine> in a konsole, just like:
    $ vncserver

 4. On your computer at home, connect to the VNC Session via vncviewer app:
    <my_ETH_machine>:<session_number>  e.g. saturn.ee.ethz.ch:1

Notice:
* In order to kill your VNC session you have to make a standard 'Logout' within your VNC operating system.
* If you close the VNC Window by clicking on X (above to the right), the session keeps running and you can login again by using the same <session_number>
* Every start of a new vncserver instance increases the <session_number> (= <display_number>) by one.
* All VNC personal settings are stored in '~/.vnc' directory. You can easily remove this dir (e.g. for cleanup reasons). It will be recreated after you execute a 'vncserver' command next time. 
* To see what VNC sessions are currently running on your ETH machine, type on a terminal:  $ ps -ef | grep vnc
* To kill a 'lost' (orphaned) VNC session do: vncserver -kill :1   (where ':1' is your session resp. display number depending on how many VNC instances you are running)

Connect to the ETH network

If current_host resides outside of the ETH network, you need to connect to it thorugh either a VPN connection or an SSH tunnel. Connecting through VPN is the preferred method as it uses a dedicated infrastructure. Both methods are explained in the following steps.
If current_host is alreay inside the ETH network, skip to Start a VNC server on internal_host.

Preferred method: Connect through a VPN connection

Know your ETH network password

If you’re unsure about your eth_network_password, login on password.ethz.ch with your regular eth_password and change your former eth_network_password to a new password.

Install the VPN client on your current host

• Go to sslvpn.ethz.ch and follow the instructions provided there to download, install and configure the Cisco AnyConnect VPN client provided by central IT services.

• To log in here you have to use your eth_username with an added realm in combination with your eth_network_password, as described on sslvpn.ethz.ch.

• If you have access to additional realms, a.k.a virtual private Zones (VPZ), you can list them by visiting realms.ethz.ch.

Initiate a VPN connection to internal_host

Now you are ready to connect the VPN client on current_host to the ETH network and continue with the following steps.

Alternative method: Connect through an SSH tunnel

SSH tunnel on Linux

The host login.ee.ethz.ch is the entry point for an SSH connection. More information about SSH connections can be found in the article RemoteAccess: SSH -remote_terminal_session.

• Establish an SSH tunnel from the local port 590L on current_host to login.ee.ethz.ch for the VNC server port 590R with your eth_username. The syntax for this is

  ssh -L 590L:current_host:590R eth_username@login.ee.ethz.ch 

• For convenience use the default VNC port on both sides of the tunnel and replace current_host with localhost:

  ssh -L 5901:localhost:5901 eth_username@login.ee.ethz.ch 

• Do not close the terminal window wherein you opened the tunnel

The default VNC port will only be known for sure after you start the VNC server on internal_host

SSH tunnel on Windows 10 with OpenSSH

• Install the optionally installable feature OpenSSH Client in Apps → Optional features → OpenSSH Client

• Establish the SSH tunnel as described for Linux

SSH tunnel on Windows with PuTTY

• Start PuTTY

• Create a session to login.ee.ethz.ch

• Configure a tunnel with port forwarding to internal_host for this session under Connection → SSH

• In Source port enter 590L

• In Destination enter internal_host:590R

• Select IPv4

• Klick on Add, the line 4l590L internal_host:590R appears in the previously empty list of tunnels

• Save the session

A comfortable setup of PuTTY is described in Windows «direct» SSH access with PuTTY

Start a VNC server on internal_host

To start a VNC server instance on internal_host, you need to initiate a SSH connection to it.
If you previously opened a VPN connection, make sure it is still active

Initiate a SSH connection to internal_host

SSH connection on Linux

• If you previously opened a VPN connection, issue the command following command

  ssh eth_username@internal_host 

• If you established an SSH tunnel, enter the above command in the terminal window still connected to login.ee.ethz.ch

• With neither a VPN connection or SSH tunnel, issue the command

  ssh -o ProxyJump=eth_username@login.ee.ethz.ch eth_username@internal_host 

SSH connection on Windows 10 with OpenSSH

• Install the optionally installable feature OpenSSH Client in Apps → Optional features → OpenSSH Client

• Establish the SSH connection as described for Linux

SSH connection on Windows with PuTTY

Follow the article Windows «direct» SSH access with PuTTY

Setup and start the VNC server

Configuration and start of a VNC server works with an ISG-provided wrapper script by issuing the command

vncserver

in your shell connected to internal_host.

Setup and first startup

If this is the first time you start vncserver, you will be asked to provide a password to allow access to the VNC server instance you start now and in the future. It is possible to set the password to allow only observing or also interacting with the VNC session. Choose a strong password, as anyone on the ETH network can connect to your internal_host while a VNC server is running. The password should contain:

• 8 characters²
• Uppercase letters
• Lowercase letters
• Numbers

The setup followed by the startup process will look like this:

Creating directory /home/eth_username/.vnc......
Creating startup_file /home/eth_username/.vnc/xstartup.....

You will require a password to access your desktops.

Password:
Verify:
Would you like to enter a view-only password (y/n)? n

New 'default' desktop is internal_host:R

Creating default config /home/eth_username/.vnc/config
Starting applications specified in /home/eth_username/.vnc/xstartup
Log file is /home/eth_username/.vnc/internal_host:R.log

Note the virtual display number R of your VNC server appearing after internal_host:. It is needed later to connect your VNC viewer on current_host to the VNC server instance on internal_host or to kill a vncserver process manually.
The default desktop started now is Xfce4. If you prefer a different desktop you have to kill the running vncserver process and start it again with the desktop of your choice.
Otherwise the vncserver process terminates after you log out of your desktop environment.

Terminating a running VNC server process

Issue the command

vncserver -kill :R

in a shell on internal_host.

Choose a non-default desktop

To start the VNC session with a non-default desktop, provide one of the options [xfce|gnome|kde|light|xterm]:

vncserver gnome

• Option light starts the light desktop Fluxbox

• Option xterm starts a minimal desktop with a window manager and a xterm terminal window. This option should be used if you intend to use your session to run only one application at the time and start said application on the command line.

Use a VNC viewer to view and control the desktop on internal_host

• If your current_host is an ISG-managed Linux computer a VNC viewer is installed.

• If it is a ISG-managed Windows computer you have to request installation of a VNC viewer.
• If you use your self-managed office or your personal home computer you have to install a viewer yourself.

VNC viewer software

The listed VNC software contains a viewer component and is available for both Linux and Windows:

• TightVNC: Opensource

• TigerVNC: Opensource, a fork of TightVNC with additional features

• TurboVNC: Opensource, a fork of TightVNC with peak 3D/video performance as a goal

• RealVNC: Freeware

The above list is not meant to be complete, feel free to install other solutions on your self-managed computer.

• TigerVNC viewer is installed on managed Linux clients
• On managed Windows clients, RealVNC viewer is installed on request.
• On private clients, use of RealVNC is discouraged. Some versions show error messages similar to «RFB protocol error bad rectangle size 10794×10794» and fail to connect.

Connect your VNC viewer to the VNC server on internal_host

VNC connection from Linux

On Linux issue the command

vncviewer internal_host:590R

VNC connection from Windows or macOS

On Windows or macOS, open your VNC viewer and connect to internal_host:590R.
If you terminate your VNC viewer without logging out of your desktop environment, your VNC session will stay active and you can reconnect to it later on.

VNC connection from macOS alternative

On macOS the built-in VNC viewer may be started by pressing Command-K and entering the url vnc://internal_host:590R. No support is given for this way to connect to a VNC session.

Check (student) host availability

Check with the command htop if any other users are using internal_host ‘s resources right now. If they do, log out and log in to a different host.
A list of student hosts can be shown by issuing the command grep tardis /etc/hosts

VNC server configuration