>>>> In seriousness, manpages are, by definition, *reference*
>>>> documentation. What the standard Unix system lacks entirely is any
>>>> kind of *explanation*.
>>>
>>> Depends on the manpage.
>>
>> No, pretty much all of them list the command options, and that's it.
>
> So I'm lying, then, is that it?

OK, let me put it this way: I've never seen any manpage which is 
anything more than a terse summary of command switches with an 
incomplete description of what they do. The most in-depth manpage I've 
seen is for Bash, which is still only a reference document, not an 
introductory tutorial.

It seems to be that the /purpose/ of a manpage is to be a reference 
document. Which is what you want when you're trying to remember the name 
of the command switch that turns on the feature you want. But it's 
useless when you're trying to figure out how to use a tool you've never 
used before...

Then again, sometimes the manpage just says "use info". And then you had 
/another/ problem...

>>>        PasswordAuthentication
>>>                Specifies whether password authentication is allowed.
>>>                The default is “yes”.
>>>
>>> Seems pretty straightforward to me.
>>
>> Does that disable CHAP as well? Or only plain password authentication?
>> (If I'm remembering this right, CHAP is basically password
>> authentication, but with a slightly more secure wire protocol.)
>
> It doesn't say anything about CHAP.  I'm pretty sure it also doesn't
> change the password encryption method from AES to Triple-DES as well.
> It's not likely to document everything it *doesn't* do, just what it
> *does* do.

So even with this line, people can *still* authenticate by password.

Hence my original statement that it's difficult to turn off all the ways 
that users can get in with a password.

>> I thought the host key is how the server identifies itself to you, not
>> how you identify yourself to the server?
>
> Host keys aren't very commonly used AFAIK.

All three of the SFTP systems we use commercially have them.

>> At any rate, it's news to me that you can create a ~/.ssh folder and
>> sshd will actually take note of this. I don't recall the manpage
>> mentioning this at all.
>
> It's always been that way.  The cited bit above is from the man page and
> says pretty explicitly that the user's keys are in ~/.ssh

OK. So now I'm wondering how come I never saw this information anywhere...

Post a reply to this message

On 14/09/2011 05:54 PM, Darren New wrote:
> On 9/14/2011 1:31, Invisible wrote:
>> On 13/09/2011 10:01 PM, Darren New wrote:
>>> 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.
>>
>> You mean SSH hasn't existed since before System V as well?
>
> *Relatively* speaking, ssh is much newer than rsh. It's also relatively
> new that it will do port forwarding and stuff like that. Remember that
> ssh was standardized in 1995 or so, and X has been around far longer
> than that.

1995? Jesus, that's WITHIN MY OWN LIFETIME! Compared to Unix, which 
almost pre-dates binary computers, that's ultra-modernist!

Post a reply to this message

>> When I looked, I couldn't find any precompiled Windows binaries for
>> OpenSSH anywhere.
>
> They are available now.  Cygwin has also been around for a while, and
> includes an sshd server (in fact, a couple of the versions I found for
> Windows were essentially stripped down installations of cygwin).

Wouldn't that mean that once you connect in, your shell can only execute 
Cygwin binaries?

(Not that this matters if you're only trying to forward ports...)

Quite why you need a complete Unix emulator to run something that only 
sends and receives data over network ports I don't know, but anyway...

Post a reply to this message

> An X /server/ (that is, the X terminal software)? Absolutely.

Mmm, OK.

> Sure, I could just plug in a keyboard and mouse, and use the analog
> input of one of my displays to switch between the two; but having two
> keyboards and two mice on the desk really sucks, KVM switches aren't
> free (as in free beer), and being able to use the Windows task bar to
> switch to the Linux desktop is quite handy as well.

Or you could just use VNC, which works on both platforms...

> An X /client/ on Windows (that is, software running on a Windows host
> and displaying on an X terminal)? Doesn't sound like a common use case
> to me.

OK, fair enough.

Post a reply to this message

Le 15/09/2011 10:26, Invisible a écrit :
>> An X /server/ (that is, the X terminal software)? Absolutely.
> 
> Mmm, OK.
> 
>> Sure, I could just plug in a keyboard and mouse, and use the analog
>> input of one of my displays to switch between the two; but having two
>> keyboards and two mice on the desk really sucks, KVM switches aren't
>> free (as in free beer), and being able to use the Windows task bar to
>> switch to the Linux desktop is quite handy as well.
> 
> Or you could just use VNC, which works on both platforms...

try playing xonix via VNC... it's far easier with just a X server on the
windows system.

It's just a shame that windows applications are unable to be translated
into X clients by MS. (well, they still have that "one user at a time"
approach in a lot of their code too)

> 
>> An X /client/ on Windows (that is, software running on a Windows host
>> and displaying on an X terminal)? Doesn't sound like a common use case
>> to me.
> 
> OK, fair enough.

Post a reply to this message

Le 15/09/2011 10:12, Invisible a écrit :
> On 14/09/2011 05:54 PM, Darren New wrote:
>> On 9/14/2011 1:31, Invisible wrote:
>>> On 13/09/2011 10:01 PM, Darren New wrote:
>>>> 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.
>>>
>>> You mean SSH hasn't existed since before System V as well?
>>
>> *Relatively* speaking, ssh is much newer than rsh. It's also relatively
>> new that it will do port forwarding and stuff like that. Remember that
>> ssh was standardized in 1995 or so, and X has been around far longer
>> than that.
> 
> 1995? Jesus, that's WITHIN MY OWN LIFETIME! Compared to Unix, which
> almost pre-dates binary computers, that's ultra-modernist!

Not only, but current ssh is version 2, which leave the status of draft
only in 2006; (1.99 is drafted version 2)

ssh of 1995 was version 1 and limited to remote shell (with very limited
inband file transfer).

Post a reply to this message

Am 15.09.2011 10:26, schrieb Invisible:
>> An X /server/ (that is, the X terminal software)? Absolutely.
>
> Mmm, OK.
>
>> Sure, I could just plug in a keyboard and mouse, and use the analog
>> input of one of my displays to switch between the two; but having two
>> keyboards and two mice on the desk really sucks, KVM switches aren't
>> free (as in free beer), and being able to use the Windows task bar to
>> switch to the Linux desktop is quite handy as well.
>
> Or you could just use VNC, which works on both platforms...

Why would I care about the thing working both ways, if my primary 
machine is the Windows machine?

That aside, using VNC would of course have required me knowing of that 
animal (which I didn't); X was a thing I knew would do the job I wanted 
(provided I could find a free X server for Windows, which I did), so 
obviously that's what I went for. (And as it runs fine now, there's also 
no motivation for me to even try anything different.)

Plus, X11 is still at the core of all the fancy Linux GUIs anyway 
(whether it is KDE or Gnome or whatever), and is /designed/ for remote 
desktop sessions, so why bother to add yet another layer of complexity 
to get a feature that's already there.

Post a reply to this message

>> Or you could just use VNC, which works on both platforms...
>
> Why would I care about the thing working both ways, if my primary
> machine is the Windows machine?
>
> That aside, using VNC would of course have required me knowing of that
> animal (which I didn't); X was a thing I knew would do the job I wanted
> (provided I could find a free X server for Windows, which I did), so
> obviously that's what I went for. (And as it runs fine now, there's also
> no motivation for me to even try anything different.)
>
> Plus, X11 is still at the core of all the fancy Linux GUIs anyway
> (whether it is KDE or Gnome or whatever), and is /designed/ for remote
> desktop sessions, so why bother to add yet another layer of complexity
> to get a feature that's already there.

As far as I know, getting X to actually work remotely is extremely 
difficult, whereas I know from experience that getting VNC to work 
remotely is trivial.

On the other hand, if you have something that works, then there isn't 
really a problem to solve.

Post a reply to this message

Am 15.09.2011 15:22, schrieb Invisible:

> As far as I know, getting X to actually work remotely is extremely
> difficult, whereas I know from experience that getting VNC to work
> remotely is trivial.

"Extremely difficult" is an exaggeration. It wasn't as trivial as 
throwing some switch in YAST, but with a bit of googling it was quite 
easy going, despite me being far from a Linux expert.

Post a reply to this message

>> 1995? Jesus, that's WITHIN MY OWN LIFETIME! Compared to Unix, which
>> almost pre-dates binary computers, that's ultra-modernist!
>
> Not only, but current ssh is version 2, which leave the status of draft
> only in 2006; (1.99 is drafted version 2)
>
> ssh of 1995 was version 1 and limited to remote shell (with very limited
> inband file transfer).

I'm told v1 isn't as secure either. I don't know if that's actually true...

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

Post a reply to this message