Ubuntu needs a secure remote desktop
Introduction
If Ubuntu wants to be taken seriously in the workplace, it needs a secure remote desktop. Many people have a need to connect to their work computer from home using remote desktop technology. Currently, the Ubuntu Remote Desktop is a front-end for VNC, which allows you to remotely manage your desktop. It works well, and a nice feature was recently added that alerts you when someone is remotely controlling your desktop.
The Problem
The problem is that VNC provides very little security. It does encrypt the password that you use to connect with, but all other traffic is not encrypted. This means that if someone is intercepting your traffic, it will be possible for them to watch what you are doing (including typing passwords). Another problem is that VNC has a maximum password length of 8 characters, and it does not require a username. This means that an attacker only has to guess 1 to 8 characters correctly in order to connect to your machine. If you use the Ubuntu Remote Desktop, it would be a very good idea to add a password to your screensaver.
This lack of security will make the Ubuntu Remote Desktop a violation of many corporate security policies. Therefore, it is a barrier to the adoption of Ubuntu in the workplace.
You Can Use Duct Tape
You may know that there are many ways to use the current remote desktop securely. Probably the most common method is to forward the entire remote desktop session through SSH. As you can read, this method takes quite a few steps and multiple commands at the terminal prompt.
Here is what I do to connect to the Ubuntu Remote Desktop on my work computer. First, I connect to our VPN server, which encrypts all my traffic. Then I connect to my machine, which is configured to only let me connect through the VPN. To do this, I use the powerful yet simple FireStarter firewall. See my firewall config below: (I am also running FTP and TFTP services on this box)
Long-term Solution
Ubuntu needs to provide a secure remote desktop by default. It should not require tweaking configuration files or typing commands at the terminal prompt. One solution would be to use FreeNX, which can be installed on Ubuntu today. Another solution would be to use the SSH forwarding technique, but to hide all that complexity behind a GUI. All that users need to see is a checkbox that says "Use Encryption". In addition, the maximum password length needs to be increased, and the login should require a username.
References
To learn more about the security problems with Ubuntu Remote Desktop, check out these two essays:
Vino - The Remote Desktop Project
Vino - The Remote Desktop Project - Take 2
If Ubuntu wants to be taken seriously in the workplace, it needs a secure remote desktop. Many people have a need to connect to their work computer from home using remote desktop technology. Currently, the Ubuntu Remote Desktop is a front-end for VNC, which allows you to remotely manage your desktop. It works well, and a nice feature was recently added that alerts you when someone is remotely controlling your desktop.
The Problem
The problem is that VNC provides very little security. It does encrypt the password that you use to connect with, but all other traffic is not encrypted. This means that if someone is intercepting your traffic, it will be possible for them to watch what you are doing (including typing passwords). Another problem is that VNC has a maximum password length of 8 characters, and it does not require a username. This means that an attacker only has to guess 1 to 8 characters correctly in order to connect to your machine. If you use the Ubuntu Remote Desktop, it would be a very good idea to add a password to your screensaver.
This lack of security will make the Ubuntu Remote Desktop a violation of many corporate security policies. Therefore, it is a barrier to the adoption of Ubuntu in the workplace.
You Can Use Duct Tape
You may know that there are many ways to use the current remote desktop securely. Probably the most common method is to forward the entire remote desktop session through SSH. As you can read, this method takes quite a few steps and multiple commands at the terminal prompt.
Here is what I do to connect to the Ubuntu Remote Desktop on my work computer. First, I connect to our VPN server, which encrypts all my traffic. Then I connect to my machine, which is configured to only let me connect through the VPN. To do this, I use the powerful yet simple FireStarter firewall. See my firewall config below: (I am also running FTP and TFTP services on this box)
Long-term Solution
Ubuntu needs to provide a secure remote desktop by default. It should not require tweaking configuration files or typing commands at the terminal prompt. One solution would be to use FreeNX, which can be installed on Ubuntu today. Another solution would be to use the SSH forwarding technique, but to hide all that complexity behind a GUI. All that users need to see is a checkbox that says "Use Encryption". In addition, the maximum password length needs to be increased, and the login should require a username.
References
To learn more about the security problems with Ubuntu Remote Desktop, check out these two essays:
Vino - The Remote Desktop Project
Vino - The Remote Desktop Project - Take 2
TightVNC already has built-in support for SSH tunneling.
ReplyDeleteFreeNX is absolutely great as is has great compression (nice to use from home on a slow line), can tunnel sound, printers..., and can suspend sessions ! So yeah for freeNX. Of course packaging needs quite lot of love to meet ubuntu standards, but I use freeNX at the lab on a thin-client layout and it works great.
ReplyDeleteNoMachine
ReplyDeleteJust this week I rediscovered nomachine.com. NoMachine is the non-free but free NX remote access. It works on port 22 alongside ssh with encryption and secure goodness.
With the recent version, you have the option to login to the "shadow" which is your current session or you can create a fake screen ala terminal services and pick your gui environment, be it Gnome, KDE, Xfce, or whatever.
I got this to work by just downloading 3 .debs. It's killer!
*it's not open source, but it is free as in beer)
Tristan - I just blogged a week or two ago on encrypting VNC in a much simpler fashion than the one you link to at the ubuntu docs.
ReplyDeletevncviewer -via user@host localhost:0
There you go, ssh tunneling which much less trouble than all that -L port:host:port nonsense.
I do agree that the password length limit is ridiculous, but tunneling from the command line can be easy.
http://ubuntu-tutorials.com/2007/06/12/vnc-over-ssh-securing-the-remote-desktop/
Isn't ssh -X enough for the Linux admin?
ReplyDeleteWhy does everyone think we need to emulate an entire screen on our already viable X Window System?
I mean seriously folks, I teach this stuff every month and am completely amazed at the number of people who can't get it through their thick skull that this is unneeded overhead.
I guess you could almost justify it in the Windows to Linux realm, but even there putty or other tools (http://x.cygwin.com/) can forward the X app across the secure localhost tunnel.
So what's stopping people I ask?
Cheers,
Clint
vncviewer already supports ssh with the -via option. This is really simple. But it has three shortcomings:
ReplyDelete- It requires a commandline, although only at the helper's side.
- It requires an ssh server installed.
- You still can log in without using SSH.
So I think point 1 and 3 could easily be adressed through extending current solutions:
- Add support for the via-option/ssh tunneling to tsclient.
- Add an option to vino that only allows access from localhost. This way one could set up a vnc server that is only accessible via SSH tunnel.
Problem 2 is a bit more difficult, as it requires ssh access to the server machine. So maybe a "Use Encryption" optin in vino would have to make sure that openssh-server is installed and would have to add a user account that could be accessed via ssh. But this way you would require a username and long password without having vnc to support it.
NX also is a fine thing, but there is currently a lack of truly free and reliable solutions on client and server side.
VNC will never be a usable alternative in the work place.
ReplyDeleteAnd this is why:
At this time my work mostly involves Windows networks. In which I VPN to a customer or log in through terminal services. Then usually make a new RDP connection to the system I need to work on. I often to this from our own terminal server.
So I have up to 3 nested remote sessions. Do you think that's manageable with VNC? The lag is gigantic. VNC is build to be cross platform. Which is handy and incredibly slow.
At the moment the default VNC installation in Ubuntu doesn't allow you to log in from the Log in screen.
I'm currently running an alternative, but it's still not as flexible as RDP.
"VNC will never be a usable alternative in the work place."
ReplyDeleteAlso, in real work places they use centralized authentication. How well do vino/vnc mix with PAM ? (Kerberos/Ldap etc)
SSH is nice, but opens also for other use, which is not very nice. SSL'ifying the vnc would be nicer in that sense.
Why even consider VNC when SSH is already integrated with PAM? Just make sure that you have:
ReplyDeleteUsePAM yes
in /etc/ssh/sshd_config and ssh will authenticate through PAM. Since sabdfl thinks that Ubuntu will someday grow up and actually be a player in the Linux server market, anything that doesn't allow central authentication via ldap or active directory is not going to work. VNC doesn't support PAM and so it doesn't support LDAP. SSH supports ldap via pam_ldap.so
This means that the only "enterprise" remote desktop (gui-wise) solution for Linux is FreeNX / NX.
A third solution would be VNC with TLS.
ReplyDeleteEver looked at how the VNC password encrytion actually works??? Don't it'll scare you.
ReplyDeleteI tried VNC and could find a good client for it. However, I really enjoy freeNX and it would support it being distributed "out of the box" with ubuntu.
ReplyDeleteAny person calling himself an linux admin should be able to do all the administration tasks using a console login from putty. People complain as they are used to RDP type of administration.
ReplyDeleteHint : I use console access. I use x11 forwarding and import a x11 session if I really need GUI.
Now why would you want to restrict yourself to the command line?
ReplyDelete(1) Having a really poor memory I keep notes, how-to's and examples in a wiki (Mediawiki) so it's either a copy-paste thing, or I add to my notes for the next time. Did I mention I'm also a poor typist and speller.
(2) Don't you fix other things besides the O/S? I do! Fix AND test - which I can do when I'm working directly as the final "user".
(3) I could, and usually do, use the fantastic Webmin product so I can go in quickly without the full log-on. Check it out - ALL my Linux (which are all Feisty) have Webmin installed.
(4) Personally, I use FreeNX (for Linux) and have had NO problems (other than the ones between my ears).
(5) And I do use VNC to a WinXX O/S, although I do find it best to run VNC from WinXX PC - I think it's the fonts that make it stagger around when done from a Linux O/S.
So why, why, would you complicate your life by restricting yourself to CLI when there are great tools available? It's just so last century - FYI, I used to be a Sr. Programmer/Analyst for CICS running on an O/S 360 - life is much better now.
Making life harder on yourself does not make you a better admin. If someone works faster with a GUI, then work with a GUI. Sure, I can do everything using the command line, but things such as file management are a pain in the butt without a GUI, unless you can sed/awk/grep for things to deal with them. And goodness gracious, it's not that much overhead. X was designed for this sort of thing. I understand that you wouldn't want to add this to servers, but we're not talking about that, we're talking about adding it to user's desktops.
ReplyDeleteits not just making it harder for myself, its "how the hell do I have to avoid a 30km round-trip to show this guy how to open a Firfox bookmark for the N-th time this week" scenario.
ReplyDeleteSo _please_ consider user-support roles in this too, not just "I use Ubuntu at home and I forgot something" + "I am Uber-root-meister and never use X"
I need to:-
A/ occasionally access and X-session myself (ever tried to setup and check GoogleEarth via a terminal session?
B/ support real people, who have no beards, who are stupid or scared, and SHOW them what to click/drag/etc
Hmm,
ReplyDeleteHaving a check box to click for "Encryption" doesn't sound like much in terms of configuration options. Really in the corporate environment the admin should be setting up tools they have reviewed, understood, and configured themselves.
Users should not be responsible for such things. Security requirements are IMO more varied than something like desktop appearance; gnome may be acceptable for most companies but that doesn't mean a bank, an isp, and a small business should be using the same security/encryption policy.
Screen Sharing looks like a good idea for Ubuntu. http://brainstorm.ubuntu.com/idea/7487/
ReplyDeleteThe real problem with VNC is that it is GOD-AWFUL slow! Ubuntu needs RDP ... end of story.
ReplyDeleteHmm, some people here are complaining that VNC is so slow and RDP is so much better.
ReplyDeleteI've found it to be exactly the opposite. With moderate to high network traffic I've still been able to get to my Ubuntu box using VNC while the Windows box, on the very same network switch, lags like crazy. I've checked out all the MS KB articles and help on the web but nothing seems wrong... it just lags like crazy when there is other network traffic.
Ubuntu Desktop and Server need an RDP service. End of Story.
ReplyDeleteReasons:
VNC is slow (but somehow performs a little better over some slower connections???)
VNC is less secure (exponentially).
Users connecting to to their desktops should not need to have anything except a shortcut/link that reads "mstsc /v:myworkcomputer.FQDN.com" or "rdesktop -f myworkcomputer.FQDN.com".
End users should not even know what SSH nor should it be open on corporate desktops.
No user should be connecting and controlling their desktops without central authentication and accounting
from an LDAP/Active Directory/NDIS server. An RDP service for Linux should facilitate this through PAM.
The industry demands ease of use, cross platform support and paramount performance. RDP is the best candidate, even against products like Citrix.
Management of Windows servers from Linux Desktops via RDP is already possible. Why not the other way around.
Things I'd like to see happen with RDP across the board:
A command line switch/check box that allows the remote support person to keep the desktop unlocked, and have the support recipient observe the desktop session. Perhaps the support person can logon to the workstation with his or her own credentials and opt to take control of the user's active session. The user will receive a prompt informing them that the support person is trying to control their desktop and requires their permission. Once permission is granted, the support person will be able to see and control the user's desktop.
RDP service for Ubuntu remain active whether the user is logged in or not. I rebooted my system at home, figuring I would just VNC back into and couldn't until the machine was physically logged into.
YOU WANT ENCRYPTED RUN THE VNC TO A VPN ADDRESS HAMACHI 5.X.X.X BOTH ENDS MUST RUN THE VPN WHICH HAS A NETWORK NAME AN A PASSWORD AND IS 256 BIT ENCRYPTED AND THE VNC ALSO NEEDS A PASSWORD LEAVE THE ROUTER PORT CLOSED THE VPN WILL TUNNEL AND ALLOW USE ON ANY PORT
ReplyDelete