[jira] [Commented] (SSHD-850) Add capability to retry a failed private key decryption when client is decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16658386#comment-16658386
]
Thomas Wolf commented on SSHD-850:
--
Thanks; that looks good.
> 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
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 2.1.1
>
>
> 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 value.
> {{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
(v7.6.3#76005)
[jira] [Commented] (SSHD-850) Add capability to retry a failed private key decryption when client is decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656138#comment-16656138
]
Goldstein Lyor commented on SSHD-850:
-
{quote}
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).
{quote}
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}}
{code:java}
enum FileDecodeResult {
TERMINATE,
RETRY,
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;
}
{code}
* 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 value.
> {{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
(v7.6.3#76005)
[jira] [Commented] (SSHD-850) Add capability to retry a failed private key decryption when client is decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655582#comment-16655582
]
Thomas Wolf commented on SSHD-850:
--
I don't quite understand that. As far as I see, KeyPairProviders are intended
to lazily load keys already. Overriding and re-implementing {{doLoadKey(String
resourceKey, InputStream inputStream, FilePasswordProvider provider)}} should
be good enough.
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). One
is also still left with the problem of how exactly to pass in the desired
number of attempts. Perhaps through the {{FilePasswordProvider}} or a new
subclass thereof (which could even provide a {{getPasswordAgain()}} method),
but if the same one is used for different sessions, that may still get messy.
But lazy-loading keys is problematic anyway with the default {{SshClient}}
since {{SshClient.connect(HostConfigEntry hostConfig)}} pre-loads all
identities from the {{HostConfigEntry}} anyway. At that point it'll ask for
passwords even for keys that may finally not even be used.
Oh, and the {{ClientIdentityLoader}} would also have to be re-done.
> 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 value.
> {{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
(v7.6.3#76005)
[jira] [Commented] (SSHD-850) Add capability to retry a failed private key decryption when client is decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655339#comment-16655339
]
Goldstein Lyor commented on SSHD-850:
-
One possible avenue of solution might be to override {{Iterable
loadKeys()}} and encapsulate an {{Iterator}} that "lazily" loads the keys, so
that when a key with a problematic password is encountered it can execute the
retry mechanism behind the scenes.
> 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 value.
> {{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
(v7.6.3#76005)
