| 1 |
Hi, |
| 2 |
|
| 3 |
On Mon, 17 Sep 2007 12:56:16 -0300 "Arturo 'Buanzo' Busleiman" |
| 4 |
<buanzo@××××××××××.ar> wrote: |
| 5 |
|
| 6 |
> > So I would definately prefer to always have a guaranteed working |
| 7 |
> > sshd running (I find OpenVPN/telnet a bit strange and an unnecessary |
| 8 |
> > potential security hole). |
| 9 |
> |
| 10 |
> If running permanently, then I agree, but I do not see the potential |
| 11 |
> security hole if using a correctly designed/configured tunnel. |
| 12 |
|
| 13 |
I just prefer manual "opening" of access means above manual "securing" |
| 14 |
them. It's just about what happens if you fail -- when the task was |
| 15 |
securing, you might have a security leak, but if it was openiung |
| 16 |
access, it is still secured. It's relatively moot, since opening access |
| 17 |
is also often error prone in the sense of "opening to much". I think |
| 18 |
it's personal taste :-) |
| 19 |
|
| 20 |
> > session. So you have to weight the risks. The real problem, however, |
| 21 |
> > can only be overcome by another way to login. Firing up another |
| 22 |
> > instance of sshd (on a different port) is just a matter of one |
| 23 |
> > simple command, so I definately prefer that. |
| 24 |
> |
| 25 |
> As long as there is no issue with the sshd binary, of course :) |
| 26 |
|
| 27 |
Yeah, but in that case you'd know it at that point, and it caused no |
| 28 |
other harm than preventing you to setting up that fallback sshd. You |
| 29 |
can then still fix it (or set up OpenVPN/telnet ;-)) using the old sshd |
| 30 |
that's still listening. Just remember not to do a "killall sshd". |
| 31 |
|
| 32 |
-hwh |
| 33 |
-- |
| 34 |
gentoo-user@g.o mailing list |
Archives