On 13/09/2011 05:48 PM, Darren New wrote:

>> (OTOH, doesn't X allow more than one user to log in at once?
>
> Not really. Remember, client and server are "reversed". You still need
> one computer per user, and indeed, I don't know of any modern distro
> that lets you lock the screen as one X user and then log in as a
> different user without logging out the first one. (Someone tell me if
> there's a way to do this with Ubuntu! :-)

OK, let me put it this way: X lets you install an application on a 
central server, and have multiple X "servers" (i.e. *clients*) connect 
to that server and have their own instance of the application appear on 
their screen.

If you want to do that with RDP, you need the multi-thousand dollar 
"server" version of Windows.

(Then again, I gather that X is doing all the work at the client end, 
while RDP is doing all the work at the server end and then copying it to 
the client screen...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 13/09/2011 05:50 PM, Darren New wrote:
> On 9/13/2011 3:42, Invisible wrote:
>> I'm told it requires spending hours editing the X configuration files
>> to set up authentication and so forth, and then to make sure the
>> server is
>> started, and then to tell the application you want to run to open on the
>> remote machine rather than the local one (by using CLI options that
>> vary for
>> every individual program so you have to look them up), and then...
>
> You're about 10 to 15 years out of date.
>
> Back when 256 colors was a high-end graphics card, this is how it worked.

So what changed then? Certainly X hasn't changed since prehistoric times...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>> As far as I'm aware, Citrix is a completely different product made by a
>>> completely different company. Terminal Services is just another instance
>>> of the general RDP protocol.
>>
>> http://en.wikipedia.org/wiki/Remote_Desktop_Services
>>
>> Terminal Services most definitely *is* RDP. So is Remote Assistance.
>> Exactly as I claimed.
>
> So did I. the part that you describes as "where you have an expensive
> server-class version of Windows, you install all your complicated
> applications on that, and then end users use their Windows-based desktop
> PC to log into the server and run the applications on that."
>
> Is what I said was not Terminal Services. It may be technically possible
> to do it via Terminal Services, but most entreprises who will require
> this will use Citrix.

Well, this is how *all* of the applications where I work are deployed. 
And as far as I can tell, it works just fine. (Modolo the occasional 
stupid glitches, of course...)

> Read the sentence just below the one where you pasted this from. I was
> mistaken in thinking that they had been bought, but they are indeed in
> bed with Microsoft.

OK, sure. Novell too, I gather...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 13/09/2011 07:17 PM, Francois Labreque wrote:

>> Puzzling thing: There are many, many SSH clients for Windows. There are
>> no SSH *servers*. And I have literally no idea why.
>
> Really?
>
> http://www.freesshd.com/?ctt=download
>
> Or maybe, running OpenSSH's sshd under Cygwin?
> http://www.petri.co.il/setup-ssh-server-vista.htm
>
> Or buying one of the many commercial versions available?

Let me rephrase: There are no SSH servers that are free software.

(At least, 5 years ago I wasted weeks searching for one, and never found 
one.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>>> You can thank Windows for this.
>>>
>>> Nah. You can thank NAT for this.
>>
>> I think it's more the general problem of Internet security.
>
> No, it's a problem of routing. If you can't address the remote computer,
> you can't give it a file, no matter what protocol you use.
>
>>> Note how all of those require a running server on a public IP address.
>>
>> Well, yes. To perform a data transfer, you need a way to contact the
>> other end.
>
> That's my point. It's nothing to do with Windows vs Linux. It has to do
> with public vs private IP addresses.

Certainly it's nothing to do with what OS you're running.

I still think the main problem is that to allow somebody to send you 
data, you have to figure out how to prevent anybody *else* sending you data.

>> I'm told there's a system called UPnP or something which is supposed to
>> allow you to automatically bypass NAT.
>
> The local machine still needs to run something that uses upnp to poke a
> hole in the firewall.

Sure. I'm saying that if you were expecting someone to get/put a file, 
the software that makes this happen could temporarily open a suitable 
port, and then close it when it's done.

That way, you could (for example) have an IM client that doesn't send 
data through a 3rd party.

>> It's news to me that you can transfer files with RDP.
>
> Give it a try. Log in remotely, copy a file off your desktop, mouse over
> the remote machine, and pick paste.

How the heck w...?

Oh, wait, you can set the remote display to not take up the whole 
screen, can't you?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Tue, 13 Sep 2011 19:45:39 +0100, Orchid XP v8 wrote:

> On 13/09/2011 05:50 PM, Darren New wrote:
>> On 9/13/2011 3:42, Invisible wrote:
>>> I'm told it requires spending hours editing the X configuration files
>>> to set up authentication and so forth, and then to make sure the
>>> server is
>>> started, and then to tell the application you want to run to open on
>>> the remote machine rather than the local one (by using CLI options
>>> that vary for
>>> every individual program so you have to look them up), and then...
>>
>> You're about 10 to 15 years out of date.
>>
>> Back when 256 colors was a high-end graphics card, this is how it
>> worked.
> 
> So what changed then? Certainly X hasn't changed since prehistoric
> times...

Other than going from XFree86 to Xorg and apparently an entire 
configuration system rewrite that makes the configuration you remember 
not necessary any more.

Jim

Post a reply to this message

On Tue, 13 Sep 2011 19:40:57 +0100, Orchid XP v8 wrote:

>>> Damn. Setting up SSH has got a whole lot easier than when I tried to
>>> do it with Debian a few years ago.
>>>
>>> I'm presuming it defaults to password authentication though? As I
>>> recall, half the trouble was figuring out how to permanently and
>>> irrevocably disable password authentication and *only* allow public
>>> key authentication. (For one thing, you have to work out how to create
>>> a keypair...)
>>
>> Yes, it defaults to password authentication.
>>
>> To disable password authentication, modify /etc/ssh/sshd_config to
>> include:
>>
>> PasswordAuthentication no
>>
>> Done.
> 
> The solution may not be complex. Trying to find it in the documentation
> often is.

man sshd_config

Search manpage.

Problem solved.

> Now explain how to generate a keypair and put the public half on the
> list of acceptable clients.

ssh-keygen

Then copy the id_rsa.pub (or id_dsa.pub) file to the ~/.ssh directory on 
the target system.

Problem solved.

Jim

Post a reply to this message

On Tue, 13 Sep 2011 19:53:17 +0100, Orchid XP v8 wrote:

> I still think the main problem is that to allow somebody to send you
> data, you have to figure out how to prevent anybody *else* sending you
> data.

No, that's easy.  It's called "authentication and authorisation".

Jim

Post a reply to this message

>> The solution may not be complex. Trying to find it in the documentation
>> often is.
>
> man sshd_config
>
> Search manpage.

And now there are *two* problems... ;-)

In seriousness, manpages are, by definition, *reference* documentation. 
What the standard Unix system lacks entirely is any kind of *explanation*.

>> Now explain how to generate a keypair and put the public half on the
>> list of acceptable clients.
>
> ssh-keygen
>
> Then copy the id_rsa.pub (or id_dsa.pub) file to the ~/.ssh directory on
> the target system.
>
> Problem solved.

That's... interesing. I'm damned /sure/ the manpage said to put the 
files into /etc/sshd or similar. And to edit the SSH configuration file 
to tell it what (local) user account goes with a given key. And how many 
simultaneous logins that user can have, what their shell is, and a bunch 
of other complicated stuff...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 13/09/2011 08:03 PM, Jim Henderson wrote:
> On Tue, 13 Sep 2011 19:53:17 +0100, Orchid XP v8 wrote:
>
>> I still think the main problem is that to allow somebody to send you
>> data, you have to figure out how to prevent anybody *else* sending you
>> data.
>
> No, that's easy.  It's called "authentication and authorisation".

Ah, I see.

So how do you prevent somebody connecting to your server a thousand 
times per second and feeding it duff credentials, thereby preventing any 
legitimate users logging in, and wasting lots of CPU power?

See, security isn't so simple...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message