 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 15 Sep 2011 19:17:36 +0100, Orchid XP v8 wrote:
>>> 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...)
Yes, that's true, if you trust the LAN.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 15 Sep 2011 19:46:42 +0100, Orchid XP v8 wrote:
>> Man pages are not intended to be tutorials. They're manual pages.
>
> ...which is the point I'm trying to make, yes.
So then what's the problem? You're complaining that they're not
tutorials, but they're not intended to be tutorials.
>>> 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...
Yes, and I usually end up googling instead. I'm sure I could figure it
out, but I don't need it that often.
>>> 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.
It might be easier now, yes. Honestly, I've never even looked for a CHAP-
based authentication mechanism for ssh.
>>>>> 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. ;-)
Sure, but not mathematically significant.
> 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...
I don't have to - I see it fairly regularly.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 15 Sep 2011 19:10:09 -0700, Darren New wrote:
> On 9/15/2011 18:19, Francois Labreque wrote:
>> Heathen! Linux machines do not need to be rebooted. Ever.
>
> I'm pretty sure you're wrong on that one.
Yeah, kernel updates require a reboot. Other than that, you usually
don't have to (unless you're killing zombie processes), but sometimes
"it's easier".
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/15/2011 19:36, Jim Henderson wrote:
> Yeah, kernel updates require a reboot. Other than that, you usually
> don't have to
Again, it depends on what you're doing and where the Linux is living. I'll
grant that *desktop* linux systems rarely *need* rebooting. And I'd argue
that if you have a server whose *only* job is being a web server, then
restarting the web server after an upgrade is essentially the same as a
reboot, except faster.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Did you at least refresh (aka reload) sshd when updating the
>>> configuration ?
>>
>> Is rebooting the machine sufficient to do that?
>>
>> If so, yes...
>>
>
> Heathen! Linux machines do not need to be rebooted. Ever.
It's not so much that I purposely rebooted it; more that it's a laptop
that shuts down whenever the power is unplugged. So every time I moved
it to a different location in the building, it was effectively rebooted.
> To quote Yoda: Unlearn everything you must.
If you're going to quote Yoda, do it right:
"Then you must /unlearn/ all that you have /learned/."
Not every sentence he utters is in object-subject-verb order. (At least,
not in the original trilogy.)
If you really want to split hairs,
http://itre.cis.upenn.edu/~myl/languagelog/archives/002173.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/09/2011 03:46 AM, Darren New wrote:
> Again, it depends on what you're doing and where the Linux is living.
> I'll grant that *desktop* linux systems rarely *need* rebooting. And I'd
> argue that if you have a server whose *only* job is being a web server,
> then restarting the web server after an upgrade is essentially the same
> as a reboot, except faster.
Actually Windows is getting better at not needing to be rebooted either.
You can quite often install or uninstall software, and it doesn't bother
asking for a reboot. It just /works/. (Indeed, lots of older software
asks for a reboot, but actually works fine without one.)
And - fortunately - it's becoming less common to need to reboot due to
resource leaks too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/09/2011 03:15 AM, Darren New wrote:
> On 9/15/2011 2:44, Le_Forgeron wrote:
>> try playing xonix via VNC... it's far easier with just a X server on the
>> windows system.
>
> VNC wasn't really designed for efficiency.
The fail!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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...
>
> A DDoS needs to be extremely big for an ISP to notice one of its
> customers is under attack. And you need a special business relationship
> to be able to call them up and ask that they block a certain type of
> traffic at the head end.
Quite. I did actually hear about a guy having to spend ages on the phone
to their ISP to ask for firewall configuration changes.
Now imagine if there were a standard, widely-implemented system for
letting the customer make those configuration changes themselves...
Let's face it, the ISP's routers are almost certainly remote-manageable
anyway. If the unwanted packets can be blocked at the entrance to the
ISP's network, they can save themselves the bother of having to route a
bunch of traffic. (Although the amount of data you can fire at one
customer is probably peanuts compared to the ISP network capacity.)
Ah well, dream on...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/09/2011 03:08 AM, Darren New wrote:
> On 9/12/2011 1:41, Invisible wrote:
>> After reading several dozen forum posts, it seems nobody has a really
>> good
>> solution for doing this.
>
> Actually, when you think about it, the two people in this situation are
> not unlikely using two computers both of which are using the same IP
> address, like 192.168.0.2. Hard to see how to make a TCP/IP transfer
> easy if both target machines have the same IP address, regardless of
> software installed or operating system in use.
With NAT, it can work perfectly well. At long as each endpoint knows the
other only by its publicly routable IP address, anyway.
There are probably web servers that run on RFC-1918 IP addresses. And
plenty of home users who do. And yet, they can still talk to each other...
The /problem/ happens when you want to route between two entire
/networks/ with the same network number.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Man pages are not intended to be tutorials. They're manual pages.
>>
>> ...which is the point I'm trying to make, yes.
>
> So then what's the problem? You're complaining that they're not
> tutorials, but they're not intended to be tutorials.
No, I'm complaining that tutorials don't exist. Only reference manuals.
>> Since I'm guessing the answer is probably "yes", then I don't need to
>> explain to you how hard it is...
>
> Yes, and I usually end up googling instead. I'm sure I could figure it
> out, but I don't need it that often.
Let's just hope you're not trying to look up how to configure Internet
access...
>>>> 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.
>
> It might be easier now, yes. Honestly, I've never even looked for a CHAP-
> based authentication mechanism for ssh.
No, I mean, I might be remembering this wrong.
>>> A sample size of 3 isn't exactly data supporting "commonly used".
>>
>> It's infinity times larger than a sample size of zero. ;-)
>
> Sure, but not mathematically significant.
Not /statistically/ significant, if you want to be picky.
>> Imagine it: Going to all the trouble of setting up a secure system, and
>> not even knowing how to secure it properly...
>
> I don't have to - I see it fairly regularly.
This is the real WTF...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
