On Mon, Apr 04, 2005 at 09:46:26AM -0700, Chris Adams wrote:
Policy was the wrong word - the basic idea is just that either way the
users have a password but a private key isn't directly replayable since
the attacker doesn't actually receive the key information or password.
Depending on the
Michael Stone wrote:
Depending on the attack. That's the point I'm making--rsa keys protect
against certain attacks but do absolutely nothing about other attacks
and shouldn't be seen as a magic bullet.
They were also never portrayed as such - merely an additional layer of
protection which has
On Mon, Apr 04, 2005 at 10:50:48AM -0700, Chris Adams wrote:
They were also never portrayed as such - merely an additional layer of
protection
It's not an additional layer if you replace passwords with keys.
It allows you to step in the middle of the process - it's not simply a
question of
On Fri, Apr 01, 2005 at 11:43:07AM -0800, Chris Adams wrote:
There's no difference between the two as regards policy - it's a
one-line command to change either a password or key,
There's no difference? All of the tools to automatically expire
passwords at a given interval, mandate minimum
It worked. Being a person who reads these mailing-lists in order to gain
experience, thank you.
Regards, Anders Breindahl.
On Saturday 02 April 2005 01:18, Henrique de Moraes Holschuh wrote:
Sure. But I hope my post will make people at least read ldd(1)... That
was the whole point. A new
On Mar 31, 2005, at 11:40 PM, Robert Lemmen wrote:
On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote:
`less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to
compromise
my machine since March 27th...
of course the only thing that really helps is good passwords,
Or no passwords -
On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote:
Will not having the usual all: local break something?
Yes:
$ ldd `which portmap`
libwrap.so.0 = /lib/libwrap.so.0 (0x4003)
libnsl.so.1 = /lib/libnsl.so.1 (0x40039000)
libc.so.6 = /lib/libc.so.6 (0x4004e000)
On Fri, Apr 01, 2005 at 01:23:09AM -0800, Chris Adams wrote:
Or no passwords - if requiring public key authentication is feasible
for a system you can disable password authentication entirely:
I generally consider that to be a horrible idea. Instead of centrally
managed password policies you now
Michael Stone wrote:
On Fri, Apr 01, 2005 at 01:23:09AM -0800, Chris Adams wrote:
Or no passwords - if requiring public key authentication is feasible
for a system you can disable password authentication entirely:
I generally consider that to be a horrible idea. Instead of centrally
On Fri, 01 Apr 2005, Michael Stone wrote:
On Fri, Apr 01, 2005 at 01:23:09AM -0800, Chris Adams wrote:
Or no passwords - if requiring public key authentication is feasible
for a system you can disable password authentication entirely:
I generally consider that to be a horrible idea. Instead
On Fri, Apr 01, 2005 at 04:59:40PM +0200, Philipp Schulte wrote:
Sure, maybe a user does not handle the key carefully but do you think
they are more careful with their password and don't write it down or
something like this?
I'd rather have them write it down. Paper isn't subject to remote
On Fri, Apr 01, 2005 at 12:11:29PM -0300, Henrique de Moraes Holschuh wrote:
Nowadays user passwords often end up being stolen, not broken (trojans,
etc). Keys offer no degraded security in that scenario.
Wrong. It's much harder to force people to change keys than passwords.
It's not impossible,
also sprach Chris Adams [EMAIL PROTECTED] [2005.04.01.2143 +0200]:
you somewhat from casual attacks against weak passwords: if
I obtain a copy of a user's password a public-key-only policy
means that I still need some sort of privileged access to their
home directory to exploit it - far from
On Thursday 31 March 2005 11:14 pm, Alvin Oga wrote:
but make sure ssh is compiled with tcpwarppers, otherwise that
lines are worthless
How are they compiled by default on Sid?
I think that ssh must be compiled that way by default as I had to add $WorkIP2
to
allow access from that machine...
Hello *,
On Fri, Apr 01, 2005 at 02:05:29PM -0600, Brad Sims wrote:
On Thursday 31 March 2005 11:14 pm, Alvin Oga wrote:
but make sure ssh is compiled with tcpwarppers, otherwise that
lines are worthless
How are they compiled by default on Sid?
I think that ssh must be compiled that
On Fri, 01 Apr 2005, Florian Ernst wrote:
Taken from /usr/share/doc/ssh/README.Debian.gz, more confirmation
could be taken from downloading and checking the Debian sources.
ldd is your friend. Use it...
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in
On Fri, Apr 01, 2005 at 06:03:25PM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 01 Apr 2005, Florian Ernst wrote:
Taken from /usr/share/doc/ssh/README.Debian.gz, more confirmation
could be taken from downloading and checking the Debian sources.
ldd is your friend. Use it...
I
On Sat, 02 Apr 2005, Florian Ernst wrote:
I personally do, but for some people information might be better suited
if it is explicitely spelled out... Just the ldd output alone would
Sure. But I hope my post will make people at least read ldd(1)... That was
the whole point. A new trick on
`less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise
my machine since March 27th...
/etc/hosts.deny reads: ALL: ALL
/etc/hosts.allow reads:
sshd: $WORK_IP1
sshd: $WORK_IP2
Will not having the usual all: local break something?
--
But when a long Train of Abuses and
On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote:
`less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise
my machine since March 27th...
A similar command on the log server on a class B network (/16) shows
1482 such attempts in the past 19 hours or so. It's just a
On Thu, 31 Mar 2005, Brad Sims wrote:
`less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise
my machine since March 27th...
/etc/hosts.deny reads: ALL: ALL
good
/etc/hosts.allow reads:
sshd: $WORK_IP1
sshd: $WORK_IP2
good
but make sure ssh is compiled with
On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote:
`less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise
my machine since March 27th...
of course the only thing that really helps is good passwords, but i
found this to be of great help too:
22 matches
Mail list logo
