>>>>> "mark" == mark writes:

mark> Does anybody know of a way to enforce a policy where ssh key
mark> pass-phrases should not be empty? It is one of the "weaknesses"
mark> of ssh as I see it that an administrator can't actually impose
mark> this constraint on access to his own server.

He can't, because it makes no sense. The server never sees the user's
private key. It has no control over where or how the key is stored. It's
like suggesting there's a lock out there that can "require" that you not
keep the key in your pocket.

--
Richard Silverman
res@qoxp.net

Richard E. Silverman wrote:
>>>>>> "mark" == mark writes:
>
> mark> Does anybody know of a way to enforce a policy where ssh key
> mark> pass-phrases should not be empty? It is one of the
> "weaknesses" mark> of ssh as I see it that an administrator can't
> actually impose mark> this constraint on access to his own server.
>
> He can't, because it makes no sense. The server never sees the user's
> private key. It has no control over where or how the key is stored.
> It's like suggesting there's a lock out there that can "require" that
> you not keep the key in your pocket.

Richard? You could make the lock *REALLY, REALLY, REALLY* big so that the
key has to be at least as big. But that doesn't sound like a good idea,
either.

On Thu, 27 Apr 2006 00:52:27 -0400, Richard E. Silverman wrote:
>>>>>> "mark" == mark writes:
> mark> Does anybody know of a way to enforce a policy where ssh key
> mark> pass-phrases should not be empty? It is one of the "weaknesses"
> mark> of ssh as I see it that an administrator can't actually impose
> mark> this constraint on access to his own server.
>
> He can't, because it makes no sense. The server never sees the user's
> private key. It has no control over where or how the key is stored. It's
> like suggesting there's a lock out there that can "require" that you not
> keep the key in your pocket.

Richard, of course I realise that it doesn't "make sense" wrt to the
fundamental design of ssh. The pass-phrase is only pertinent to
unlocking the user's private key and that is that. But surely it does
make "make sense" that an administrator may have a personal opinion that
users should not be allowed to use empty pass-phrases on their keys?
What I am saying is that it has always seemed to me a bit of a
deficiency of ssh that an administrator can not actually enforce this
policy on users to whom he is granting access to his server?

I guess it would be possible to write a script for root to traverse over
unix users client side home areas attempting to do some kind of
ssh-keygen operation on their keys and confirming that a pass-phrase is
prompted for? This doesn't address remote putty users etc, though.

>>>>> "NKG" == Nico Kadel-Garcia writes:

NKG> Richard E. Silverman wrote:
>>>>>>> "mark" == mark writes:
>>
mark> Does anybody know of a way to enforce a policy where ssh key
mark> pass-phrases should not be empty? It is one of the
>> "weaknesses" mark> of ssh as I see it that an administrator can't
>> actually impose mark> this constraint on access to his own server.
>>
>> He can't, because it makes no sense. The server never sees the
>> user's private key. It has no control over where or how the key is
>> stored. It's like suggesting there's a lock out there that can
>> "require" that you not keep the key in your pocket.

NKG> Richard? You could make the lock *REALLY, REALLY, REALLY* big so
NKG> that the key has to be at least as big. But that doesn't sound
NKG> like a good idea, either.

But this assumes the key size scales at least linearly with the size of
the lock...

--
Richard Silverman
res@qoxp.net

>>>>> "mark" == mark writes:

mark> On Thu, 27 Apr 2006 00:52:27 -0400, Richard E. Silverman wrote:
>>>>>>> "mark" == mark writes:
mark> Does anybody know of a way to enforce a policy where ssh key
mark> pass-phrases should not be empty? It is one of the "weaknesses"
mark> of ssh as I see it that an administrator can't actually impose
mark> this constraint on access to his own server.
>> He can't, because it makes no sense. The server never sees the
>> user's private key. It has no control over where or how the key is
>> stored. It's like suggesting there's a lock out there that can
>> "require" that you not keep the key in your pocket.

mark> Richard, of course I realise that it doesn't "make sense" wrt to
mark> the fundamental design of ssh. The pass-phrase is only pertinent
mark> to unlocking the user's private key and that is that. But surely
mark> it does make "make sense" that an administrator may have a
mark> personal opinion that users should not be allowed to use empty
mark> pass-phrases on their keys? What I am saying is that it has
mark> always seemed to me a bit of a deficiency of ssh that an
mark> administrator can not actually enforce this policy on users to
mark> whom he is granting access to his server?

Of course he should have an opinion, and communicate that to his users --
but that's a matter of policy. Calling it a deficiency of SSH implies (at
least to me) that there's some technical means by which an SSH server
*could* enforce this policy, and the protocol or its implementations
simply aren't using it. I know of no such means, and would be interested
to hear if you have an idea.

--
Richard Silverman
res@qoxp.net

mark wrote:

> I guess it would be possible to write a script for root to traverse
> over unix users client side home areas attempting to do some kind of
> ssh-keygen operation on their keys and confirming that a pass-phrase
> is prompted for?

I would not allow any SSH server to execute arbitrary code with the
permissions of my client side user account. (And this could not prevent
"malicious" users from deliberately using a key with a blank passphrase
either. The client could always manipulate the server's control process
and its environment.)

Paul

Paul Hink wrote:
> mark wrote:
>
>> I guess it would be possible to write a script for root to traverse
>> over unix users client side home areas attempting to do some kind of
>> ssh-keygen operation on their keys and confirming that a pass-phrase
>> is prompted for?
>
> I would not allow any SSH server to execute arbitrary code with the
> permissions of my client side user account. (And this could not
> prevent "malicious" users from deliberately using a key with a blank
> passphrase either. The client could always manipulate the server's
> control process and its environment.)

I've done that as an administrator in NFS based environments, and given
users gentle warnings about NFS published home directories with no password
SSH keys in them. It's a serious no-no in such an environment, since anyone
can pretend to be the user with a simple NFS client and access all their
files.

Richard E. Silverman wrote:

>> Richard? You could make the lock *REALLY, REALLY, REALLY* big so
>> that the key has to be at least as big. But that doesn't sound
>> like a good idea, either.
>
> But this assumes the key size scales at least linearly with the size
> of the lock...

Well, yeah. SSH servers could force a minimum key-length, making them 2 Gig
or so minimum. Of course, this becomes completely workable really, really
fast....

Nico Kadel-Garcia wrote:

> I've done that as an administrator in NFS based environments, and
> given users gentle warnings about NFS published home directories with
> no password SSH keys in them. It's a serious no-no in such an
> environment, since anyone can pretend to be the user with a simple
> NFS client and access all their files.

If "anyone can pretend to be the user with a simple NFS client and
access all their files" there are different and more serious problems
than SSH keys with blank passwords.

Paul

Paul Hink wrote:
> Nico Kadel-Garcia wrote:
>
>> I've done that as an administrator in NFS based environments, and
>> given users gentle warnings about NFS published home directories with
>> no password SSH keys in them. It's a serious no-no in such an
>> environment, since anyone can pretend to be the user with a simple
>> NFS client and access all their files.
>
> If "anyone can pretend to be the user with a simple NFS client and
> access all their files" there are different and more serious problems
> than SSH keys with blank passwords.

Welcome to NFS, brother. There's a compelling reason it's called "No
Freaking Security".

>>>>> "NKG" == Nico Kadel-Garcia writes:

NKG> Paul Hink wrote:
>> Nico Kadel-Garcia wrote:
>>> I've done that as an administrator in NFS based environments, and
>>> given users gentle warnings about NFS published home directories
>>> with no password SSH keys in them. It's a serious no-no in such an
>>> environment, since anyone can pretend to be the user with a simple
>>> NFS client and access all their files.
>> If "anyone can pretend to be the user with a simple NFS client and
>> access all their files" there are different and more serious
>> problems than SSH keys with blank passwords.

NKG> Welcome to NFS, brother. There's a compelling reason it's called
NKG> "No Freaking Security".

It's worth noting that this is not necessarily so. Where I work, we are
right now in the process of kerberizing all our NFS shares, which provides
real authentication, integrity, and encryption. Actually, it's true that
NFS proper has no security features per se; that's left to its transport.
All you need do is use a secure RPC underneath it.

--
Richard Silverman
res@qoxp.net

Nico Kadel-Garcia wrote:
> Paul Hink wrote:
>> Nico Kadel-Garcia wrote:
>>
>>> I've done that as an administrator in NFS based environments, and
>>> given users gentle warnings about NFS published home directories
>>> with no password SSH keys in them. It's a serious no-no in such an
>>> environment, since anyone can pretend to be the user with a simple
>>> NFS client and access all their files.
>>
>> If "anyone can pretend to be the user with a simple NFS client and
>> access all their files" there are different and more serious
>> problems than SSH keys with blank passwords.
>
> Welcome to NFS, brother. There's a compelling reason it's called "No
> Freaking Security".

Then why bother about blank SSH key passphrases at all? These keys have
to be regarded as compromised anyway.

Paul

On 2006-04-28, Richard E. Silverman wrote:
>>>>>> "mark" == mark writes:

> mark> always seemed to me a bit of a deficiency of ssh that an
> mark> administrator can not actually enforce this policy on users to
> mark> whom he is granting access to his server?
>
> Of course he should have an opinion, and communicate that to his users --
> but that's a matter of policy. Calling it a deficiency of SSH implies (at
> least to me) that there's some technical means by which an SSH server
> *could* enforce this policy, and the protocol or its implementations
> simply aren't using it. I know of no such means, and would be interested
> to hear if you have an idea.

Sounds like using keys alone is not what Mark wants. Hardware tokens then?

--
Elvis Notargiacomo master AT barefaced DOT cheek
http://www.notatla.org.uk/goen/
Powergen write "Why not stay with us" - let me count the ways!

>>>>> "all" == all mail refused writes:

all> On 2006-04-28, Richard E. Silverman wrote:
>>>>>>> "mark" == mark writes:

mark> always seemed to me a bit of a deficiency of ssh that an
mark> administrator can not actually enforce this policy on users to
mark> whom he is granting access to his server?
>> Of course he should have an opinion, and communicate that to his
>> users -- but that's a matter of policy. Calling it a deficiency of
>> SSH implies (at least to me) that there's some technical means by
>> which an SSH server *could* enforce this policy, and the protocol
>> or its implementations simply aren't using it. I know of no such
>> means, and would be interested to hear if you have an idea.

all> Sounds like using keys alone is not what Mark wants. Hardware
all> tokens then?

This could work, as long as he locks down the server so that only the
sysadmin can authorize keys for login.

--
Richard Silverman
res@qoxp.net

>>>>> "PH" == Paul Hink writes:

PH> Nico Kadel-Garcia wrote:
>> Paul Hink wrote:
>>> Nico Kadel-Garcia wrote:
>>>> I've done that as an administrator in NFS based environments, and
>>>> given users gentle warnings about NFS published home directories
>>>> with no password SSH keys in them. It's a serious no-no in such
>>>> an environment, since anyone can pretend to be the user with a
>>>> simple NFS client and access all their files.
>>> If "anyone can pretend to be the user with a simple NFS client
>>> and access all their files" there are different and more serious
>>> problems than SSH keys with blank passwords.
>> Welcome to NFS, brother. There's a compelling reason it's called
>> "No Freaking Security".

PH> Then why bother about blank SSH key passphrases at all? These keys
PH> have to be regarded as compromised anyway.

Then change them all & encrypt the new keys.

Just because multiple related parts of a system are flawed, does not mean
there's no point in fixing some of them. You have to start somewhere.

--
Richard Silverman
res@qoxp.net

mark schrieb:
> On Thu, 27 Apr 2006 00:52:27 -0400, Richard E. Silverman wrote:
>
>>>>>>>"mark" == mark writes:
>>
>> mark> Does anybody know of a way to enforce a policy where ssh key
>> mark> pass-phrases should not be empty? It is one of the "weaknesses"
>> mark> of ssh as I see it that an administrator can't actually impose
>> mark> this constraint on access to his own server.
>>
>>He can't, because it makes no sense. The server never sees the user's
>>private key. It has no control over where or how the key is stored. It's
>>like suggesting there's a lock out there that can "require" that you not
>>keep the key in your pocket.
>
>
> Richard, of course I realise that it doesn't "make sense" wrt to the
> fundamental design of ssh. The pass-phrase is only pertinent to
> unlocking the user's private key and that is that. But surely it does
> make "make sense" that an administrator may have a personal opinion that
> users should not be allowed to use empty pass-phrases on their keys?
> What I am saying is that it has always seemed to me a bit of a
> deficiency of ssh that an administrator can not actually enforce this
> policy on users to whom he is granting access to his server?
>
> I guess it would be possible to write a script for root to traverse over
> unix users client side home areas attempting to do some kind of
> ssh-keygen operation on their keys and confirming that a pass-phrase is
> prompted for? This doesn't address remote putty users etc, though.
>

I agree with you!
I am adminstrator for serveral hundreds servers, and I can not
enforce the users not to use encrypted keys. I would welcome an
extension to the protocoll to ask the client if the key is encrypted or
not. In an environment, e.g. intranet of an company like mine, where the
users can not install other binary (hopefully) it would make sense.

At the moment, the only method is to restrict the users to a central
login server an to scan the keys, which is very time consuming.

>>>>> "WT" == Wolfgang writes:

WT> mark schrieb:
>> On Thu, 27 Apr 2006 00:52:27 -0400, Richard E. Silverman wrote:
>>>>>>>> "mark" == mark writes:
>>>
mark> Does anybody know of a way to enforce a policy where ssh key
mark> pass-phrases should not be empty? It is one of the "weaknesses"
mark> of ssh as I see it that an administrator can't actually impose
mark> this constraint on access to his own server.
>>> He can't, because it makes no sense. The server never sees the
>>> user's private key. It has no control over where or how the key
>>> is stored. It's like suggesting there's a lock out there that can
>>> "require" that you not keep the key in your pocket.
>> Richard, of course I realise that it doesn't "make sense" wrt to
>> the fundamental design of ssh. The pass-phrase is only pertinent to
>> unlocking the user's private key and that is that. But surely it
>> does make "make sense" that an administrator may have a personal
>> opinion that users should not be allowed to use empty pass-phrases
>> on their keys? What I am saying is that it has always seemed to me
>> a bit of a deficiency of ssh that an administrator can not actually
>> enforce this policy on users to whom he is granting access to his
>> server? I guess it would be possible to write a script for root to
>> traverse over unix users client side home areas attempting to do
>> some kind of ssh-keygen operation on their keys and confirming that
>> a pass-phrase is prompted for? This doesn't address remote putty
>> users etc, though.
>>

WT> I agree with you! I am adminstrator for serveral hundreds
WT> servers, and I can not enforce the users not to use encrypted
WT> keys. I would welcome an extension to the protocoll to ask the
WT> client if the key is encrypted or not. In an environment,
WT> e.g. intranet of an company like mine, where the users can not
WT> install other binary (hopefully) it would make sense.

If you're going to rely on people's inability to use other than provided
software, what would make more sense is to modify the client to simply
refuse to use plaintext keys, rather than clutter the protocol with an
extension which does not increase security.

--
Richard Silverman
res@qoxp.net