[
https://issues.apache.org/jira/browse/SSHD-1166?focusedWorklogId=603594&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-603594
]
ASF GitHub Bot logged work on SSHD-1166:
----------------------------------------
Author: ASF GitHub Bot
Created on: 28/May/21 16:07
Start Date: 28/May/21 16:07
Worklog Time Spent: 10m
Work Description: alex-sherwin commented on a change in pull request #198:
URL: https://github.com/apache/mina-sshd/pull/198#discussion_r641662142
##########
File path:
sshd-common/src/main/java/org/apache/sshd/common/config/keys/OpenSshCertificate.java
##########
@@ -52,26 +57,34 @@
Collection<String> getPrincipals();
/**
- * Retrieves the time in number of seconds since the {@link
java.time.Instant#EPOCH} at which this certificate
- * becomes or became valid.
- *
- * @return the number of seconds since the Instant.EPOCH <em>as an
unsigned 64bit value</em>
- * @see {{@link #isValidNow(OpenSshCertificate)}
+ * When null, implies forever
*/
- long getValidAfter();
+ Instant getValidAfter();
+
+ default long getValidAfterEpochSeconds() {
+ if (getValidAfter() == null) {
+ return VALID_AFTER_FOREVER_EPOCH;
+ }
+ return getValidAfter().getEpochSecond();
Review comment:
I don't think it can be legally `0` and mean "forever"
I just re-read the man page for `ssh-keygen`'s `validity_interval` and you
can use the magic values `always` for the `validAfter` and `forever` for
`validBefore`
But, when encoded, there is no special flag to indicate this, they are still
just epoch (seconds) uint64's, where `always` (`validAfter`) is encoded as `0`
and `forever` (`validBefore`) is uint64 max value
I manually verified this by generating certs and looking at the encoded
bytes, and you can also see it like this, where generating a certificate using
`-V 'always:20220101' versus `-V '19790101:20220101` yield identical values.
If you inspect the cert using `ssh-keygen -L -f [file]` when using a cert
generated with `-V '19790101:20220101`, as you would now expect, it prints a
human-friendly output of what "always" would have shown.
What's more, is if you move the date back before UTC 1970, ssh-keygen still
encodes it as `0` (which I guess they have to, since it's a uint64)
... so maybe when they defined the spec they assumed (probably rightly so)
that no one would be trying to enforce a `validAfter` time on a server that was
pretending to run pre 1970?
So, it seems to me, like they do treat `0` and max uint64 as a magic value.
However, it is also entirely possible this magic behavior is just for the
human-friendly output of the CLI tools...
I'm happy to change this to behave how you think it should, but I'm not
really sure what that should be
--
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:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 603594)
Time Spent: 1.5h (was: 1h 20m)
> 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: 1.5h
> 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: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
