Remote Controlling a KDE 4 Desktop

FAIL (the browser should render some flash content, not this).

How-to set up your KDE desktop for remote access.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Remote control? what, from the couch??

lefty.crupps's picture

This is all well and good when you're connecting from one room to the next, but many of us have remote support issues for family and friends across the city or country. I can run to that other room; I cannot run to my mom's computer without lots of Gatorade...

What port does this VNC run on? Is KDE's Krfb compatible with xtightvncviewer, or just vncviewer? (or maybe these are the same, the first being a Debian package, and the second program looking to be Ubuntu in this video?)

How can we set up a tunnel to allow just the support person to have to open a single port on the local firewall, and allow this connection to be encrypted end-to-end?

How can we get KDE to allow connections on other-than-VNC-standard ports?

It would be very nice if you could expand this tutorial and make it a real-world-applicable, useful HowTo (complete with a transcript of the video for searching purposes).

Quick response:

Shawn Powers's picture

Standard port is 5900, but it can be adjusted in either Gnome or KDE (in the settings of the program I demonstrated, it's an option).

It uses standard VNC, so any viewer works.

For remote computers, you'd need to forward the port on the firewall into the local computer, and set up some sort of dynamic DNS system (there are free ones) so you always know the address to connect to.

There are security concerns with opening firewall port to a VNC client, so at the very least making it a non-standard port is a good idea.

Shawn Powers is an Associate Editor for Linux Journal. You might find him chatting on the IRC channel, or Twitter

re: remote control

lefty.crupps's picture

>> How can we set up a tunnel to allow just the support person to have to open a single
>> port on the local firewall, and allow this connection to be encrypted end-to-end?

> For remote computers, you'd need to forward the port on the firewall into the local
> computer, and set up some sort of dynamic DNS system (there are free ones) so you
> always know the address to connect to.

I understand how opening ports can be dangerous, hence why I asked about a tunnel with only opening the port on the support person's network, and using a tunnel to connect this way. I know it can be done (and I know how to do it), but my point is that your tutorial leaves a lot to be desired in making this actually usable for most situations.

For those who are interested in this approach, here is that tunnel over SSH. This command should be run on the sharing-desktop computer in a terminal (Konsole on KDE) after being adjusted for the correct IP addresses. Once this is run, set up the invitation (or use the always-available connection setup as explained in the video):

shellprompt:~$ ssh -R 5900:localhost:5900 USERNAME@remote.dynamicdns.com -p22
where:
USERNAME is a username on the support person's computer
remote.dynamicdns.com is the support person's IP Address or DynamicDNS domain name.
-p22 is the SSH port on that remote user's computer; 22 is standard SSH but it may be
different in some circumstances

The support person would then run the xtightvncviewer or whatever VNC viewer application to:
localhost::5900

After the connection is finished, the supported person then should run 'exit' in the terminal to close the tunnel to the supporter's computer. Note that during this time, the supported person has shell access to the supporter's computer, so do not use any account that may have root access. Also, having SSH port open to your box is a security risk and should be protected with good passwords, at a minimum.

Some VNC programs use port 5500 and others use 5900, which can make a failed connection confusing for a new user and should be clarified (which you just did, so thank you).

I did misunderstand

Shawn Powers's picture

My apologies, I did misunderstand your original question. I appreciate that you elaborated on your technique in this last comment. It's great when folks work together and add to these tech tips. So again, I appreciate it.

Anyway, that aside, tunneling applications over SSH is a great tech tip. It's not a part of the Gnome and KDE remote control settings, so I didn't cover it here. For me, in a large closed network on the school campus it works great as is.

I think SSH tunneling will make for a great future tech tip though, I thank you for the (possibly inadvertent) suggestion! :)

Shawn Powers is an Associate Editor for Linux Journal. You might find him chatting on the IRC channel, or Twitter

I'm lovin' Linux in a Minute

smpratz's picture

Some of the things you're covering may seem pretty basic to many LJ readers, but it's exactly these sorts of basic HOWTOs that make migrating easier. (Where were you in '02 when I was making *my* switch, darnit?) Heck, they make life simpler for new computer users, period.

Besides, sometimes you hit a topic (VNC under Gnome) which hadn't occurred to me to try. Keep up the great work, Shawn and Mitch.

Thanks!

Shawn Powers's picture

That's great to hear, I appreciate it. I'm also open to suggestions for tips that would be good for folks, at any difficulty level really.

Shawn Powers is an Associate Editor for Linux Journal. You might find him chatting on the IRC channel, or Twitter

An idea, then.

smpratz's picture

To tie in with your VNC videos (and with a nod to lefty up there), it wouldn't take more than a minute to explain installing and using noip2.

That might even lead toward some quick server topics, like remote controlling a BitTorrent client.

Excuse me while I wander off to relive my BBS glory days. :D
/installs Citadel

Great Idea!

Shawn Powers's picture

Hey, that's a great idea. Thanks!

Shawn Powers is an Associate Editor for Linux Journal. You might find him chatting on the IRC channel, or Twitter

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState