On Tue, 13 Sep 2011 17:14:02 -0400, Jim Henderson wrote:

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

Additionally, if I wanted to be more secure on my system, I could run sshd 
on a non-standard port (or forward from a non-standard port in my 
firewall).  Then they have to find the service first, and most of the 
scripts that do that won't bother, because there are easier targets.

Jim

Post a reply to this message

On 9/13/2011 7:00 AM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> On 13/09/2011 11:40 AM, Warp wrote:
>>> Invisible<voi### [at] devnull>   wrote:
>>>> I said that Windows allows it *by default*
>>>
>>>     So how exactly would I transfer a file to you from my Windows?
>
>> You can't. My PC is firewalled.
>
>> You also can't transfer a file using Unix, for the same reason.
>
>    Most firewalls have the ssh port open because it's considered safe.
> (And if it's not, it's easy to open in most distros).
>
>    Then you can use scp, rsync or any equivalent tool to transfer files.
> (There probably isn't any linux distro that doesn't come by default with
> scp and rsync.)
>
>    (Btw, the great thing about rsync is that it can resume interrupted file
> transfers, a rather important feature that, oddly, most file transfer tools
> completely lack.)
>
And even if you do have them.. Sometimes, at least in Windows, it 
doesn't work. Remember a few years back. Bad connection (disconnects 
after about 5-10 minutes), a tendency of files to almost complete, but 
then not, and a 1GB download, which Sony decided should be on a 
non-resumable server... WTF?

Post a reply to this message

Le 2011-09-13 14:37, Orchid XP v8 a écrit :
> On 13/09/2011 07:00 PM, Francois Labreque wrote:
>> Le 2011-09-13 11:20, Invisible a écrit :
>>>>> No, I mean there's a *hardware* firewall in the way. You know, with
>>>>> the
>>>>> big Cisco sticker on it and the 3-digit price tag? (Although obviously
>>>>> that's only because I'm at work right now. My house doesn't have
>>>>> one of
>>>>> those...)
>>>>
>>
>> You're off by two orders of magnitude. Most Cisco firewalls are in teh 5
>> digit price tag.
>
> True. But not this particular one.
>
>
http://www.ebuyer.com/135532-cisco-asa-5505-firewall-edition-bundle-asa5505-50-bun-k9
>

Ok. you got me.  I usually don't deal with small-office/home-office gear.

>
> (Go on, hack me. You know you want to.)
>
>>>> And that hardware firewall is completely incapable of forwarding ssh
>>>> connections? Pretty useless, I'd say.
>>>
>>> No, I don't have the password to configure it.
>
> Still stands.
>
>>> (And besides, have *you*
>>> tried configuring Cisco stuff? It's not exactly intuitive. You probably
>>> need Certified Engineer status to figure it out.)
>>
>> You don't need to be a Cisco Certified Internetwork Expert to figure it
>> out. The Cisco manuals are usually pretty easy to follow, and freely
>> available on their web site.
>
> Really? That might be worth reading...
>

This is a good place to start:

For routers and switches:
http://www.cisco.com/en/US/docs/ios-xml/ios/fundamentals/command/cf-cr-book.html

Or "Support | IOS & NX OS | IOS 12.4 Mainline " from the home page.

Firewalls are a little different, but the syntax is still related. 
Kinda like French and Italian.

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/conf_gd.html

Or "Support | Security | PIX firewall software | Configuration Guide | 
Version 8.0" from the home page.

Note: Even though Cisco firewall appliances are now called ASAs, their 
documentation still cals them PIXes all over the place.

>> And it is actually pretty intuitive...
>>
>> - Give each interface an ip address.
>> - Create your NAT tables.
>> - And off you go.
>
>  From what I've seen, you telnet into the router, enter a password, and
> then enter lines of gibberish such as "enh eth gw all". You would
> *definitely* need a manual to figure out WTH that actually means, or
> what the name of the command you want is.

Two things:

First thing, typing ? at any point will list all the available commands 
at that point.

Second thing, you don't have to enter gibberish.  the commands are plain 
english words.  They can be abbreviated for speed, but

sh ip int fa0/0 bri

Is exactly the same as typing

show ip interface fastethernet0/0 brief

which would show you a brief summary of all the stats it keeps for the 
IP protocol on interface fastethernet0/0. (protocol distribution, packet 
counts, etc...)

>
>> The only difference between a Cisco firewall and a D-link or NetGear
>> home router, besides performance and scalability, is that you can (and
>> should!) override the basic "everything outbound is ok, nothing inbound
>> can come in" configuration.
>
> I'm still guessing that, between the configuration for routing to
> multiple LANs, multiple VPN endpoints, and remote access, adding a line
> that forwards SSH to a port on a desktop PC who's IP address is
> configured via DHCP is probably going to take some doing. (!)

Routing for the multiple lans actually comes straigh out of the box. 
You confiugre an ip address on all the interfaces and it will know that 
any packets it receives whose destination is on another lan interface, 
it will forward it (let's disregard security rules, for the moment!). 
Remote lans are handled the same way they would be on a Windows or Unix 
machine.  By either configuring a routing protocol, or by adding static 
routes.

On Windows, you'd type:

route add 192.168.200.0 mask 255.255.255.0 192.168.1.1

On a router, you'd type:

ip route 192.168.200.0 255.255.255.0 192.168.1.1

On a firewall, you'd type:

ip route [interfacename] 192.168.200.0 255.255.255.0 192.168.1.1

You have to specify the interface name because, as opposed to a router, 
the firewall will drop any packet that has to be routed back out the 
same interface it came in.

VPN endpoints are not more complicated than on any other platform, but 
that's a bit like saying that changing the transmission of a Formula One 
is not more complicated than changing it on a Toyota...  It may not Be 
for a complete noob.

Allowing inbound ssh connections will need that PC to have a static NAT 
address, and therefore a static local IP address.  Your Netgear or 
Linksys home router can work around this because it also acts as the 
DHCP server, so it knows to which MAC adress to send the traffic, but in 
an entreprise where the firewall is a separate piece of hardware, there 
is simply no way to do this.

>
> And we still have the minor issue that I don't have the password. :-P
>

If you have physical access to the box, you can do a password recovery 
and put a new password in, but since this would likely cost you your job 
and may very well land you in jail, I do not recommend you try it at the 
office....

> Actually, I have a NetGear router in my house. I used it to create a VPN
> between my house and my grandparents' house. It lets you do all sorts of
> port forwarding and stuff. The only trouble is... it's not reliable.
> Like, when certain datagrams pass through it, the firmware crashes, and
> you have to power-cycle it to get the Internet back. Eventually I was
> forced to take it out of the circuit, because it was pissing me off so
> much! (No, there isn't a firmware update available.)
>
> Given the price of the Cisco ASA, I'm almost tempted...
>


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 2011-09-13 14:48, Orchid XP v8 a écrit :
> On 13/09/2011 07:17 PM, Francois Labreque wrote:
>> Le 2011-09-13 10:21, Invisible a écrit :
>>> 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.)
>

And how much does Cygwin or openssh's sshd cost?

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 2011-09-13 15:17, Orchid XP v8 a écrit :
> 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...
>

by having a real firewall (such as the aforementioned Cisco ASA) 
configured to throttle individual connections.  ;)

Now the /b/tard in question would have to use zombie PCs to do his DOS 
against your machine.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 2011-09-13 14:53, Orchid XP v8 a écrit :

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

Yes.  I run my work laptop at 1440x900, but the screen sizes for my 
remote desktops are 1152x864, so that I still have the contact list of 
my work IM program and my local taskbar visible.  Makes it easier to 
switch from one server to the other, hunt for local files, chat with the 
boss, or surf the internet while still keeping an occasional eye on the 
Oracle indexes rebuilding themselves.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On Tue, 13 Sep 2011 19:48:55 +0100, Orchid XP v8 wrote:

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

openssh is released under the GPL, and has been around for quite some 
time now (certainly more than 5 years - I'd say more than a decade).

And there are versions that run on Windows - using cygwin or not.

Jim

Post a reply to this message

>>> You're off by two orders of magnitude. Most Cisco firewalls are in teh 5
>>> digit price tag.
>>
>> True. But not this particular one.
>>
>>
http://www.ebuyer.com/135532-cisco-asa-5505-firewall-edition-bundle-asa5505-50-bun-k9
>
> Ok. you got me. I usually don't deal with small-office/home-office gear.

I was surprised myself. Our network switches cost about 3x what every 
other manufacturer wanted.

(I soon discovered, however, that these "switches" are actually just 
24-port *routers*...)

>>> You don't need to be a Cisco Certified Internetwork Expert to figure it
>>> out. The Cisco manuals are usually pretty easy to follow, and freely
>>> available on their web site.
>>
>> Really? That might be worth reading...
>>
>
> This is a good place to start:

OK.

> Note: Even though Cisco firewall appliances are now called ASAs, their
> documentation still cals them PIXes all over the place.

Yeah, we've still got a PIX 506e in the corner. Though damned if I know 
why; that thing was starting to become quite unreliable...

>> From what I've seen, you telnet into the router, enter a password, and
>> then enter lines of gibberish such as "enh eth gw all". You would
>> *definitely* need a manual to figure out WTH that actually means, or
>> what the name of the command you want is.
>
> Two things:
>
> First thing, typing ? at any point will list all the available commands
> at that point.

So... it's some kind of hierarchical menu system? (I had assumed that 
all commands are available all the time.)

> Second thing, you don't have to enter gibberish. the commands are plain
> english words. They can be abbreviated for speed, but
>
> sh ip int fa0/0 bri
>
> Is exactly the same as typing
>
> show ip interface fastethernet0/0 brief

I see.

I'm guessing that unless you do this kind of thing all day, you'll 
quickly forget what the name for each command is, and so you'll need the 
manual open constantly. (I really hope the manuals contain more than 
just a reference list of every command name and what it does...)

>> I'm still guessing that, between the configuration for routing to
>> multiple LANs, multiple VPN endpoints, and remote access, adding a line
>> that forwards SSH to a port on a desktop PC who's IP address is
>> configured via DHCP is probably going to take some doing. (!)
>
> Routing for the multiple lans actually comes straigh out of the box. You
> confiugre an ip address on all the interfaces and it will know that any
> packets it receives whose destination is on another lan interface, it
> will forward it (let's disregard security rules, for the moment!).

Even though there's only one connection from the firewall to the 
(multiple) switches?

> Remote lans are handled the same way they would be on a Windows or Unix
> machine. By either configuring a routing protocol, or by adding static
> routes.
>
> On Windows, you'd type:
>
> route add 192.168.200.0 mask 255.255.255.0 192.168.1.1

1. I didn't know you could do that.
2. What does it do?

> VPN endpoints are not more complicated than on any other platform, but
> that's a bit like saying that changing the transmission of a Formula One
> is not more complicated than changing it on a Toyota... It may not Be
> for a complete noob.

Presumably you have to specify protocol types and encryption keys and so 
forth...

> Allowing inbound ssh connections will need that PC to have a static NAT
> address, and therefore a static local IP address. Your Netgear or
> Linksys home router can work around this because it also acts as the
> DHCP server, so it knows to which MAC adress to send the traffic, but in
> an entreprise where the firewall is a separate piece of hardware, there
> is simply no way to do this.

Quite. The only way this could work is if you wanted to /temporarily/ 
forward SSH (probably on a different port number) to the IP address that 
my desktop PC /currently/ has.

>> And we still have the minor issue that I don't have the password. :-P
>
> If you have physical access to the box, you can do a password recovery

I am *so* not trying this! :-D

Incidentally, I gather that there's two ways to control the ASA. One 
involves telnet. The other involves a serial cable...

Post a reply to this message

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?

Post a reply to this message

On 13/09/2011 10:05 PM, Darren New wrote:
> 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.

Sure. But I mean, you can set up an application server that more than 
one person can access, without doing anything particularly special.

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

OK, well maybe it's the cost of the client licenses I'm thinking of then...

Post a reply to this message

On 14/09/2011 04:22 AM, Jim Henderson wrote:
> On Tue, 13 Sep 2011 19:48:55 +0100, Orchid XP v8 wrote:
>
>> Let me rephrase: There are no SSH servers that are free software.
>
> openssh is released under the GPL, and has been around for quite some
> time now (certainly more than 5 years - I'd say more than a decade).
>
> And there are versions that run on Windows - using cygwin or not.

When I looked, I couldn't find any precompiled Windows binaries for 
OpenSSH anywhere.

Post a reply to this message

On 13/09/2011 09:57 PM, Darren New wrote:
> 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.

Really? I thought they just connect to a central game server. 
(Although... actually they mostly seem to use UDP, so "connect" is a 
little nebulous.)

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

Oh, that works?

> Or just let RDP mount the disks over the link, so they
> show up as networked drives on the remote machine.

Ah - it [optionally] connects local and remote disks, the same way it 
connects printers, right?

Post a reply to this message

>> 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...
>>
>
> by having a real firewall (such as the aforementioned Cisco ASA)
> configured to throttle individual connections. ;)

I'm sorry, I thought we were still talking about "why the average home 
user can't easily send a file to another average home user". :-) I doubt 
many home users will pay hundreds of pounds for a Cisco ASA and spend 
god-knows how long learning what "tee sea pee eye pee" is in order to 
set this up.

> Now the /b/tard in question would have to use zombie PCs to do his DOS
> against your machine.

Yeah, because none of the script kiddies have figured out how to do 
that. ;-)

Then again, if somebody decides to DDoS you, it doesn't matter if you 
have *no* ports exposed to the Internet... You still get no service.

Sometimes I think it would be nice if there was a widely-supported 
standard for configuring the firewall at the /other end/ of the last 
mile to drop certain packets. But anyway...

Post a reply to this message

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

The manpage for bash practically lists the BNF grammar for shell 
scripts, but fails to provide any useful introductory material for 
anyone just trying to get started. (E.g., how the **** to I execute the 
same command for every file in this folder?)

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

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

I thought the host key is how the server identifies itself to you, not 
how you identify yourself to the server?

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.

Post a reply to this message

Le 14/09/2011 10:42, Invisible a écrit :

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

Indeed, for ssh, PasswordAuthentication is never going to CHAP.
PasswordAuthentication of ssh need that the lower layer negociated
already an encryption and a mac/checksum.
(it is forbidden to use password authentication over a clear connection)

Myself, I prefer signature authentication, with ~/.ssh/authorized_keys .
My password/passphrase locally unlock the private key, and the public
key is in the remote host(s) user directory.


> 
> I thought the host key is how the server identifies itself to you, not
> how you identify yourself to the server?

Correct.

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

~/.ssh/authorized_keys !!
(name can be configured with AuthorizedKeysFile )

May be you have a different man page for sshd.
Mine talk about ~/.ssh/rc, ~/.ssh/environment, and more...
including ~/.ssh/known_hosts

In fact, the FILES section of the man page for sshd is long... very long.



-- 
Software is like dirt - it costs time and money to change it and move it
around.<br/><br/>


Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

>>> 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.)
>>
>
> Indeed, for ssh, PasswordAuthentication is never going to CHAP.
> PasswordAuthentication of ssh need that the lower layer negociated
> already an encryption and a mac/checksum.
> (it is forbidden to use password authentication over a clear connection)
>
> Myself, I prefer signature authentication, with ~/.ssh/authorized_keys .
> My password/passphrase locally unlock the private key, and the public
> key is in the remote host(s) user directory.

Yeah, that's basically my point. It took me *forever* to figure out how 
to make it so that public key is the /only/ enabled protocol, so that if 
you don't have a copy of my private key, there is NO WAY IN HELL that 
you can log in to my box.

Seems like a simple thing to want to do, but I tested it several times 
and it was still letting me log in with a weak-arse password instead of 
demanding a key.

> In fact, the FILES section of the man page for sshd is long... very long.

As is the configuration file, IIRC...

Post a reply to this message

Le 14/09/2011 10:33, Invisible a écrit :
> On 14/09/2011 04:22 AM, Jim Henderson wrote:
>> On Tue, 13 Sep 2011 19:48:55 +0100, Orchid XP v8 wrote:
>>
>>> Let me rephrase: There are no SSH servers that are free software.
>>
>> openssh is released under the GPL, and has been around for quite some
>> time now (certainly more than 5 years - I'd say more than a decade).
>>
>> And there are versions that run on Windows - using cygwin or not.
> 
> When I looked, I couldn't find any precompiled Windows binaries for
> OpenSSH anywhere.


I'm sorry, but you are asking for something against the commercial logic
of your operating system:

You paid for your OS, you also have to pay for your applications.
Only loonies provides free stuff of excellent quality on that platform.
Serious programmers for that platform are expected to extort a lot for
the application you might install (be it shareware or direct buyware or
troyan or racket-ware... ).

Please, assume your choice.






did you look at http://www.freesshd.com/?ctt=overview

Post a reply to this message

>> When I looked, I couldn't find any precompiled Windows binaries for
>> OpenSSH anywhere.
>
>
> I'm sorry, but you are asking for something against the commercial logic
> of your operating system:
>
> You paid for your OS, you also have to pay for your applications.
> Only loonies provides free stuff of excellent quality on that platform.
> Serious programmers for that platform are expected to extort a lot for
> the application you might install (be it shareware or direct buyware or
> troyan or racket-ware... ).
>
> Please, assume your choice.

No OS fanboys in here, no sir! :-S

Post a reply to this message

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.

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

Post a reply to this message

On 9/14/2011 1:32, Invisible wrote:
> On 13/09/2011 10:05 PM, Darren New wrote:
>> 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.
>
> Sure. But I mean, you can set up an application server that more than one
> person can access, without doing anything particularly special.

You can do exactly the same thing on Windows that you do on Unix.

Log into the windows box remotely. Start an X client and point it at your 
display. Disconnect without logging out. Someone else logs into the windows 
box remotely. They start an X client and points it at their display. They 
disconnect without logging out.  Guess what? Windows running X clients 
talking to two different X servers.

>> 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".
>
> OK, well maybe it's the cost of the client licenses I'm thinking of then...

That's with five client licenses. So about $110/user.

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

Post a reply to this message

On 9/14/2011 8:09, Le_Forgeron wrote:
> You paid for your OS, you also have to pay for your applications.
> Only loonies provides free stuff of excellent quality on that platform.

I think you just insulted every member of TAG. ;-)

Seriously, googling for "gnu win32" tends to get you ports of everything.

http://linuxmafia.com/ssh/win32.html

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

Post a reply to this message

On 9/14/2011 1:37, Invisible wrote:
> Really? I thought they just connect to a central game server. (Although...
> actually they mostly seem to use UDP, so "connect" is a little nebulous.)

Bingo.

>> Or iconify the remote screen, copy the file, expand the remote screen,
>> paste the file.
>
> Oh, that works?

Why wouldn't it?

>> Or just let RDP mount the disks over the link, so they
>> show up as networked drives on the remote machine.
>
> Ah - it [optionally] connects local and remote disks, the same way it
> connects printers, right?

Yep. And sound. And USB ports.

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

Post a reply to this message

On Wed, 14 Sep 2011 09:42:31 +0100, Invisible wrote:

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

I suspect that I spend just a *tiny* bit more time than you do reading 
man pages - and I wouldn't make an assertion that "it depends on the man 
page in question" if it weren't actually the case.

> The manpage for bash practically lists the BNF grammar for shell
> scripts, but fails to provide any useful introductory material for
> anyone just trying to get started. (E.g., how the **** to I execute the
> same command for every file in this folder?)
> 
>>       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.

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

> 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

Jim

Post a reply to this message

On Wed, 14 Sep 2011 16:57:09 +0200, Le_Forgeron wrote:

> Myself, I prefer signature authentication, with ~/.ssh/authorized_keys .
> My password/passphrase locally unlock the private key, and the public
> key is in the remote host(s) user directory.

As do I - I guess I wasn't as clear as I thought in explaining how the 
key is put on the remote machine - it does indeed go in the 
authorized_keys file.

Jim

Post a reply to this message

On Wed, 14 Sep 2011 09:33:49 +0100, Invisible wrote:

> On 14/09/2011 04:22 AM, Jim Henderson wrote:
>> On Tue, 13 Sep 2011 19:48:55 +0100, Orchid XP v8 wrote:
>>
>>> Let me rephrase: There are no SSH servers that are free software.
>>
>> openssh is released under the GPL, and has been around for quite some
>> time now (certainly more than 5 years - I'd say more than a decade).
>>
>> And there are versions that run on Windows - using cygwin or not.
> 
> 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).

Jim

Post a reply to this message

>>> Yep. You still need a computer for each user, tho.
>>
>> Sure. But I mean, you can set up an application server that more than one
>> person can access, without doing anything particularly special.
>
> You can do exactly the same thing on Windows that you do on Unix.
>
> Log into the windows box remotely. Start an X client and point it at
> your display. Disconnect without logging out. Someone else logs into the
> windows box remotely. They start an X client and points it at their
> display. They disconnect without logging out. Guess what? Windows
> running X clients talking to two different X servers.

Does anyone, anywhere on Earth, actually run X on Windows?

I mean, I gather that you *can*. But does anybody actually *do* this?

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

Post a reply to this message

On 14/09/2011 5:58 PM, Darren New wrote:
> On 9/14/2011 8:09, Le_Forgeron wrote:
>> You paid for your OS, you also have to pay for your applications.
>> Only loonies provides free stuff of excellent quality on that platform.
>
> I think you just insulted every member of TAG. ;-)

Or complemented them.

-- 
Regards
     Stephen

Post a reply to this message

On 14-9-2011 22:52, Orchid XP v8 wrote:
>>>> Yep. You still need a computer for each user, tho.
>>>
>>> Sure. But I mean, you can set up an application server that more than
>>> one
>>> person can access, without doing anything particularly special.
>>
>> You can do exactly the same thing on Windows that you do on Unix.
>>
>> Log into the windows box remotely. Start an X client and point it at
>> your display. Disconnect without logging out. Someone else logs into the
>> windows box remotely. They start an X client and points it at their
>> display. They disconnect without logging out. Guess what? Windows
>> running X clients talking to two different X servers.
>
> Does anyone, anywhere on Earth, actually run X on Windows?
>
> I mean, I gather that you *can*. But does anybody actually *do* this?
>

I have done that, why?

Post a reply to this message

On Wed, 14 Sep 2011 21:52:10 +0100, Orchid XP v8 wrote:

>>>> Yep. You still need a computer for each user, tho.
>>>
>>> Sure. But I mean, you can set up an application server that more than
>>> one person can access, without doing anything particularly special.
>>
>> You can do exactly the same thing on Windows that you do on Unix.
>>
>> Log into the windows box remotely. Start an X client and point it at
>> your display. Disconnect without logging out. Someone else logs into
>> the windows box remotely. They start an X client and points it at their
>> display. They disconnect without logging out. Guess what? Windows
>> running X clients talking to two different X servers.
> 
> Does anyone, anywhere on Earth, actually run X on Windows?
> 
> I mean, I gather that you *can*. But does anybody actually *do* this?

Yes.

Jim

Post a reply to this message

Am 14.09.2011 22:52, schrieb Orchid XP v8:

> Does anyone, anywhere on Earth, actually run X on Windows?
>
> I mean, I gather that you *can*. But does anybody actually *do* this?

An X /server/ (that is, the X terminal software)? Absolutely. Guess how 
I "remotely" control my Linux machine (which I use primarily for 
scripted test-runs of POV-Ray) from my Windows machine (which I use for 
everyday stuff, including POV-Ray development with MS Visual Studio).

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.


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.

Post a reply to this message

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

On Thu, 15 Sep 2011 18:15:43 +0100, Orchid XP v8 wrote:

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

It is.

Jim

Post a reply to this message

On Thu, 15 Sep 2011 09:12:03 +0100, Invisible wrote:

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

Man pages are not intended to be tutorials.  They're manual pages.

Ever read the Windows manual?  It's not a tutorial on how to use Windows, 
it's a description of what Windows is and its features/functionality.

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

And when you're looking for configuration options, a reference is 
generally what people turn to.

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

Well, no, it's not *another* problem - you just need to use the info 
command instead.

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

Not to the best of my knowledge.  On my systems, if I try to use password 
authentication, the system tells me that only public key authentication 
is enabled.

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

No, it's trivial.  My server is in fact a perfect example of that.

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

A sample size of 3 isn't exactly data supporting "commonly used".  I've 
used sftp systems that don't use them at all, and just use ssh as a way 
of tunneling ftp data securely.

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

Beats me.

Jim

Post a reply to this message

On Thu, 15 Sep 2011 14:22:31 +0100, Invisible wrote:

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

VNC is also trivially compromised unless you tunnel it over ssh or wrap 
it in ssl.

For Windows, IIRC, you just need to install MingW.  IIRC, that covers X 
protocol on Windows for accessing remote X servers (ie, it's a client, 
not a server).

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

That's certainly true.

Jim

Post a reply to this message

On Thu, 15 Sep 2011 09:14:33 +0100, Invisible wrote:

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

Absolutely not.  Go read up on what Cygwin is and how it works.

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

That's how Cygwin is set up.  It's not the only solution, just an example.

Jim

Post a reply to this message

Le 2011-09-14 04:27, Invisible a écrit :
>>>> You're off by two orders of magnitude. Most Cisco firewalls are in
>>>> teh 5
>>>> digit price tag.
>>>
>>> True. But not this particular one.
>>>
>>>
http://www.ebuyer.com/135532-cisco-asa-5505-firewall-edition-bundle-asa5505-50-bun-k9
>>>
>>
>> Ok. you got me. I usually don't deal with small-office/home-office gear.
>
> I was surprised myself. Our network switches cost about 3x what every
> other manufacturer wanted.
>
> (I soon discovered, however, that these "switches" are actually just
> 24-port *routers*...)
>
>>>> You don't need to be a Cisco Certified Internetwork Expert to figure it
>>>> out. The Cisco manuals are usually pretty easy to follow, and freely
>>>> available on their web site.
>>>
>>> Really? That might be worth reading...
>>>
>>
>> This is a good place to start:
>
> OK.
>
>> Note: Even though Cisco firewall appliances are now called ASAs, their
>> documentation still cals them PIXes all over the place.
>
> Yeah, we've still got a PIX 506e in the corner. Though damned if I know
> why; that thing was starting to become quite unreliable...
>
>>> From what I've seen, you telnet into the router, enter a password, and
>>> then enter lines of gibberish such as "enh eth gw all". You would
>>> *definitely* need a manual to figure out WTH that actually means, or
>>> what the name of the command you want is.
>>
>> Two things:
>>
>> First thing, typing ? at any point will list all the available commands
>> at that point.
>
> So... it's some kind of hierarchical menu system? (I had assumed that
> all commands are available all the time.)

Yes and no.

there are multiple modes.  Normal display mode, "enable" mode, where you 
can make some changes such as clear counters, logs or set certain 
parameters, and "Configure" mode where you make ... configuration changes.

The available commands vary for each mode, however what I meant whas that

? by itself will list all the commands you can type, while

show ?

will list all the stuff the show command can display, and

show interface ?

will list all the types of interfaces that can be displayed

etc...

>
>> Second thing, you don't have to enter gibberish. the commands are plain
>> english words. They can be abbreviated for speed, but
>>
>> sh ip int fa0/0 bri
>>
>> Is exactly the same as typing
>>
>> show ip interface fastethernet0/0 brief
>
> I see.
>
> I'm guessing that unless you do this kind of thing all day, you'll
> quickly forget what the name for each command is, and so you'll need the
> manual open constantly. (I really hope the manuals contain more than
> just a reference list of every command name and what it does...)
>

Configuration guides, command references, hardware installation 
checklists, etc... they're all in there.

>>> I'm still guessing that, between the configuration for routing to
>>> multiple LANs, multiple VPN endpoints, and remote access, adding a line
>>> that forwards SSH to a port on a desktop PC who's IP address is
>>> configured via DHCP is probably going to take some doing. (!)
>>
>> Routing for the multiple lans actually comes straigh out of the box. You
>> confiugre an ip address on all the interfaces and it will know that any
>> packets it receives whose destination is on another lan interface, it
>> will forward it (let's disregard security rules, for the moment!).
>
> Even though there's only one connection from the firewall to the
> (multiple) switches?

Then, there are mulitple "VLAN" interfaces created, so the above still 
stands.

>
>> Remote lans are handled the same way they would be on a Windows or Unix
>> machine. By either configuring a routing protocol, or by adding static
>> routes.
>>

>> On Windows, you'd type:
>>
>> route add 192.168.200.0 mask 255.255.255.0 192.168.1.1
>
> 1. I didn't know you could do that.
> 2. What does it do?
>

It tells your PC that there's a network called 192.168.200.0 somewhere 
voer there, and that to get ot it, you must forward the packets to 
192.168.1.1 and he'll take care of them.

On a pc with no VPN and only one NIC, that's pointless, but if you have 
more than one NIC on a server, or have "split-tunnelling" enabled on 
your VPN, you need to have those set up so that the machine knows on 
which interface it needs to send the packets.

>> VPN endpoints are not more complicated than on any other platform, but
>> that's a bit like saying that changing the transmission of a Formula One
>> is not more complicated than changing it on a Toyota... It may not Be
>> for a complete noob.
>
> Presumably you have to specify protocol types and encryption keys and so
> forth...
>

Yup.

>> Allowing inbound ssh connections will need that PC to have a static NAT
>> address, and therefore a static local IP address. Your Netgear or
>> Linksys home router can work around this because it also acts as the
>> DHCP server, so it knows to which MAC adress to send the traffic, but in
>> an entreprise where the firewall is a separate piece of hardware, there
>> is simply no way to do this.
>
> Quite. The only way this could work is if you wanted to /temporarily/
> forward SSH (probably on a different port number) to the IP address that
> my desktop PC /currently/ has.
>
>>> And we still have the minor issue that I don't have the password. :-P
>>
>> If you have physical access to the box, you can do a password recovery
>
> I am *so* not trying this! :-D
>
> Incidentally, I gather that there's two ways to control the ASA. One
> involves telnet. The other involves a serial cable...

Serial cable is required to give the machine its initial barebones 
config, after that, it's telnet or preferably ssh.  Since anyone could 
sniff the telnet password.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>> 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.
>
> VNC is also trivially compromised unless you tunnel it over ssh or wrap
> it in ssl.

If the two machines are on the same LAN, this probably isn't a problem. 
(And presumably the same applies to X as well anyway...)

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

Post a reply to this message

>>> 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.
>
> Man pages are not intended to be tutorials.  They're manual pages.

...which is the point I'm trying to make, yes.

>> Then again, sometimes the manpage just says "use info". And then you had
>> /another/ problem...
>
> Well, no, it's not *another* problem - you just need to use the info
> command instead.

Have /you/ tried navigating the thing?

Since I'm guessing the answer is probably "yes", then I don't need to 
explain to you how hard it is...

>>> 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.
>
> Not to the best of my knowledge.

I'm fairly sure I tested it, and discovered that I needed to turn off 
multiple things to stop it accepting my password as a valid login. But 
since that was then and this is now, I guess I might be incorrect.

>>>> 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.
>
> A sample size of 3 isn't exactly data supporting "commonly used".

It's infinity times larger than a sample size of zero. ;-)

Then again, one of these systems is set up to use PK authentication, and 
the server administrators emailled /us/ with the private key to use to 
get access. *facepalm*

Imagine it: Going to all the trouble of setting up a secure system, and 
not even knowing how to secure it properly...

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

Post a reply to this message

Le 15/09/2011 20:46, Orchid XP v8 nous fit lire :

>>>> 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.
>>
>> Not to the best of my knowledge.
> 
> I'm fairly sure I tested it, and discovered that I needed to turn off
> multiple things to stop it accepting my password as a valid login. But
> since that was then and this is now, I guess I might be incorrect.
> 

Did you at least refresh (aka reload) sshd when updating the configuration ?
Updating the configuration is not enough, the daemon must be flushed to
reload it.

SSH password authentication is just delegating the password to the OS
system... (bad! IMNSHO)

>>>>> 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.
>>
>> A sample size of 3 isn't exactly data supporting "commonly used".
> 
> It's infinity times larger than a sample size of zero. ;-)

Host key are kind of mandatory for server. Unless you want to use ssh
without encryption at all.

> 
> Then again, one of these systems is set up to use PK authentication, and
> the server administrators emailled /us/ with the private key to use to
> get access. *facepalm*
> 
> Imagine it: Going to all the trouble of setting up a secure system, and
> not even knowing how to secure it properly...
> 

That's the issue with wrong administrators: they assume people do not
have their own public key, and generate a pair for them... they need a
clue (and some users too!).

From my bad memory, there is at least 5 kinds of attacks that must be
covered. If you cannot understand them all, you're out of the trusted.

Post a reply to this message

>> I'm fairly sure I tested it, and discovered that I needed to turn off
>> multiple things to stop it accepting my password as a valid login. But
>> since that was then and this is now, I guess I might be incorrect.
>>
>
> Did you at least refresh (aka reload) sshd when updating the configuration ?

Is rebooting the machine sufficient to do that?

If so, yes...

>> Imagine it: Going to all the trouble of setting up a secure system, and
>> not even knowing how to secure it properly...
>
> That's the issue with wrong administrators: they assume people do not
> have their own public key, and generate a pair for them... they need a
> clue (and some users too!).

The most mystifying part is, the first time we set it up, they did it 
right. Only the second time around did they insist that we use their key...

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

Post a reply to this message

>>> First thing, typing ? at any point will list all the available commands
>>> at that point.
>>
>> So... it's some kind of hierarchical menu system? (I had assumed that
>> all commands are available all the time.)
>
> Yes and no.
>
> there are multiple modes. Normal display mode, "enable" mode, where you
> can make some changes such as clear counters, logs or set certain
> parameters, and "Configure" mode where you make ... configuration changes.
>
> The available commands vary for each mode, however what I meant whas that
>
> ? by itself will list all the commands you can type, while
>
> show ?
>
> will list all the stuff the show command can display, and
>
> show interface ?
>
> will list all the types of interfaces that can be displayed
>
> etc...

Oh, right, I see. Well that seems logical enough...

>> I'm guessing that unless you do this kind of thing all day, you'll
>> quickly forget what the name for each command is, and so you'll need the
>> manual open constantly. (I really hope the manuals contain more than
>> just a reference list of every command name and what it does...)
>
> Configuration guides, command references, hardware installation
> checklists, etc... they're all in there.

That's very reassuring.

>>> Routing for the multiple lans actually comes straigh out of the box. You
>>> confiugre an ip address on all the interfaces and it will know that any
>>> packets it receives whose destination is on another lan interface, it
>>> will forward it (let's disregard security rules, for the moment!).
>>
>> Even though there's only one connection from the firewall to the
>> (multiple) switches?
>
> Then, there are mulitple "VLAN" interfaces created, so the above still
> stands.

I see. (I think...)

>>> On Windows, you'd type:
>>>
>>> route add 192.168.200.0 mask 255.255.255.0 192.168.1.1
>>
>> 1. I didn't know you could do that.
>> 2. What does it do?
>>
>
> It tells your PC that there's a network called 192.168.200.0 somewhere
> voer there, and that to get ot it, you must forward the packets to
> 192.168.1.1 and he'll take care of them.

Interesting. I didn't know Windows was actually capable of doing that. 
Usually when I need a router in a hurry, I load up Linux and read some 
manpages...

Hmm, I wonder... If my VPN client doesn't route all the subnets I want, 
can I get it to dump the packets onto the wrong LAN segment, and then 
trust the router at that end to take it to the correct place?

>> Incidentally, I gather that there's two ways to control the ASA. One
>> involves telnet. The other involves a serial cable...
>
> Serial cable is required to give the machine its initial barebones
> config, after that, it's telnet or preferably ssh. Since anyone could
> sniff the telnet password.

It's neat that you can configure it via IP. Then again, if you configure 
the IP stuff wrong, you need to connect somehow so you can reconfigure 
it. :-}

I wonder what authentication options there are for SSH...

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

Post a reply to this message