mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Goldstein Lyor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SSHD-850) Add capability to retry a failed private key decryption when client is decrypting private key file(s)
Date Fri, 19 Oct 2018 01:33:00 GMT

    [ https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16656138#comment-16656138

Goldstein Lyor commented on SSHD-850:

But it remains a big ugly hack in my opinion. Doing it that level requires guessing things
(such as if I get an IOException before I asked for a passsword, it's some other problem,
don't retry, but if I get one after, then it is in all likelihood an indication of a wrong
password). That's why I think it'd be much better implemented in core, at the place(s) where
getPassword() is called. There one knows much more, and is not restricted to guesswork (which
may moreover break if the core implementation changes).
Sounds reasonable, but is more difficult then it sounds since the location where {{getPassword}}
is called is not necessarily the same as where the decoding is attempted. Therefore changes
at the core level for (IMO) a minor feature do not seem like a good idea at this time. I do
have an idea that I would like to explore that may help facilitate implement this issue -
although it will not relieve the user from having to track whether {{getPassword}} was called
for a specific file and do a bit of "guesswork" (as you put it):

* Add a *default* method to {{FilePasswordProvider}} called {{handleDecodingAttemptResult}}
enum FileDecodeResult {
    IGNORE;   // Ignore and take your chances with the code that is trying to use this key

default FileDecodeResult handleDecodingAttemptResult(String resourceKey, Exception err /*
null if success */) {
    return FileDecodeResult .TERMINATE;
* The method will be invoked regardless of whether {{getPassword}} was invoked (so the user
knows about successes as well as failures)
* The user can/should use the resource key in order to decide whether {{getPassword}} has
been called for the specified file or not.
* The user can then examine the reported exception (thus "some guesswork") and decide whether
to proceed with a retry or not.
* The {{IGNORE}} case is provided for future uses and/or "advanced" coders who know what they're
doing and are willing to take a chance with the fact that the decoding did not succeed and
no key was loaded (note that the code is quite tolerant of the fact that no keys are available
- at least on the client side).

Note that failure to decode is more likely to be due to a {{GeneralSecurityException}} rather
than an {{IOException}}, but there are no guarantees as to how failure to decode is signaled.
However, as an initial implementation of this feature I think that users can treat all I/O
or security exceptions as some problem with the password simply display the exception type/text
as a prompt to the interactive framework.

The success call is provided so that implementors can clear any internal state associated
with tracking calls to {{getPassword}}

> Add capability to retry a failed private key decryption when client is decrypting private
key file(s)
> -----------------------------------------------------------------------------------------------------
>                 Key: SSHD-850
>                 URL: https://issues.apache.org/jira/browse/SSHD-850
>             Project: MINA SSHD
>          Issue Type: New Feature
>    Affects Versions: 2.0.0, 2.1.0
>            Reporter: Thomas Wolf
>            Priority: Minor
> In openssh, the ssh config entry NumberOfPasswordPrompts controls the number of times
the ssh client keeps asking for a password if the one entered was invalid in two cases:
>  # keyboard-interactive authentication, and
>  # asking for passwords for encrypted private keys in identity files in pubkey authentication
(see [openssh sources; sshconnect2.c|https://github.com/openssh/openssh-portable/blob/1a4a9cf/sshconnect2.c#L1380]).
> sshd-core only has support for (1) through setting the property {{ClientAuthenticationManager.PASSWORD_PROMPTS}}
in the session's properties.
> There doesn't seem to be any support for FilePasswordProvider to make it respect this
> {{AbstractPEMResourceKeyPairParser.extractkeyPairs()}} and also {{BouncyCastleKeyPairResourceParser.loadKeyPair()}}
call {{FilePasswordProvider.getPassword()}} exactly once.
> So how can I write a ssh client using sshd that asks the user NumberOfPasswordPrompts
times? Either I'm missing something, or there is some support for this missing in sshd.

This message was sent by Atlassian JIRA

View raw message