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