Re: [school-discuss] Re: Linux in Government: Linux Desktops in the Enterprise with Microsoft Terminal Services | Linux Journal

[Tom Adelstein <tadelste@xxxxxxxxxxx>]

Karsten,

Thanks. I appreciate the feedback. rdesktop has lots of promise for now.
We'll see what happens when Longhorn arrives.

> What rdesktop lacks AFAICT is any way of using some sort of key agent (e.g.:
> ssh-agent) to handle authentication tokens.  Know of any tricks here?

I've seen iterations of port forwarding - but haven't tested them and
understand the ports may not accept encryption. I've seen two
discussions of the issue depending on the server. So, I'm a little
hesitant to share these iterations with you. That said, here's my notes.
You may have a chance to try them before I do.

ssh -l username -C -L 3389:nt.termserver.box:3389 ssh.gateway.box
rdesktop localhost

ssh -g -L 3390:server2:3389 localbox and rdesktop localbox 3390 for the
second server

ssh username@myip_address -L 3390:xp_system:3389

A security update may have plugged this hole where a stream of
customised packets to port 3389 could DoS the terminal 
server. But, Windows users have used Putty to get through, so it may work with OpenSSH too.

Let us know if you get any results.

Otherwise, have fun.








On Wed, 2005-05-04 at 05:06 -0700, Karsten M. Self wrote:
> on Tue, May 03, 2005 at 10:54:49AM -0500, Tom Adelstein (tadelste@xxxxxxxxxxx) wrote:
> > If anyone has missed the advances in how Linux desktops can run
> > Windows applications from MS Terminal Services native in Windows XP
> > Pro and 2003 Server, here's a recap. 
> > 
> > Rdesktop and TSClient have gone up several gradients in capability and
> > do not require server extensions like the Citrix ICA client which is
> > still available for Linux.
> 
> Tom:  I found rdesktop was a pretty slick way to access legacy MS
> Windows systems when I was admining a network of 'em.
> 
> It's got a couple of advantages over VNC, among them that you're not
> bound to the remote host's physical screen geometry (VNC is), and if
> you're doing repetitive tasks on a slew of systems, it's possible to
> access the lot of them in a shell script or one-liner (with
> appropriately named hosts, or a target hosts file), since rdesktop takes
> password on the command line.   
> 
> This is markedly faster than VNC, which
> requires inputting user/pass to log on to each system.  Say you've
> managed to sequentially name your hosts:
> 
>    for i in $( seq 20 )
>    do
>        rdesktop -u Administrator -p s00p3rs3k17 winhost-${i} &
>    done
> 
> ...would launch 20 rdesktop sessions (useful for slogging through
> updates, virus / malware filtering, software installs, and the like).
> 
> Of course, that's also a security issue:  process listings (ps, top, or
> traipsing through /proc) would then reveal your passwords.  What
> rdesktop lacks AFAICT is any way of using some sort of key agent (e.g.:
> ssh-agent) to handle authentication tokens.  Know of any tricks here?
> 
> 
> The other limitation of rdesktop is that it allows  _only_ local _or_
> remote access to a given workstation host.  This differs from both VNC
> and a true MS Windows Terminal Services Client:
> 
>   - VNC:  legacy MS Windows allows only one active desktop session per
>     workstation, however this session can be accessed both locally and
>     remotely at the same time.  Unlike other options, VNC is
>     cross-platform, with both server and client available for legacy MS
>     Windows, GNU/Linux, MacOS, and other platforms.
> 
>   - rdesktop:  allows only one active desktop session per workstation.
>     Remote use locks the local console until remote user logs out.
> 
>   - MS Windows Terminal Server:  multiple remote sessions are allowed,
>     which are independent of the local console session (more like a
>     GNU/Linux X Terminal Server or VNC session server).  My
>     understanding is that this requires specific licensing from
>     Microsoft, specific products (vendors include MSFT, Citrix, and
>     Tarantella (a/k/a "Old SCO").  To the best of my knowledge, rdesktop
>     does _not_ work with WTS, though I've limited experience here --
>     care to disabuse me?
> 
> 
> There's a number of useful compatibility environment options, rdesktop
> definitely deserves more plugging, good article.
> 
> 
> Peace.
>