- ssh -N -L 6666:\!\*:5900 remotehost
Finder / Go / Connect to Server
vnc://localhost:6666
It's slow as shit. Even bouncing dock icons are painful. Dragging a window is a 30 second ordeal. Where is the "go faster" crank?
Trying to search for answers to this question on the interwebs produces, unsurprisingly, a lot of cargo-cult palm-frond tail-section mockups that I do not believe.
Usng a vnc: URL like that will get you the macos built-in VNC client.
Have you tried different VNC clients to see if that affects performance?
There is a "Remote Desktop" app on the mac app store, I think.
The compresson flavors are many and varied. Some are shared between
multiple clients, some flavors of compression are proprietary
or only implemented in a paired client/server from a single vendor.
Yeah, so, I'm hoping for a more authoritative answer than "I have no idea, but you could download a bunch of random crapshoots and see if one of them works better".
It sounds like both client and target are macs in your scenario.
Having read the other follow ups so far, I would +1 these:
1) If target is headless try a fake HDMI dongle to trick the target MacOS.
2) Fork out bucks for Apple Remote Desktop.
IIRC older versions of the VNC client had an option in the view menu to reduce the quality. Maybe there’s a hidden setting to reenable?
VNC just is what it is. For ssh tunneling, there are a handful of tweaks that can help, but it's not going to be fast. And with the Mac, we are limited in our ability to drop color depth and such to speed things up.
I've been using NoMachine NX server/client for a few years now, and it's largely been working great, and it's quite usable even over my poor ISP connection (2Mb/sec upstream). It can be scripted pretty easily and ssh tunnel the same as VNC.
On another Mac, I've recently managed to set up an RDP server clone which...is fast, but I'd never recommend it for anything, it's way too fragile.
Much like the script you have above, I have one which ssh's into my house, sends a WoL packet to the target machine, waits 10 seconds, and ssh's back in to set up the tunnel, then launches NX.
I should say, when I say "largely been working great", the only issue I have is that I can't do multiple active sessions. So if my wife is sitting at that machine, it'll just say "waiting for remote user to authorize session". That's about it. Aside from that, works great, and I just might not be reading far enough to make multi-session work because it's a pretty infrequent problem for me.
My client machines are Linux, and I have a few Macs and Linux machines as servers.
As others are saying, you can put -C on the ssh session, and use a 20 year old deprecated crypto suite to speed things up a bit, but VNC's just not fast on Macs, even on the local network, let alone over the Internet. I've never used ARD because my client machines are Linux anyway, not to mention $$$.
I have to second NoMachine (proprietary, formerly open-source and known as NX, but free for personal use). It does work better than VNC for me (Linux client, OSX remote machine).
It has a quality slider and options for doing a little finer control over display encodings, buffering, frame rates, etc. The pipe I use it over is fairly fat, so YMMV, but I suspect you could find settings which work a lot better than VNC for you.
C.
Thanks, I hadn't looked at licensing, I've been using it continuously since it was open source so I'd no idea that you even could pay them money. It looks like it's not even just "Free for individual use" but rather "Free, but if you want a bunch of Enterprisey or Cloud stuff, we'll sell it to you".
But it is definitely really fast and convenient.
3rd for NX. I ssh tunnel to my parents house from time to time and do connections using it when they need help with stuff and aside from an initial pause on first screen draw, it’s quite speedy. I even use it when I remote into my iMac from my living room vs screen share/vnc simply because it’s more usable.
I installed nomachine and I can't get it to do shit. In particular, it does not seem able to communicate with the remote machine over the ssh tunnel I have already set up, which means it can never, ever work. It seems to include its own implementation of ssh that can only make direct connections and wants me to select my id_dsa file for some baffling reason?? And the documentation crap.
Yeah I don't use any of that "nxssh" nonsense, and didn't really know it existed until reading up on it because of this thread. This really is fast enough that it's worth the weirdness to set up. Fast enough that I can move windows around over a 2Mb/sec connection without smashing my monitor. I'll post full configs for both the client and server tomorrow. My ssh tunnel looks very much like the one you posted, excuse all the garbage amateur shell scripting:
#! /bin/bash
# ssh in and WoL the Pro
ssh -c aes256-ctr xrayspx@home.xrayspx.com 'wakepro'
sleep 10
# Build the tunnel for NX to use
ssh -c aes256-ctr -N -L 4003:10.250.0.99:4000 xrayspx@home.xrayspx.com &
# Get pids so I can kill them all later when the session is closed
sshpid=`jobs -p`
echo "SSH is: $sshpid"
shellpid=`echo $$`
echo "Shell is: $shellpid"
# Launch saved NXPlayer session configured for the Pro - Set to connect to Localhost on 4003
/usr/NX/bin/nxplayer --session ~/Documents/NoMachine/home-pro.nxs
kill $sshpid; echo "killed pid $sshpid"
kill $shellpid
Unsurprisingly, the macOS version of their application bears little to no resemblance to what you have typed.
Yeah that was the script I use on the Linux client, the paths all needed to be updated for a Mac.
I've just made a way overly-simplified setup guide on the chance that someone else might want this someday. The guide was done based on Macs on both the client and server side, starting with a fresh server install to make sure I hadn't missed any steps.
If anything there doesn't work, I'm happy to test more. It should be as easy as "set up the ssh tunnel, click the saved connection".
Thanks for giving the lazyweb a task to focus on this week.
Thanks, your instructions were very helpful!
NoMachine is still... pretty baroque, but that "quality" slider makes all the difference.
One problem I haven't figured out yet that maybe you have an idea about: I can log in from home to work as "jwz" but not as a different user (the user who is logged in on console).
I installed the NoMachine app on both home and work machines as user "jwz". The work machine has user "icecast" logged in on console. User "jwz" on the work machine has the NoMachine menu in the menubar, but "icecast" does not. When I log in via NoMachine as "jwz" it creates a new desktop session for me, which is fine. But when I try to log in as "icecast" to share the existing desktop, I get "No available sessions on this server".
That's with the ssh tunnel running as "jwz" on both ends. If I run the ssh tunnel as "jwz->icecast" then instead the error I get is "54: connection reset by peer" and ssh reports "channel 2: open failed: connect failed: nodename nor servname provided, or not known".
Man I really thought I had this one. I thought it was going to be as simple as logging out the Icecast user and logging them back in. I created a new user on my test machine and logged the test user in, uninstalled NX, rebooted, logged in as both users, re-installed it as using my regular admin user and verified that the new test user did /not/ have the icon in their tray. I expected it to give me the same behavior you see, but when the test user was active on the console and I logged in as them, it just logged me right in and gave me their desktop.
In fact, it sounds like if Icecast is logged in at the console, and you log in as jwz, you get a fresh jwz virtual session, or access to a logged in session anyway. That's the functionality I wish I had, and which I thought was only part of the paid version, actual multiple active user sessions, one at the console and one virtual. In the rare case that I try to connect from remote and my wife is using the machine and I connect as me, I just get timed out because she doesn't notice the "allow user to connect" window, and even if she allowed it, I'd just be taking over her desktop session.
Nope, I still can't find any way to use NX to log in as "icecast". The NX menu is not in the menubar, which is likely the root of the problem. I even tried making the "icecast" user an admin and re-installing NX, but nothing I can do will make the menubar show up, or have "nxnode" show up in Prefs / Security / Privacy / Accessability. I can't add it to that list by hand, either.
If "icecast" is logged in on console, and the ssh tunnel is running as either "jwz" or "icecast", NX can't log in as either "jwz" or "icecast".
BUT!
If I VNC in to the other machine; then log in as jwz; then say "self" to the "log in as yourself, or share display?" question; then log in again on the Mac login screen, THEN I can NX as jwz.
So it only works if there's already a jwz session running, even though that session is a "virtual" non-console one.
And there's no way to get an icecast session at all.
Perhaps there's some way to manually launch /etc/NX/nxserver as "icecast" on the target machine to get around this, but I haven't figured it out.
Yeah that's weird, I've been trying and failing to replicate the issue, though the "54: connection reset by peer" error does seem to be solveable according to the NoMachine forums.
I'm wondering if something running as the Icecast user might not like some of the stuff NX does to the local session. In the server settings, you can disable things like blanking the local (physical) display when someone connects, changing the local resolution to match the client window size, and I'd probably turn off all the device forwarding, "enable audio streaming", etc.
I'm thinking of setting up IceCast with a stream based on input audio to see if maybe that's stopping NX from grabbing multimedia control or something similar. My thought was that if IceCast is streaming from the audio in, and NX tries to stream that input to the client, that could choke. Are you just using the audio line-in, or is there some external USB dingus feeding sound to the machine? If it's just line-in that'd be a pretty easy test for me to check off.
In my case, all my users are "regular guy" users, so the Admin user thing shouldn't make a difference.
Does NX have log files I could look at? I didn't find any.
I am streaming audio from the line-in headphone jack using both Nicecast and OBS -- which demonstrates that it's possible for more than one process to read that at the same time.
Nothing else funny about the desktop display settings. Just a normal user account with blanking turned off, auto-login turned on, running in 1080p.
Just the quick test of taking audio output from my phone and listening to the line-in audio with Quicktime didn't break it either. Though with audio playing on the server, it doesn't automatically stream to the client either, which I've never tried or thought about before.
Yep, the logs seem to be at:
/Library/Application\ Support/NoMachine/var/log/
As I said, I've seen threads on their boards about people having solved this on various platforms, but they don't seem to say how, so I think it might be a catch-all error.
Huh! Well I rebooted a couple of times and now "icecast" has the NX thing in the menubar, and I can connect? So.... shrug. I guess it's working for now...
Cool! Welp, back to sysadminning my media libraries. It doesn't ever end.
I don't have anything more authoritative, but there's the mildly obvious: Have you tried adding '-C' (compression enable) to that ssh commandline?
The inbuilt VNC server is trash, even on gigabit LAN. It can’t encode fast enough, it’s obviously doing a some shitty screen-scrape.
From the Mac users I know, the only thing works is Apple’s paid Remote Desktop software. For 80 bucks. And if you want to display it on a non-Mac? Lllolollol
That’s all you have.
I second this. I did a fair bit of this ~6 years ago, and I don’t think anything’s changed, but at the time the Apple Remote Desktop app was the only thing that worked reasonably well.
And it does have a ‘go faster’ crank in the form of a slider to adjust image quality.
It’ll probably freak out if you try to ssh-tunnel and point it at localhost—it may use multiple ports—but it does have radio buttons to choose between “Encrypt all network data (more secure) / Encrypt passwords and keystrokes only (faster).” And it definitely works ok over a VPN tunnel. For a poor-person’s VPN tunnel, my go-to would be to fire up a local VM so that there’s a separate IP for ARD to see, set up SSH listening ports on that, and watch tcpdump to see if you’re missing stuff.
I have no idea what MacOS does with vnc, but other vnc viewers I've used see "oh, I'm connecting to localhost!" and use raw uncompressed encoding because it assumes it's not actually going over a network.
When I use vncviewer through an SSH tunnel, I add the arguments -encodings "tight hextile zlib corre rre"
FWIW, if I connect to some other hostname that just so happens to have the IP address 127.0.0.1, it performs just as badly.
It resolves the hostname before determining whether it's localhost. However, you can fool it if you bind and connect to another local IP, like 127.0.0.100, at least in my testing.
If you use Remote Management rather than Screen Sharing (check your Sharing settings), you can use the Apple Remote Desktop client to connect and you can configure the quality with a slider.
Unfortunately, ARD is $70 or something and sucks for a bunch of other reasons.
An alternative client is Screens, which also costs money ($30?) but lets you scale the display. However, it only gives you two quality settings. Still, overall Screens is much better than ARD.
You can avoid clicking Finder menus with open vnc://localhost:6666, assuming you haven't changed the vnc:// handler from the default.
The only thing that worked for me in the past for VNC through SSH (even if not with Mac) was changing the cipher to something faster in the SSH tunnel. I remember arcfour being noticeably faster than others. Maybe it is worth a quick try...
One thing not to waste time trying - I use AnyDesk for remote support, and that doesn't help - dialing into a Mac is always painfully slow because of all the animations. Click on a different browser tab, wait whilst every single pixel travels to Mordor on foot in its way off the screen.
Can you use XRDP in your setup? Haven't used it on Mac, but linux distros usually have the client pre-installed. It's the only protocol I've found usable outside a LAN, doesn't need any tinkering to work, and I haven't had an issue with desktop managers either.
I hate to tell you this, but this is an area where free software seems to fail, but propriety software basically has it down, and apple seems indecisive. I did remote for many years and tried nearly everything. I don't trust companies, so I always used ssh text mode, and web port forwarding. Every fucking vnc in history has felt slow. ARD has worked at times, but it's also $ and it rarely worked well for me. Microsoft has RDP, which works fine, but who cares. Even skype used to work okay between macs, but I don't trust it now. But whenever I used GoToMyPC/GotoMeeting/Logmein it seemed to work fine. But it was always someone else who set it up and paid for it.
Google Chrome remote desktop is "free" and probably works okay if you're at google HQ, but since it basically does a video stream, it's actually not so good. I found it sometimes annoyingly laggy to things in the same room. But they're probably improving it as we speak. I've heard nomachine works okay, but I haven't tried it.
You probably know/don't care, but ... SSH just seems to never be able to even come close to ever doing anything at full speed. Even just TCP seems like it actually sucks for everything other than one big fat stream. E.g. games mostly use UDP or their own protocol to get decent interactivity. Even HTTP/3 sort of uses UDP.
The other problem is you basically want to intercept the lowest level graphics API, in this case "Metal" and apply smart caching/compression/encryption, smush it through the old protocols, and then reassemble something exactly like it but better on the other side. But if want to have more than a few users and survive the next API change, you have to make it work for X11/w extensions including GLX, and MS Direct X versions 0-current. Since it's apparently an "unsolved" problem how to make web traffic fast, it's uh.. like harder or something. I don't know how the companies that pull it off do it, but I do know it's a perpetual enterprise cash cow. (please forgive/ignore my venting about this)
This. I investigated all the options for remotely administering my headless mac mini media PC, and the only solutions that did not suck were various free-for-personal-use, paid-for-corporate-use remote control apps.
Sadly such apps have a distressing tendency to decide they are losing too much money by letting individuals use the app for free and go paid-only. Currently, Splashtop is free if you're remoting into another device on the same LAN network, and quite reasonably priced if for individuals who want to access a limited number of devices on a different network.
Is the target headless? I had this exact problem VNC’ing into a headless mac Mini, and the solution was to plug something (anything) into its HDMI port. The one I got is apparently discontinued, but the magic search string is “HDMI dummy plug” at your favourite online retailer.
HTH!
Part of that is going to be the ssh overhead
I've witnessed anywhere from 30-50% speed degradation in ssh vs untunneled connections, personally
Many years ago, I used https://www.stunnel.org/ to tunnel VNC over the internet between Windows PCs. That might perform better than SSH.
I think I created self-signed certificates for both ends of the link (using client certificate authentication). Then the VNC server listened on localhost and ran a stunnel server that listened externally, and the other end ran stunnel and VNC clients. I've lost the exact configuration I used in one PC migrations or another over the years.
Another possibility - on some platforms VNC has a mirror driver that hooks into high-level drawing operations instead of just screen-scraping. I have no idea if this exists on Mac or not, sorry.
If the encryption overhead is SSH, what's a better tunnel for Jamie? Wireguard lets you specify (local) ListenPort and Endpoint can be host-ip:port, and it's much more lightweight than OpenSSL or SSH tunnels. Would that work?
K3n.
beats the shit out of me but i love the imagery of the various data-free cults of connectivity. let me add my anecdata. i connect to macs on my lan with just a plain old `open vnc://hostname` and it has none of the lag (or encryption) that you mention. many of my customers swear by nomachine but i personally think its a load of steaming crap because i'm the one that has to fix that documentation-free, non-helpful-logging, you-get-less-than-what-you-pay-for festering bag-of-bits.
Sorry to be that guy, but obvious problem is obvious. PPTP into a VM running any of the recent windows versions, and RDP will make you understand just how badly Apple has shit the bed on remote access.
In being focused on making a buttery smooth and painfully good looking desktop experience, Apple has missed the trick of extorting good remote access technology from Citrix (which in turn came from the gap between OS/2 presentation manager and the underlying subsystems) in exchange for access to the windows source code.
You're not playing along with the cloud and sell-yet-another-device model, if you don't just do everything in parallel on your home iPad.
macos uses some custom vnc commands when the 'serving' side handshakes w/ a macos client (vs one of the open source-ish clients that i use from linux). this means that the suggestion to try other clients is going to work less well in general, eg, they fail when switching spaces (the animation for switching will seem to get stuck partway trhough the wipe). however, if you change habits (always use the mission control thingee to switch spaces works better than disabling spaces animations) then alternate clients will use the vanilla vnc protocol and things will be usable slow (vs shoot-me-now slow).
of course, ymwv my remote mac is still on the monkeybrains network not too many hops home.
I use Screens, though I'm always going from iOS or MacOS to MacOS. If you're not I'm not sure what the situation is. Even remote and ssh encrypted I find it tolerable. Not at-the-machine good, but workable for anything other than drawing/retouching type work. Certainly none of the long-delay window drags.
....I haven't tried this but... I know you're not looking for ... Don't do that... Long ago when I had to do not this... The problem is obvious!!! Are you sure you want to do this.....
Thank you all for the 'hacker'new by proxy eyeball damage.
There's something called Mosh for getting useful SSH over really terrible connections. It might be getting a bit rusty (the "recent news" was over a couple years ago) but when I last used tried it, Mosh was the most effective solution I found.
[Insert "not screen sharing" flames below]
Nomachine client/server works well (round-trip elimination and jpeg compression ; I have used it on very slow connection). The free soft fork has evolved up to x2go, it seems to works too.
Perhaps your VNC server is crap. I use tigerVNC server (works on slow conections ~1Mb/s 60ms ping) and for a client with it there is the html5 canvas client noVNC that works well.
Another vote for nomachine, it seems faster than screen sharing over pretty much any type of connection. It does however occasionally give you the "No Available Sessions error" finger. At which point running "sudo /etc/NX/nxserver --restart" is in order.
Here's another cargo cult answer, but one that directly addresses a known problem with ssh port forwarding in a different remote access tool: Why nxssh 3.5.0 needs to require the X11 forwarding when the connection is encrypted:
Just to give a counter example for the VNC-bashing: TurboVNC is working fairly well for complex graphics content, but requires the VirtualGL extension for that to work. Unfortunately I only have experience with running the server on Linux and the client on macOS. In that configuration even 3D hacks of xscreensaver starting up on the Linux side works (as in the savers are reasonably smooth over a 100MBit/s connection) without any major problem. TurboVNC even supports Xrandr which is handy once a single desktop session is accessed from clients with varying screen size.
At the risk of stating the obvious : vnc on a localhost connection uses raw encoding. Over gigabit, this is acceptable. Over the Internet this is fail. Are you using -PreferredEncoding ?
As I'm using macOS, and there is no functional VNC client or server for macOS other than Apple's, no, I'm am not using -PreferredEncoding.
I'm just commenting to say that I'm in the same boat, and it's sucks even over a gigabit link. If you find a solution that reduces the suck factor, please do share it with the class.
This is pretty common and usually the reason is that when you connect to 'localhost' most VNC clients (I don't know about the MacOS X one) don't use any strategy to reduce bandwidth use (such as hextile or compression).
Usually it is possible to start the VNC client with an option to use compression, or to set it after starting the client.
Try using one of the non-Apple VNC clients if the Apple one does not allow that.
Are you willing to try out non-VNC methods? At work we have a couple of clients use TeamViewer for screen-sharing. I see that there's a MacOS version, but I've never used it, only the Windows version. It's not open source, but there's a free version.
I am open to any process that involves sharing the screen between two computers over a direct ssh tunnel.
If it involves The Clown in any way, then no.
Fair enough. I don't know if it does or not.