Archive for June, 2021

VNC minimal server on RHEL8 / CentOS8 / OEL8

Tuesday, June 29th, 2021

With the update to version 8 (or, if to be accurate, according to common documentations, 8.3 and above), VNC configuration has had a major overhaul, and it is entirely different. Most documentations will refer to using ‘gnome’ as the desktop manager, however – if you want something lightweight with minimal impact (both package-wise and performance-wise), using the minimal ‘xinit-compat’ could work well for you.

To make it work, you will need to follow these steps:

Install the required packages

The required packages are xorg-x11-xinit-session, xorg-x11-xinit, tigervnc-server, metacity, xterm. All dependant packages need to be installed too, of course.

Configuration

The initial (and minimal) configuration required is to edit /etc/tigervnc/vncserver.users and add the required user with a display port. In this example, I have used ‘:1’. The content of the file should look something like this:

# TigerVNC User assignment
#
# This file assigns users to specific VNC display numbers.
# The syntax is <display>=<username>. E.g.:
#
# :2=andrew
# :3=lisa
:1=myuser

Then, set a vnc password for the user, using ‘vncpasswd’ as the user.

Then, create a file in the directory .vnc in the user’s home directory, called config, with contents such as this:

session=xinit-compat
securitytypes=tlsvnc
desktop=sandbox
geometry=1800x1000

Now comes the tricky part (and not well documented) of setting the xinit startup script. Create a file in the user’s home directory called ‘.xsession’ with execution permissions, containing the following code:

xterm &
xterm &
metacity

This file is being read by xinit-compat, and will allow running a minimal desktop with two xterm windows, and a window manager (metacity).

Starting the service

Now, all that is required is to start the vnc service,. Use the command ‘systemctl start [email protected]:1’ . Note that the number ‘:1’ is in correlation to the file mentioned earlier ‘vncserver.users’.

This should do the trick. Let me know how it worked for you.

sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation

Tuesday, June 1st, 2021

This is a problem which bugs the Internet. Many solutions were suggested. All of them work sometimes (like making sure that the permissions on the private/public SSH key files are correct).

One solution which never gets mentioned is about DNS. When attempting login to a remote server, the server attempts to resolve the connecting address (yours) using the DNS server defined to the server. This is the default for SSHD, and I seldom see any reason to change it. However, if the DNS servers are inaccessible, then the login takes very long (actually – waiting for the DNS query attempt to timeout). If this thing happens when using SSH-agent (I use KeePass2 with KeeAgent, as a very secure means of protecting my private keys. I suggest you check it out), the timeout might be just long enough to timeout on the agent’s side, and thus, produce the dreaded ‘sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation’ error message.

The easy two possible solutions (pick one)L

  • Disable SSH DNS query (Remove the comment before ‘UseDNS no’ directive in /etc/ssh/sshd_config)
  • Disable DNS servers – comment out the defined servers in /etc/resolv.conf

This solves the timeout, and with it – this message, and your connection problems.