On Sun, Dec 24, 2017 at 9:54 PM, David Newall <openssh at davidnewall.com>
wrote:> On 25/12/17 00:11, John Devitofranceschi wrote:
>>
>> Besides ssh.com?s PrivX product, has anyone created a web service that
can
>> be used to issue temporary certkeys to authenticated users?
>>
>> Any pointers appreciated!
>
>
> I expect that what I'm about to say is exactly what you're not
interested in
> hearing, but I think it's something that should be said nonetheless.
>
> The benefit of a central authority issuing a key so that a user can
> authenticate himself or herself with it is dubious at best.
please take my following comments as coming from someone who spends
his days securing ssh for an enterprise. thousands of users * 10's of
thousands of machines; I have a strong interest in centralization.
> First, it's backwards. The principle of user authentication is that
users
> should be free to choose their own password with which to secure their
> access, and that these passwords should be secrets known only to the
> individual users. This is one reason why passwords are not stored. A
> public/private key pair is an alternative form of password, but, still,
> users should be free to generate their own keys, which they use to say,
> "this is me." If a central authority generates the keys, then
they are
> effectively saying, "this is you." It's just backwards.
in an enterprise, I don't trust what the user chooses for a password or a
key.
> Second, it is more easily compromised. Here's why: the act of
generating a
> public and private key pair is approximately as secure if a user generates
> them or if a central authority generates them, and the act of transmitting
> half of the pair can be approximately as secure transmitting one or the
> other. But, that's not to say that transmitting the key is without
risk.
> Somebody could intercept the transmission and take a copy of the key. If
> it's a public key then nothing of great value has been obtained. If
it's a
> private key then the veracity of authentication is completely compromised.
> The public key should be sent from user to server; the private key must not
> be sent from server to user.
this might be true if ssh weren't an encrypted transport. but a client
can easily forward their ssh agent to a certificate distributing
server and, over an encrypted channel, receive both a private and
public key.
> Third, it doesn't scale. If every SSH server generated keys (or had
them
> generated on their user's behalf), then every user would need as many
keys
> as SSH servers that they used. That's an n-squared growth of keys. If
> users generate their own keys, they can use the same private key for all
> servers, if that's what they want. That's a linear growth of keys
(grows by
> number of users, not number of servers.)
for an enterprise, this is precisely wrong.
with certkeys, you distribute a single pubkey to every host and all
users with certs signed by the corresponding private key get access.
this is the opposite of needing to distribute the pukeys of N-users on
M-machines.
> Fourth, it's putting faith in a demonstrably untrustworthy party.
I'm not
> saying that PrivX, to use your example, cannot be trusted; I'm saying
that
> no central authority can be trusted. So many have been compromised that
the
> only rational assumption is that none can be trusted. Each user has his or
> her own security standard, and I'm willing to accept that a central
> authority is less likely to be compromised than a single user, but
> compromising a central authority breaks the security of all of its users,
> not just of a single user.
>
> For these reasons I advise do not use a web service to create the keys that
> users can and should create for themselves. There is nothing that I can
see
> such a service offering that is of any real value, and there is much damage
> that can be wreaked by them.
I would agree that using a random service for signing certs is a bad
idea. thankfully there are a few full featured opensource ssh CA's
already available. I have it on good authority that another is going
to be released in the near future as well.
> The particular question was about temporary keys. A key is only useful if
> the public half is registered. If you want it to be temporary, schedule a
> job to remove it after the requisite time. How? "man cron".
if there's nothing inherent in the key that forces expiration, you're
gonna have a bad time.
finally (and it seems like no one talks about this), ssh certs work
for hosts as well. that means no more "host key doesn't match"
warnings, ever.
that's, "drops mic" level badassary.
> I apologise if my comments seem needlessly dismal or sermon-like. I
imagine
> the question was based on a notion that users are capable of using SSH but
> not capable of generating their own keys. I reject that notion. Users
> learn how to drive motor vehicles, and that's much harder than
generating
> SSH keys. Don't pander to mere laziness.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev