diff options
author | djm@openbsd.org <djm@openbsd.org> | 2020-01-06 02:00:46 +0000 |
---|---|---|
committer | Damien Miller <djm@mindrot.org> | 2020-01-06 13:12:46 +1100 |
commit | c312ca077cd2a6c15545cd6b4d34ee2f69289174 (patch) | |
tree | b8dd974c55dd0de351dfcbfc4f33fddb935a1c12 /ssh-keygen.1 | |
parent | 2ab335712d084d9ccaf3f53afc3fa9535329da87 (diff) |
upstream: Extends the SK API to accept a set of key/value options
for all operations. These are intended to future-proof the API a little by
making it easier to specify additional fields for without having to change
the API version for each.
At present, only two options are defined: one to explicitly specify
the device for an operation (rather than accepting the middleware's
autoselection) and another to specify the FIDO2 username that may
be used when generating a resident key. These new options may be
invoked at key generation time via ssh-keygen -O
This also implements a suggestion from Markus to avoid "int" in favour
of uint32_t for the algorithm argument in the API, to make implementation
of ssh-sk-client/helper a little easier.
feedback, fixes and ok markus@
OpenBSD-Commit-ID: 973ce11704609022ab36abbdeb6bc23c8001eabc
Diffstat (limited to 'ssh-keygen.1')
-rw-r--r-- | ssh-keygen.1 | 23 |
1 files changed, 19 insertions, 4 deletions
diff --git a/ssh-keygen.1 b/ssh-keygen.1 index 7b83a2240..92c516588 100644 --- a/ssh-keygen.1 +++ b/ssh-keygen.1 | |||
@@ -1,4 +1,4 @@ | |||
1 | .\" $OpenBSD: ssh-keygen.1,v 1.188 2020/01/03 07:33:33 jmc Exp $ | 1 | .\" $OpenBSD: ssh-keygen.1,v 1.189 2020/01/06 02:00:46 djm Exp $ |
2 | .\" | 2 | .\" |
3 | .\" Author: Tatu Ylonen <ylo@cs.hut.fi> | 3 | .\" Author: Tatu Ylonen <ylo@cs.hut.fi> |
4 | .\" Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland | 4 | .\" Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland |
@@ -35,7 +35,7 @@ | |||
35 | .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF | 35 | .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF |
36 | .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | 36 | .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. |
37 | .\" | 37 | .\" |
38 | .Dd $Mdocdate: January 3 2020 $ | 38 | .Dd $Mdocdate: January 6 2020 $ |
39 | .Dt SSH-KEYGEN 1 | 39 | .Dt SSH-KEYGEN 1 |
40 | .Os | 40 | .Os |
41 | .Sh NAME | 41 | .Sh NAME |
@@ -462,8 +462,18 @@ section may be specified. | |||
462 | .Pp | 462 | .Pp |
463 | When generating a key that will be hosted on a FIDO authenticator, this | 463 | When generating a key that will be hosted on a FIDO authenticator, this |
464 | flag may be used to specify key-specific options. | 464 | flag may be used to specify key-specific options. |
465 | Two FIDO authenticator options are supported at present: | 465 | The FIDO authenticator options are supported at present are: |
466 | .Pp | 466 | .Pp |
467 | .Cm application | ||
468 | overrides the default FIDO application/origin string of | ||
469 | .Dq ssh: . | ||
470 | This option may be useful when generating host or domain-specific resident | ||
471 | keys. | ||
472 | .Cm device | ||
473 | explicitly specify a device to generate the key on, rather than accepting | ||
474 | the authenticator middleware's automatic selection. | ||
475 | .Xr fido 4 | ||
476 | device to use, rather than letting the token middleware select one. | ||
467 | .Cm no-touch-required | 477 | .Cm no-touch-required |
468 | indicates that the generated private key should not require touch | 478 | indicates that the generated private key should not require touch |
469 | events (user presence) when making signatures. | 479 | events (user presence) when making signatures. |
@@ -478,6 +488,11 @@ Resident keys may be supported on FIDO2 tokens and typically require that | |||
478 | a PIN be set on the token prior to generation. | 488 | a PIN be set on the token prior to generation. |
479 | Resident keys may be loaded off the token using | 489 | Resident keys may be loaded off the token using |
480 | .Xr ssh-add 1 . | 490 | .Xr ssh-add 1 . |
491 | .Cm user | ||
492 | allows specification of a username to be associated with a resident key, | ||
493 | overriding the empty default username. | ||
494 | Specifying a username may be useful when generating multiple resident keys | ||
495 | for the same application name. | ||
481 | .Pp | 496 | .Pp |
482 | The | 497 | The |
483 | .Fl O | 498 | .Fl O |