Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for signed SSH certificates #10404

Closed
cyberduck opened this issue Jul 23, 2018 · 2 comments
Closed

Support for signed SSH certificates #10404

cyberduck opened this issue Jul 23, 2018 · 2 comments
Assignees
Labels
feature fixed sftp SFTP Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

6ecd071 created the issue

Please support ssh certs signed by a CA. See https://man.openbsd.org/ssh-keygen#CERTIFICATES

This process produces a
key-cert.pub file which is signed by the CA and is presented to the server. I've tried selecting that file in CyberDuck and I get message that it's an invalid format.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In d893390.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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 PKCS11 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.


@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature fixed sftp SFTP Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants