So I’ve noticed this lately with a VPN workflow I’ve started having to use. VNC Viewer (by RealVNC, our campus-wide install I’m afraid) does not allow passwords to be inserted via Keychain/TouchID. In fact, most times no options show up at all by itself or if you click in the password field. Every once in a while, by clicking around (for example on the visible/invisible widget), I can get the app to appear to show password options (see below), but nothing there you could actually click on or select. Clicking the Passwords… button does not lead to anything.
Unlike most of my other apps, I’m forced to input the password by hand no matter what I do or try. Is this a problem with the individual app or does this go deeper?
No help here, but I’m experiencing something similar with some Microsoft authentication procedure recently imposed on a school email account. I get a password screen in System Preferences > Internet Accounts and I need to enter the password. The one difference is that I can paste, so I’ve saved my password in plain text on the Mac, and when I need to enter the password, I copy and paste it.
So let me then ask this question: any good alternative clients out there? A very long time ago I remember stuff like Chicken of the VNC but it looks like that isn’t being actively developed anymore (nor its replacement Chicken). I also recall JollysFastVNC, but that appears to be a bit costly and I can’t even get the trial to work.
When I started having problems that I blamed on Cisco AnyConnect, I ditched it and started using Shimo. For me, it does the job, although the developer’s response to a query was terse in the extreme. After using it briefly, I posted comments. When I want VPN, I still use it.
That’s likely. Apple screen sharing is based on VNC. You can launch a session in one of three ways:
Via the GUI (only seems to work if the other device is also a Mac):
Open up the network browser. From the Finder, select Go → Network (or type CMD-SHIFT-K)
Open the server
Click the “share screen” button
Via URL
From the Finder, select Go → Connect to Server… (or type CMD-K)
Enter a URL of the form vnc://user@hostname:port, where:
user is the user-name you want to connect as.
If you omit the user@ part, it will attempt to connect using the short-user-name of the account you’re logged in to your Mac as.
hostname is the IP address or host name of the VNC server
port is the port number. The number should be 5900 plus the screen number. For instance, screen :5 would use port 5905.
If you omit the :port part, it will assume port 5900. This is screen :0, which is typically used when mirroring the device’s console-desktop (vs. a separate desktop that isn’t mirroring the server’s console).
Click Connect
Enter the remote server’s password and click Sign In
Directly launch the Screen Sharing app
Locate the Screen Sharing app and double-click it to launch it
This has moved to different locations over the years. On my Big Sur system, it is in the /System/Library/CoreServices/Applications folder.
Type in the URL (without the vnc:// prefix). It will be of the form user@hostname:port. See above for a description.
But, as you’ve pointed out, this may not work if the remote server doesn’t support compatible authentication. VNC’s password and data is not encrypted unless the session is tunneled through an SSH session and Apple’s client won’t automatically create such a tunnel.
If you have a VPN connection to the network where the VNC server is running, it’s probably secure enough, but if the site administrator wants end-to-end encryption, you probably need to use a different client.
If your remote server is expecting VNC over SSH, you may be able to manually create a tunnel and then use Apple’s VNC client over that tunnel. Based on an Apple discussion thread:
In a Terminal session, create an SSH tunnel from your Mac to the remote server that maps some local port number to the remote server’s VNC port. I think this will work:
ssh -L 5999:localhost:5900 -N user@example.com
Where:
5999 is a local port number. Anything sent to this port will be forwarded to the other end of the tunnel.
localhost is the name of the remote server, relative to the other end of the SSH tunnel. If the VNC server is running on that host, use the literal string localhost. Otherwise, use the VNC server’s hostname or IP address, as it would be used by someone logged on to the computer at the other end of the tunnel.
5900 is the VNC port number on the remote VNC server. Change this to the port for the session you want to access. The port should be 5900 plus the screen number. So if you’re connecting to screen :27, then use port 5927
user@example.com is the other end of the SSH tunnel. Replace user with your user name on the remote system. Replace example.com with the remote system’s hostname or IP address.
You will be asked for an SSH password, unless you have previously configured public key-based authentication for accessing the remote server.
Once the SSH tunnel is up, use Apple’s VNC client (e.g. type CMD-K from the Finder) and point it at the local end of the tunnel. For example:
vnc://user@localhost:5999, where:
user is your user name on the VNC server (not necessarily the same name used for the SSH tunnel itself)
localhost is literally localhost. It is representing your end of the tunnel, which is the Mac you’re sitting in front of.
5999 is the local port number you specified when creating the tunnel
When you’re done, after disconnecting the VNC session, go to the Terminal session where SSH is running and type Ctrl-C to close the tunnel.
A shame you spent all that time writing that up because that’s entirely beside this problem. The SSH tunnel was already set up and it works just fine. The problem is what you run through that tunnel and that Screen Sharing is not just any VNC, or rather there is not just one plain vanilla VNC that SS can just deal with. As I’ve been able to verify, SS—unlike VNC Viewer—fails to open to user@localhost:59xx even though RealVNC server is running on the remote host and serving up on exactly 59xx what it’s supposed to. The actual question here is not how to set up a tunnel or launch SS or any of that other stuff. The question is simply what client aside from RealVNC’s own could negotiate the connection. It’s possible the true answer is none due to some proprietary nonsense. But until I hear that, I’m looking out for good alternate client suggestions.
I remember similar issues connecting to my Raspberry Pi. It includes a build of RealVNC’s server and I found that open source clients would not connect to it. I suspect the RealVNC people changed something to deliberately break interoperability with open source builds (many of which were forks from RealVNC’s open source releases).
In the case of my Pi, it didn’t matter, because I ended up configuring it to not run a GUI at all. All my access to it is remote, so I run an X11 server (XQuartz) on my Mac and then SSH to the Pi with the -Y option to forward X11 over the tunnel.
My other Linux box (a PC running Debian) runs the TigerVNC server (a fork from TightVNC) which has no problem accepting connections from Apple’s VNC client.
