Session Manager Error: Could not use SSH private key

[nathanshearer]

TurboVNC Viewer 3.0.1 on Gentoo Linux.

I cannot connect to any hosts anymore. Even ones that are not running a VNC server fail with this error before attempting to actually connect:

Session Manager Error: Could not use SSH private key: /home/user/.ssh/id_rsa: invalid privatekey

My ssh private key is valid and has been working for years and still works. I don't use SSH authentication with VNC for any connections and there seems to be no way to get around this error.

Older version 2.2.7 seems to work fine.

[dcommander]

Are you entering just a hostname for the VNC server name? Previously, that was a shortcut for connecting to {host}:0, but with TurboVNC 3.0.x, you now have to specify {host}:0. TurboVNC 3.0.x assumes that, if you enter just a hostname for the VNC server name, you want to connect via SSH and use the TurboVNC Session Manager, which is a more user-friendly way of using the TurboVNC Server. (The Session Manager automatically handles starting a new TurboVNC session, if necessary, and using SSH for both encryption and session authentication.) You can disable the session manager and restore the TurboVNC 2.2.x behavior by setting JAVA_TOOL_OPTIONS=-Dturbovnc.sessmgr=0 in the environment.

That being said, I am curious how you generated your private key. That error occurred with TurboVNC 3.0 and prior with private keys that use the rsa-sha2-256 or rsa-sha2-512 signature scheme or the new OpenSSH private key format, but TurboVNC 3.0.1 should have fixed all of that.

[nathanshearer]

I was connecting via a hostname that resolves to a private IP address without using :0 or any port offsets, for example: server42.vpn.domain.com -> 192.168.100.42 My ssh key was generated a few years ago for my user account with: ssh-keygen -t rsa -b 16384 which has worked for ancient and modern systems alike when using ssh authorized keys. It's big key (deliberately), but that key size is supported by all versions of ssh.

All my vnc servers authenticate with a simple password since they are on a secure network, and some hosts are very old SCADA systems that cannot be updated.

SSH behavior is to attempt using the private key if available, then fail back to password based authentication if needed.

[dcommander]

OK, well, that definitely explains why it was trying to activate SSH. Just add “:0” explicitly or disable the session manager, as described above, to restore the behavior of the TurboVNC 2.2.x viewer. I will look into the SSH key issue. It may be that JSch doesn’t support keys with that bit depth, in which case I’ll have to patch it.

[dcommander]

Regarding the SSH private key, I generated a new key using the exact command line you posted above, but I can't reproduce any problems with it.