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

On 9/13/2011 11:53, Orchid XP v8 wrote:
> Sure. I'm saying that if you were expecting someone to get/put a file,

Yes, certainly. That is, after all, how things like video games do it.

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

Or iconify the remote screen, copy the file, expand the remote screen, paste 
the file. Or just let RDP mount the disks over the link, so they show up as 
networked drives on the remote machine.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 9/13/2011 11:45, Orchid XP v8 wrote:
> So what changed then? Certainly X hasn't changed since prehistoric times...

ssh port forwarding, for one.  It was never hard to forward X. It was hard 
to forward X securely and hard to forward X without first logging in over a 
command line interface.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 9/13/2011 11:45, Orchid XP v8 wrote:
> 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.

Yep. You still need a computer for each user, tho.

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

Um, it's $117 online, and that's with five client licenses.

Even if you don't find a deal, it's $525. Far from "multi-thousand dollars".

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Tue, 13 Sep 2011 20:15:17 +0100, Orchid XP v8 wrote:

>>> 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*.

Depends on the manpage.

     PasswordAuthentication
             Specifies whether password authentication is allowed.  The
             default is “yes”.

Seems pretty straightforward to me.

>>> 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...

There's a difference between configuring sshd and using the public key for
authentication.

You *can* do a host key, but in most cases it's not necessary:

     Normally each user wishing to use SSH with public key authentication runs
     this once to create the authentication key in ~/.ssh/identity,
     ~/.ssh/id_ecdsa, ~/.ssh/id_dsa or ~/.ssh/id_rsa.  Additionally, the sys-
     tem administrator may use this to generate host keys, as seen in /etc/rc.

Jim

Post a reply to this message

On Tue, 13 Sep 2011 20:17:11 +0100, Orchid XP v8 wrote:

> 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?

On my system, I use a tool called blockhosts.  After 5 failed attempts, 
the portmapper won't allow them to connect to the service any more - 
which slows them down (because it doesn't send an ack) and allows legit 
users to login - even on the same port/service - and doesn't waste any 
CPU power at all.

> See, security isn't so simple...

It is when you know what tools are available to use.  That's different 
than "security is hard".

Jim

Post a reply to this message