Roy Schestowitz wrote:
> __/ [Larry Qualig] on Thursday 16 February 2006 15:43 \__
> > mlw wrote:
> >> Say whatever you want about Windows, blah blah bah
> >> create a shortcut:
> >> ssh -XC hostname program.
> >> Violla!! You have a desktop link to an application on anther machine.
> > Whoah... not so fast. This is interesting and brings up a much larger
> > point. In the spirit of fail disclosure I'll go on record as saying
> > that running X-apps remotely is very cool and the performance is
> > generally better than using something like RemoteDesktop of VNC. But at
> > the same time this example illustrates why Linux is doing so well at
> > the IT/Server level and still strugling at the consumer desktop level.
> > In the IT/Server running X11 apps remotely is a very nice feature. But
> > in this world you also have competent technical people who can take
> > advantage of this feature.
> I agree that there is something less intuitive about this approach (desktop
> within desktop), but see the comments which are yet to follow.
> > Now lets contrast this to the average consumer desktop. I will offer to
> > use my neighbor as an example for this. He's a researcher at Boston
> > Scientific (a medical company) with a post graduate degree in chemistry
> > from Yale. I know him well and would say that he is certainly brighter
> > than the "average" computer user. But he's a chemist who studies
> > pharmaceuticals and not a computer geek. This past weekend I helped him
> > out for an hour or so setting up his new laptop. His problem was quite
> > simple... he wanted to copy a bunch of documents from his old laptop to
> > his new one. First I emailed him and told him the easiest way would be
> > to "share" the drive on his old laptop and copy them over the network.
> > Not a chance this was going to happen without help. So what does this
> > have to do with "ssh -XC hostname program" ???
> > For starters it's not simply typing in "ssh -XC hostname program" and
> > have everything work. One simple reason is that most users don't know
> > the names of their apps. They know how to click on the icon and run the
> > app... but they don't know what the name of the app is. In business the
> > most frequently run app is "Microsoft Word" - business users run Word
> > more than any other app. So assuming that they could do this (which
> > they can't) what would they type?
> > "ssh -XC hostname Microsoft Word" wouldn't work. Even if they added
> > quotes it wouldn't work. Using MSWord as the program name wouldn't work
> > either. The correct name is "WinWord" with the point being that your
> > typical computer user will *not* know the names of their apps. Easy to
> > learn, yes. But users know icons, not application names.
> Two points to make:
> * Do not forget KSSH and similar front ends. SSH is not a command-line thing
> anymore, but experienced users tend to choose that route, which is often
> quicker. This tendency often leads to this misconception that Linux is
> (still) command-line-driven.
> * ssh -XC hostname gnome-panel OR ssh -XC hostname kicker. Put this behind
> the KSSH GUI, for example, and voila! The user has got the entire panel
> imported from the remote machine. No need for any commands or any typing
> into the command-line. User taps icon on the Desktop, a prompt for password
> comes up in a widget, user types in password and waits for a new panel to
> load up in his/her desktop environment. Then, open any application from the
> usual menus.
I'll have to ive kssh a try. To be honest... I never even knew kssh
existed. I've been using ssh (command line) all this time.
> > But there is a much larger problem. How the hell is the average
> > computer user going to learn to setup ssh? First they need to run the
> > SSH server on their machine. That's the easy part.
> SSH is enabled by default on some distributions. Ubuntu only needs OpenSSH
> installed (Synaptic makes this a clickthough job). In SuSE, you need only
> open YaST (or go via Control Centre) and tick a box under the networking
> header. It makes the workstation accessible via SSH, i.e. an SSH-enabled
That's why I said enabling the ssh server is the easy part.
> > But before you can use ssh you need to generate a public/private
> > keypair using sshkeygen. Huh... try explaining a public/private keypair
> > to Joe six-pack.
> No, you need only log in with your password and the key is generated
> automatically. You might be facing some misunderstanding or misconception
> here. I have set up SSH on several boxes and on every distribution I tried,
> the process was largely automatic.
> > So assume that average Joe has a public/private keypair (id_rsa and
> > id_rsa.pub). The keys still need to be copied to the server and placed
> > in the ~/.ssh "hidden" directory and appended to the authorized_keys
> > file. Huh... what's hidden directory average Joe asks? The known_hosts
> > file also needs to be updated to allow connections from this remote
> > system... and so on and so on.
> With all due respect, you are overcomplicating matters only to support your
Not a problem Roy... I've read enough of your posts to understand your
style and I took no offense. I'm actually not trying to over complicate
matters. I'm basing my post on my own experience.
I've used X11 "remoting" at home to run apps on my desktop and have
them display on the laptop. My house is pretty secure and I didn't feel
the need to use ssh to do this. I simply logged in to my desktop via
rsh, set the DISPLAY environment variable and started the apps. (I
probably had to run xhost the first time too.)
My "ssh" experience comes from logging in to the network we have at
work from my home machine. I've been able to do this with Windows
pretty easily for a while now using the Nortel VPN software but I
wanted to do this from Linux too. I asked some of the *nix gurus at
work about this (and these people really do know their stuff) and this
(what I explained) is what they said I should do.
I needed to generate a private/public key-pair on my home system using
sshkeygen. I had to keep one key at home and append the other key to
the list of keys in the ~/.ssh/authorized_keys file and add my computer
to the ~/.ssh/known_hosts file.
Perhaps this is unique to our setup here at work. But I did it and it's
been working perfectly since. But until I did all of this I simply
couldn't access the corporate network from home.
> > The bottom line is that only a very, very small percentage of "average"
> > computer users would have a chance of setting up SSH and getting it to
> > work. Once setup.... great. It works nice. But the reality is that this
> > would be a nightmare for the average nurse or chemist. For them using
> > something like Remote Desktop really is a better solution. But then
> > again... they don't have 20 servers to administer remotely. Which once
> > again explains why Linux does well in the IT/Server world but isn't
> > normally found in average Joe's home.
> Are you sure you have set up and are using SuSE 10?
> While I concur with some of your arguments, I feel compelled to say that you
> got yourself trapped in this illusion that SSH is hard. I have used SSH for
> over 5 years, even as a teenager with near-zero (take away or add two)
> knowledge of Linux. SSH was one of the first skills I acquired and, if I may
> add, I used a front-end for it. It was utterly simple... on par with setting
> up a dial-up connection where you need a username, a password and a
> telephone number (machine's address). SSH activation on the server is like
> pulling a knob.
See the above explanation. I don't doubt you that it can be that easy
in other environments. But my experience is based on getting an ssh
connection from my SuSE machine to the corporate network. Our security
needs are likely much higher than usual which may explain the extra