Re: wmaker and docked remote apps

[Dave Sherohman <esper@usinternet.com>]

Brad said:
> WindowMaker will do that. But, if you dock the new appicon that was
> created when you ran it with the ssh -f ... command, it should work ok
> then.

Got it!  As I was responding to this, it occurred to me that the -f may
be what's causing the problem.  When I drag over the appicon, the ssh
call still disappears, but if I add the ssh back in manually - without
the -f - I can then restart it by double-clicking on the dock icon and it
runs in the dock.

My guess as to what's happening:

When you do a 'ssh -f remotehost wmmon' from the command line, the -f puts
the wmmon process into the background and the shell keeps running normally.

When you do a 'ssh -f remotehost wmmon' in a dock icon, it creates a virtual
shell session (I doubt that an actual shell process is created, but it's a
convenient way to think of it) which then remains in the dock's 'foreground'
while the ssh executes in the 'background'.  By removing the -f, the app will
run in the 'foreground' and be displayed in the dock.

> I'm guessing you're using ssh-agent or something similar of
> authentication, because i can't get this to work ;)

I just installed the ssh package on both machines, added the lines
'ForwardX11 yes' and 'PasswordAuthentication no' to ssh_config, created
an /etc/ssh/shosts.equiv to each machine containing the other box's IP
address, and sshed from each machine to the other one.

Although I expect to now hear about how insecure this is from others on
the list, the risks appear to be minimal:

- With PasswordAuthentication set to no, each host refuses connection
attempts from non-trusted hosts.  To be trusted, a remote host must _both_ be
in shosts.equiv and have had an ssh connection to it initiated from the local
host at some time in the past.  (The first time an attempt is made, the user
is asked something along the lines of, "I don't know the machine you want to
connect to.  Should it be trusted?"  If the user answers 'yes', the local
host sends over its public key so that the remote host can be identified as
trusted in the future.  Note that this creates a one-way trust relationship.
For two-way trust, you have to ssh from the remote host back to the local
host.)

- My shosts.equiv listings are numeric IP addresses (to prevent DNS
spoofing) as assigned from a nonroutable (to prevent IP spoofing) network
that I use internally.

I'm certainly interested to hear about any other holes that I may be leaving
open!