Desktop computer screen on Raspberry Pi

If I've understood you correctly, you have another (unspecified) computer that you hope to control from the keyboard, mouse and monitor of your Raspberry Pi.

One way to do it is with a VNC server on the unspecified computer and a VNC client (e.g. Avalanche, by James Peacock) on the RPi.

I've only run Avalanche on the Iyonix, to control an Ubuntu box, but it seems to work quite reliably.

The position years ago was that there did not appear to be an equally reliable VNC server for RISC OS. I would like to discover that there is.

Dave

If the PC is running sshd you can run it headless from the RPi. If you've allowed X11 forwarding you can run GUI programs to. I don't bother with a desktop during remote access, so somebody else can explain how to start one (use startx?).

Only if you want to use VNC in place of X. The VNC server needs to be running on the remote PC. You can either ssh in and start it in the target user and logout leaving it running, or you can run it as an xinetd- hosted application. Te RPI rins the client which can either be a desktop application or run as a web app in a browser on the RPi.

Sorry, I failed to notice that I had run past the end of the comp.sys.acorn newsgroups.

Dave

Yes, vnc or rdp. Teamviewer hasn't been ported to linux so there's no hope of a version of teamviewer for raspberry pi any time soon.

I take it that there are no VNC clients for Raspbmc?

I've had a quick search and couldn't find anything. Given that the RPi finds it hard enough to run XBMC, I guess that a VNC client for Raspbmc is highly unlikely?

Guess I'll use Raspbian.

Depends. As others have suggested you can run X11 over SSH. But that requires not only SSH but X at both ends. If you need to go across operaring systems I think VNC and the like are the only solution.

You might be able to do straight X over the network, with_OUT_ going through an ssh tunnel. It's rarely done lately, largely due to security issues. However, it was fairly commonly done during the 1980s (and maybe before).

The basic idea is the X server (the one that will be displaying the stuff on screen) enables reception of X connections from the X client's machine. The xhost mechanism is one way to do that. Then, X client (the one sending the graphical info) sets $DISPLAY to include the hostname of the X server, followed (IIRC) by a colon, followed by the display name on the X server. There may be other hoops to jump through--flavors of X authentication. Also, firewalls must be open to those connections.

HTH

I still do this quite frequently with headless servers and/or other remote systems on the LAN. It's very simple:-

local$ local$ ssh -X remote chris@remote's password: Last login: Sat Jan 11 21:45:07 2014 from acer-aspire.zbmc.eu remote$ thunderbird

... and thunderbird pops up on the local screen (plus a number of warning messages on the terminal).

"with_OUT_"

Sorry?

ahem., he said 'without using ssh tunnel' you said 'I often do this (using ssh)'

I have X11 forwarding enabled in /etc/ssh/ssh_config and /etc/ssh/ sshd_config on all the Linux boxes on my network. So, no matter which box I'm sitting at I can simply run, for example:

ssh user@remotebox # and supply the password, then run oocalc mysheet.ods

and there's the spreadsheet on my screen. The same works for all Linux graphical programs.

scp and sftp file transfers are equally easy.

A recent discovery is that the excellent gftp FTP client can also use the sftp protocol: just set the protocol to SSH2 instead of FTP at login, but you lot probably knew that already.

From

"As it is a Debian system, it is completely expansive and you can install any packages from Debian?s massive repository"

So does Debian have a VNC client? Google took 0.27 seconds to find this.

What is an ssh tunnel but an ssh connection? OK, I use what I'd call reverse ssh sometimes (to make connections possible through a firewall) but apart from the things it can overcome it offers no particular differences or advantages over a 'normal' ssh connection. ... does it?

An ssh tunnel is a normally encrypted ssh session that the client establishes with a remote ssh server but does itself originate or receive any of the data transferred by the session. Instead, the session links a local port, created by the ssh client and that accepts outbound connections from other programs and passes the traffic to and from a specified port on a remote ssh server. IOW you can use this session to securely pass unencrypted data between a client and remote server that do not encrypt the messages they pass.

This is unlike a normal ssh session where the client, typically ssh, scp or sftp generates outbound data and consumes inbound data.

So, confirmation to Robert Riches: you CAN run an X11 GUI program remotely without using an ssh tunnel: Just login to the remote system using ssh, which starts a normal ssh session, and run the X11-using program from the command line. However you'll have to allow X11 forwarding first: you can do this on a per-session basis by specifying the ForwardX11 option or you can make it the default by editing the ssh configuration file, /etc/ssh/ssh_config

You don't even need ssh at all, nor any other remote shell access like telnet or rsh. Xdm can connect directly to a remote system. That is how X-window terminals used to work and I guess it's also what Robert Riches meant. For more details see:

Regards,

Kees.

Telnet is deprecated for remote shell access due to its lack of encryption or security features: the telnet client is still made available because its useful for checking that other plain text servers, such as MTAs, are working, but telnetd, which is needed if telnet is the run a remote shell, is not now a usual part of the telnet package.

The same should apply to rsh/rlogin too because it has the same problems as telnet, which is precedes, though would appear to be more widely distributed (RedHat Fedora no longer includes telnetd though its rsh package includes srh, rlogin and rcp).

On the other hand, in a private home network behind a NAT router who honestly gives a f***?

I communicate with all my internal machines with telnet, because I am the only one who does.

I only use ssh going to a remote machine.

And that has a bloody great hole punched through its firewall anyway so I ()MY IP address) can use whatever I want - I NFS mount its drives with no issues.

And are you quite sure your router hasn't any bugs? I'd remind you that it was only recently that Linksys and Cisco routers were found to be exposing their sysadmin logins on their public side and compounding this this by having a fixed login name and a pretty obvious password.

Relying on your router being bullet-proof by running a telnet daemon when ssh is just as easy to use and not noticeably slower seems like running an avoidable risk to me.

That's an risk I won't take, but obviously its owner is more willing to gamble that the machine won't get pwned than I would be.