[Cyberduck-trac] [Cyberduck] #10404: Support for signed SSH certificates

[Cyberduck]

#10404: Support for signed SSH certificates
----------------------+------------------------
 Reporter:  jshannon  |         Owner:  dkocher
     Type:  feature   |        Status:  closed
 Priority:  normal    |     Milestone:  8.0
Component:  sftp      |       Version:  6.6.2
 Severity:  normal    |    Resolution:  fixed
 Keywords:            |  Architecture:
 Platform:            |
----------------------+------------------------

Comment (by dkocher):

 {{{
 CERTIFICATES
      ssh-keygen supports signing of keys to produce certificates that may
 be used for user or host authentication.  Certificates consist of a public
 key, some identity information, zero or more principal (user or host)
 names and a set of
      options that are signed by a Certification Authority (CA) key.
 Clients or servers may then trust only the CA key and verify its signature
 on a certificate rather than trusting many user/host keys.  Note that
 OpenSSH certificates are a
      different, and much simpler, format to the X.509 certificates used in
 ssl(8).

      ssh-keygen supports two types of certificates: user and host.  User
 certificates authenticate users to servers, whereas host certificates
 authenticate server hosts to users.  To generate a user certificate:

            $ ssh-keygen -s /path/to/ca_key -I key_id /path/to/user_key.pub

      The resultant certificate will be placed in /path/to/user_key-
 cert.pub.  A host certificate requires the -h option:

            $ ssh-keygen -s /path/to/ca_key -I key_id -h
 /path/to/host_key.pub

      The host certificate will be output to /path/to/host_key-cert.pub.

      It is possible to sign using a CA key stored in a PKCS#11 token by
 providing the token library using -D and identifying the CA key by
 providing its public half as an argument to -s:

            $ ssh-keygen -s ca_key.pub -D libpkcs11.so -I key_id
 user_key.pub

      Similarly, it is possible for the CA key to be hosted in a ssh-
 agent(1).  This is indicated by the -U flag and, again, the CA key must be
 identified by its public half.

            $ ssh-keygen -Us ca_key.pub -I key_id user_key.pub

      In all cases, key_id is a "key identifier" that is logged by the
 server when the certificate is used for authentication.

      Certificates may be limited to be valid for a set of principal
 (user/host) names.  By default, generated certificates are valid for all
 users or hosts.  To generate a certificate for a specified set of
 principals:

            $ ssh-keygen -s ca_key -I key_id -n user1,user2 user_key.pub
            $ ssh-keygen -s ca_key -I key_id -h -n host.domain host_key.pub

      Additional limitations on the validity and use of user certificates
 may be specified through certificate options.  A certificate option may
 disable features of the SSH session, may be valid only when presented from
 particular source
      addresses or may force the use of a specific command.  For a list of
 valid certificate options, see the documentation for the -O option above.

      Finally, certificates may be defined with a validity lifetime.  The
 -V option allows specification of certificate start and end times.  A
 certificate that is presented at a time outside this range will not be
 considered valid.  By
      default, certificates are valid from UNIX Epoch to the distant
 future.

      For certificates to be used for user or host authentication, the CA
 public key must be trusted by sshd(8) or ssh(1).  Please refer to those
 manual pages for details.


 }}}

--
Ticket URL: <https://trac.cyberduck.io/ticket/10404#comment:4>
Cyberduck <https://cyberduck.io>
Libre FTP, SFTP, WebDAV, S3 & OpenStack Swift browser for Mac and Windows