[
https://issues.apache.org/jira/browse/SSHD-1166?focusedWorklogId=603257&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-603257
]
ASF GitHub Bot logged work on SSHD-1166:
----------------------------------------
Author: ASF GitHub Bot
Created on: 27/May/21 20:55
Start Date: 27/May/21 20:55
Worklog Time Spent: 10m
Work Description: alex-sherwin opened a new pull request #198:
URL: https://github.com/apache/mina-sshd/pull/198
This adds new OpenSshCertificateSigner & OpenSshCertificateSignRequest types
which are used to use a CA KeyPair to sign a OpenSshCertificateSignRequest,
resulting in an instance of OpenSshCertificate with the signature bytes filled
in.
The resulting OpenSshCertificate instance is completely valid and can be
serialized over the wire using the Buffer.put*PublicKey functions or serialized
using the existing OpenSSHKeyPairResourceWriter class.
This change also:
* Fixed a subtle bug observed in KeyUtils mapping data, where order matters
for discovery in a few places. There are places which iterate over the map
entries and check if a unknown Key instance is an instance of the registered
map PublicKey or PrivateKey type. Unfortunately, some of these registrations
register `java.security.PrivateKey`, which all private keys are an instance of,
thus matching this registration (which may actually be wrong). By making order
matter here, all more specific registered types have a chance to succeed first.
* Changed the data type of OpenSshCertificate.validAfter/validBefore from a
long to Instant for better developer UX (the long value encoded is actually
epoch seconds, which is uncommon for developers to work with in Java). This
change also makes it nullable, which helps with the concept of representing
"forever" signed OpenSSH Certificates.
* Added some constants to OpenSshCertificate to represent the magic forever
epochs
* Added a new OpenSshCertificate.CriticalOption data type and modified the
criticalOptions/extensions types to use it. This allows for proper
representation of critical option (and extension) data, which are not simply
strings (they are in fact key/value pairs).
* Fixed OpenSSHCertificateDecoder encoding of a OpenSshPublicKey to call
Buffer.putRawPublicKey, which properly prepends the key type before writing the
key data. Existing code paths for OpenSshCertificate usage didn't previously
hit this, so it went unnoticed.
* updated Buffer with specific encode/decode functions for the new
OpenSshCertificate.CriticalOption data type. The existing code was
encoding/decoding Critical Options & Extensions incorrectly (as CSV data).
This went unnoticed though, since generally speaking critical options are not
used (so this was never checked by anything) and extensions are an optional
implementation that must be ignored by a server if they are not recognized (so,
silently ignored). I added a unit test which now asserts decoding valid,
existing OpenSSH certificates, and encoding/decoding ones which were generated
by the features in this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 603257)
Remaining Estimate: 0h
Time Spent: 10m
> Support generating OpenSSH client certificates
> ----------------------------------------------
>
> Key: SSHD-1166
> URL: https://issues.apache.org/jira/browse/SSHD-1166
> Project: MINA SSHD
> Issue Type: New Feature
> Reporter: Alex Sherwin
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Support generating OpenSSH client certificates
> The OpenSSH certificate spec is defined here:
> https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD
> MINA already supports using OpenSSH client certs for publickey auth via
> SSHD-1161
> This ticket is to support creating/generating OpenSSH client certificates
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
