Re: [SAGE] The danger of SSH keys..

["Dana Quinn" <dquinn@gmail.com>]

nothing, i imagine.

also doesn't stop people from compiling their ssh binaries.  or many
other ways of getting around.

this approach also assumes a lot of things - standardized desktop
builds, packaging (so that people aren't using their own [or redhat's]
build of ssh-keygen), other things.

but it works fairly well in this environment, because when ssh-keygen
is run, and the person hits return for a blank password, they get a
message about how it's against corporate policy, so on.  so someone
choosing to work around that *probably* has already received a
reminder that they aren't supposed to do it that way.

in practice, i've seen it stops 99% of the attempts to do it, and they
go try to solve their problem another way.  (it's usually developers
trying to push things automatically, the company has other, approved
ways to do that sort of thing)

whether the 1% of attempts that continue around this block are more
dangerous or less dangerous to overall company security is probably
something people argue about.  I've not seen what happens when a 1%-er
is uncovered, but that could be handled by a standard company policy.

so this isn't exactly what Dustin has asked for, but it's been a
useful approach so far.

dana

On 1/22/07, Meenoo Shivdasani <meenoo@gmail.com> wrote:
> On 1/22/07, Dana Quinn <dquinn@gmail.com> wrote:
> > Make it so people only have access to a keygen binary that requires a
> > password.  I'm aware of a large company that does this fairly
> > successfully.  Could get unwieldy as you need to cover all the
>
> What stops someone from taking a key generated with that binary,
> importing into another key management tool, removing the keyphrase,
> and saving it back out?
>
> M
>


-- 
Dana Quinn
danaq@pobox.com