Use of non-user readable (null password) private keys

[Piete Brooks]

> Example:
...
> Security has now been compermised.

Sure -- I can see how having user private keys readable is not a good idea.

What I want is the *ABILITY* to have public `capabilities' which can perform a 
fixed operation (e.g. prod a server) which is `harmless'.

> I would not consider this a bug.

:-(

> It's a safety feature to protect the user from doing stupid things.

I want the ability to say "this is not the action of a dumb user -- I know 
what I'm doing"

This is explicitly using `-i' -- not defaulting to a .ssh/ file

> I don't see why the 'private' key should be allowed to be made public.

As per the example I gave -- it is not a key which allows login or such -- it 
is bound to a particular command.

>> We use a client/server model with no `user' accounts on servers.
>> There are certain operations which a user may require to run with certain
>> privs, and we use ssh to do this. The capability may be given to an 
individual
>> user (user-only-readable in their .ssh/), a group (using UN*X group 
semantics)
>> or may be accessible to all users of a particular machine or set of machines
>> (e.g. when a user changes their password, a process is woken up on the
>> password server).
> Feel free to explain why such behavior is not correct.

I did in my message :-(

> I can't see how allowing everyone to read/steal my keys

It is not "my key", it is a capability which I want to be able to give 
multiple users.

> is considered a Good Thing(tm). =)

I want to make it easy for users to do the thinks they need to do.
Locally they can use sudo, but for performing operations on a remote machine, 
they need an ssh capability.


SO: your (plural) concern is that we have to avoid bozo users being insecure 
by doing silly things -- yes ?

1) I don't think it should be needed if `-i' is used.
2) How about `if owned by root, can be readable by others' (root is no bozo)
3) ... and not readable by user (root)	[ won'
4) ... and has the sticky bit set
5) ... and has the setuid bit set
etc

Failing that, a separate flag to say `capability can be readable' ?