Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Feature request
September 29, 2004, 10:29 pm
rate this thread
I don't know whether this is the right group to post but I'll give it a
I must admit that I haven't looked how the authentication handshake happens
and whether the feature I'm going to ask is achievable having the protocol
I like to lockdown installed public keys by adding a
'fingerprint="xx:xx:xx....:xx" option to it. I can then create a secure
webserver and enforce strong passphrases. The user will receive a private
key (file download in browser) and the webserver keeps the public key and
the belonging fingerprint.
Also a 'validuntil='<date>' option would be great to help the feature even
more to be able to create temporary accounts. This will save me from
tampering around with the shadowfile.
- Richard E. Silverman
September 30, 2004, 2:52 am
Re: Feature request
PB> I like to lockdown installed public keys by adding a
PB> 'fingerprint="xx:xx:xx....:xx" option to it.
I don't understand. The fingerprint is a function of the key; this adds
PB> I can then create a secure webserver and enforce strong
You cannot enforce any kind of passphrases at all. The passphrase is used
to encrypt the private key; it is on the client side, not visible to the
protocol, and not under your control at all.
PB> The user will receive a private key (file download in browser) and
PB> the webserver keeps the public key and the belonging fingerprint.
This should *never* happen; people generate their own private keys, so
they know they are indeed private. What do you think you gain by
generating them yourself?
- Niels van Dijke
September 30, 2004, 6:57 am
Re: Feature request
Isn't it so that the fingerprint a MD5 sum is of the private key? If that is
case why can that not be send across on request in the handshake phase? As
long as the MD5 algorithm hasn't been broken, this should be safe to do.
This is also why security people do not like passphrases. The can be to weak
or even empty! And a sysadmin has no means of verifying weak passphrases. So
a sysadmin needs to trust both the user in his activities and also that he
uses strong passphrases. I do know from experience that users who do not use
ssh-agents or any other technique of passphrase caching use to weak
passphrases. Simply because they do not want to type in 20+ character
Why should this *never* happen? I'm responsible for the servers I manage.
Okay, I can try to refuse to create accounts. But management will overule
this by default. If the key is for business use only then to my opinion this
key does not have to be secret to the user only by default. We have syslog
standard on 'info' level and have therefor the fingerprint logging. For
auditing by it self would the fingerprint option in the authorized_keys be
If we generate the key ourselves we have control over the strength (length
and randomness). With the fingerprint matching a user would not be able to
weaken their passphrase without notifying the sysadmin (assuming that they
can not change their own authorized_keys file).
Re: Feature request
The fingerprint is computed from the public key - but your idea wouldn't
be any more useful if it was computed from the private key: The
fundamental basis for public/private key cryptography is that the key
pairs are "unique" - a given public key can only ever be used with the
corresponding private one and vice versa. I.e. if the user were to
change his private key in any way, he could no longer be authenticated
by the public key that you have on the server. (N.B. the passphrase is
not part of the key.)
Because it's a bad idea to ship secret things around and needlessly
store them in multiple places.
You gain nothing by having knowledge of what the secret key is, see
above - but obviously you could lose a lot if a third-party manages to
get hold of it due to flaws in your creation/distribution/storage
No, it's useless, see above.
You may possibly have a point regarding the randomness, but I believe
most key-generation SW does a good job of ensuring that - and unless you
use cryptographic HW, simply having the knowledge that the key was
generated on a specific server at a specific time may at least
theoretically increase the probability of a successful attack over the
case where it was done on some random end-user host at an unknown point
in time. All in all, probably won't outweigh the cons above.
The length can be determined from the public key alone of course, so you
just need to make that a requirement and refuse to accept public keys of
a shorter length.
No, the fingerprint is quite independent of the passphrase.
Hm, it seems maybe you actually think that the fingerprint is just a
straight MD5 sum of the private key file as stored on disk. It isn't,
obviously (and couldn't be used for its intented purposes if it were),
but such a thing could possibly be used for the purposes you consider
above. On the other hand a given private key with a given passphrase is
likely to yield different such MD5 sums depending on type of client SW
and OS - there is no standard for how keys are stored on disk, and as
far as I know not even for how the passphrase is used to encrypt them.
And of course strictly speaking, if you don't trust the user to manage
his key securely, you also couldn't trust that he didn't modify his
client SW to send your "expected" MD5 sum regardless of what is actually
in his key file.
But this last part is all academic anyway - ssh client SW doesn't send
or even compute such an MD5 sum, so there's no way the server can verify
- » root remote access allowance for some users@machines
- — Next thread in » Secure Shell Forum
- » fatal: buffer_get: trying to get more bytes 4 than in buffer 0
- — Previous thread in » Secure Shell Forum
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — Newest thread in » Secure Shell Forum