New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Why no SSH-tunneled VNC?
Something I was wondering. Every provider that offers KVM also offers VNC for console access. We all know VNC is unencrypted and passwords can't be longer than 8 characters (unless you buy a commercial VNC application). It seems to me that it would only be logical to offer tunneled SSH with VNC so the connection is encrypted and you have better security (given that you only allow VNC connections on 127.0.0.1 or on a local network). So, what's the problem I wonder? SolusVM? Too much work? Something I'm missing here?
Comments
The biggest problem would be explaining to the customers how to use the SSH tunneled VNC. Support costs.
Remmina has a handy option for that, but I'm just assuming other software may not have it.
It also could be an option if you ask me, so people can use the tunnel if they want (when on public WiFi or at work or something).
Well, unless it can all be integrated in SolusVM (or whatever panel is used) so that it's just a point and click for the customer...
Sshuttle all day.
by personal vpn
This. But not only that, you'll alienate clients who want the easy way. Now, it's easy to stand on the outside and say "Well screw them." However, you might as well also say "Screw profit" at the same time. Convenience and security are traditionally opposite sides of the scale. A balance must be achieved.
openitc/xenvz support Spice to connect to it's KVM VPS.
"Console settings
We highly recommend using Spice where possible thanks to the TLS encrypted channel.
Console type:
VNC (Plaintext)
Spice (TLS)
"
Never tried it.
I have that exact problem with my KVM provider. No security on the VNC connection. I use the VNC connection for emergencies only, such as when I accidentally misconfigure the firewall. I would reserve such VNC connections to a reasonably trusted network - not Starbucks, or the school dorm, or a hacker conference. As soon as the problem is fixed, I would burn the VNC and root passwords by changing them both over a secure channel, of course.
It would be nice to have VNC tunneled through SSH, but my provider's SolusVM doesn't seem to offer it, and high security for these corner cases is not a priority for Soluslabs.
Allow me to point out that you must always trust your hosting provider, because your VPS is on their node, which they control completely. If you eliminate the hosting provider from the threat model and you are operating from a "trusted" network, then your exposure is relatively low, as long as you are efficient about fixing the problem.