[jira] [Commented] (SSHD-852) Verification fails for hashed known host entry on non standard port generated by OpenSSH client
[
https://issues.apache.org/jira/browse/SSHD-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16654040#comment-16654040
]
Goldstein Lyor commented on SSHD-852:
-
Thanks for the contribution - created
[https://github.com/apache/mina-sshd/pull/71.] I will review it and merge it in
if no problems come up. Can you provide some link to the documentation that
explains how known host hashes should be calculated for standard and
non-standard ports ? I would be especially interested also in how to hash IPv6
addresses (though not an issue at the moment).
> Verification fails for hashed known host entry on non standard port generated
> by OpenSSH client
> ---
>
> Key: SSHD-852
> URL: https://issues.apache.org/jira/browse/SSHD-852
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Linux Mint 19
>Reporter: Stefan Verhoeven
>Priority: Minor
> Attachments: ConnectToNonDefaultPortTest.java
>
>
> The Apache SshClient is unable to verify a known host entry that was made by
> the OpenSSH client when the entry is on a port other than 22.
>
> I get the following exception
> {code:java}
> org.apache.sshd.common.SshException: Server key did not validate
> at
> org.apache.sshd.client.session.AbstractClientSession.checkKeys(AbstractClientSession.java:440)
> ...{code}
>
> The OpenSSH client will create a hash for `[host]:port` while Apache
> SshClient will check hashed entries for `host` (see
> https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130[).|https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130.]
> This difference will cause the correct known host entry to be marked as not
> a match which in turn causes the exception.
>
> The error can be reproduced by setting up the a SSH server
> {code:java}
> rm ~/.ssh/known_hosts
> docker run -d -p :22 nlesc/xenon-ssh
> # Prime known hosts with hash entry, password=javagat
> ssh xenon@localhost -p 10022 hostname
> {code}
> and then running the attached test.
>
> I created a fix and tests at
> https://github.com/apache/mina-sshd/compare/master...NLeSC:hashed-known-host-port
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] mina-sshd pull request #71: OpenSSH client creates hash with port, mina shou...
GitHub user lgoldstein opened a pull request: https://github.com/apache/mina-sshd/pull/71 OpenSSH client creates hash with port, mina should be able to verify ⦠â¦that hash Compare hash with `[host]:port` if port is non-standard You can merge this pull request into a Git repository by running: $ git pull https://github.com/NLeSC/mina-sshd hashed-known-host-port Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mina-sshd/pull/71.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #71 commit 5c380939b3af687619514d378a6fab43cf6ae585 Author: Stefan Verhoeven Date: 2018-10-17T17:32:16Z OpenSSH client creates hash with port, mina should be able to verify that hash Compare hash with `[host]:port` if port is non-standard ---
[jira] [Created] (SSHD-852) Verification fails for hashed known host entry on non standard port generated by OpenSSH client
Stefan Verhoeven created SSHD-852:
-
Summary: Verification fails for hashed known host entry on non
standard port generated by OpenSSH client
Key: SSHD-852
URL: https://issues.apache.org/jira/browse/SSHD-852
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.1.1
Environment: Linux Mint 19
Reporter: Stefan Verhoeven
Attachments: ConnectToNonDefaultPortTest.java
The Apache SshClient is unable to verify a known host entry that was made by
the OpenSSH client when the entry is on a port other than 22.
I get the following exception
{code:java}
org.apache.sshd.common.SshException: Server key did not validate
at
org.apache.sshd.client.session.AbstractClientSession.checkKeys(AbstractClientSession.java:440)
...{code}
The OpenSSH client will create a hash for `[host]:port` while Apache SshClient
will check hashed entries for `host` (see
https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130[).|https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-common/src/main/java/org/apache/sshd/client/config/hosts/KnownHostEntry.java;h=91d61842373bb322b09198f551d6dfd095554677;hb=HEAD#l130.]
This difference will cause the correct known host entry to be marked as not a
match which in turn causes the exception.
The error can be reproduced by setting up the a SSH server
{code:java}
rm ~/.ssh/known_hosts
docker run -d -p :22 nlesc/xenon-ssh
# Prime known hosts with hash entry, password=javagat
ssh xenon@localhost -p 10022 hostname
{code}
and then running the attached test.
I created a fix and tests at
https://github.com/apache/mina-sshd/compare/master...NLeSC:hashed-known-host-port
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SSHD-851) Last chunk of data lost into local port forwarding channel
[
https://issues.apache.org/jira/browse/SSHD-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653640#comment-16653640
]
Roberto Deandrea commented on SSHD-851:
---
I guess that the problem is originated from changes made in
Nio2Sesion.doCloseGracefully() for issue SSHD-85.
>From old code:
_@Override_
_protected CloseFuture doCloseGracefully() {_
_return builder().when(writes).build().close(false);_
_}_
To new code:
_@Override_
_protected CloseFuture doCloseGracefully() {_
_return builder().when(writes).run(() -> {_
_try {_
_AsynchronousSocketChannel socket = getSocket();_
_socket.shutdownOutput();_
_} catch (IOException e) {_
_log.info("doCloseGracefully({}) {} while shutting down output:
{}",_
_this, e.getClass().getSimpleName(), e.getMessage());_
_}_
_}).build().close(false);_
_}_
> Last chunk of data lost into local port forwarding channel
> --
>
> Key: SSHD-851
> URL: https://issues.apache.org/jira/browse/SSHD-851
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: Roberto Deandrea
>Priority: Major
> Attachments: sshd.agent.trace
>
>
> Hi Lyor,
> I found another problem transferring data through a local port forwarding
> channel.
> It seems that the problem is located into Apache SSHD server code according
> to me.
> All the data are transferred from the originating client to the Apache SSH
> client and then go to the SSHD server through a local port forwarding channel.
> When the client stops sending data, and the channel is being closed, the
> SSHD server fail to send the last chunk of data to the target destination.
> In the attached trace file the problem is isolated as the following:
> *local port forwarding channel : [id=732 recipient=732]*
> *Nio2Session[local=/0:0:0:0:0:0:0:0:50047, remote=/192.168.2.107:62284
> session against target server*
> Looking through the traces I see that when the local port forwarding channel
> is closed, the Nio2Session against the target server is closed gracefully,
> but instead of waiting to complete pending socket writes to the target server
> the Nio2Session is then closed immediately causing write failures.
> In the traces I see:
> 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-1]
> [AbstractCloseable.close] close(Nio2Session[local=/0:0:0:0:0:0:0:0:50047,
> remote=/192.168.2.107:62284]) Closing gracefully
> 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2]
> [AbstractCloseable.close]
> close(org.apache.sshd.common.io.nio2.Nio2Connector@77fcff14) Closing
> immediately^M
> 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2]
> [AbstractCloseable.close] close(Nio2Session[local=/0:0:0:0:0:0:0:0:50047,
> remote=/192.168.2.107:62284]) Closing immediately
> After that I see:
> 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2]
> [Nio2Session.doCloseImmediately]
> doCloseImmediately(Nio2Session[local=/0:0:0:0:0:0:0:0:50047,
> remote=/192.168.2.107:62284]) signal write abort for
> future=Nio2DefaultIoWriteFuture[id=/192.168.2.107:62284][value=null]
> 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2]
> [TcpipServerChannel.handleWriteDataFailure]
> handleWriteDataFailure(TcpipServerChannel[id=732,
> recipient=732]-ServerSessionImpl[aixdmzdriverssh@/192.168.10.34:55335])[SSH_MSG_CHANNEL_DATA]
> failed (WriteAbortedException) to write len=16384: Write request aborted due
> to immediate session close
>
> These errors are repeated multiple times.
> The sum of bytes not written are equal to the chunk of data missing ad the
> target server.
> Can you troubleshoot this problem?
> Let me know if you need more info.
>
> Cheers
> Roberto
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SSHD-851) Last chunk of data lost into local port forwarding channel
Roberto Deandrea created SSHD-851: - Summary: Last chunk of data lost into local port forwarding channel Key: SSHD-851 URL: https://issues.apache.org/jira/browse/SSHD-851 Project: MINA SSHD Issue Type: Bug Affects Versions: 2.1.1 Reporter: Roberto Deandrea Attachments: sshd.agent.trace Hi Lyor, I found another problem transferring data through a local port forwarding channel. It seems that the problem is located into Apache SSHD server code according to me. All the data are transferred from the originating client to the Apache SSH client and then go to the SSHD server through a local port forwarding channel. When the client stops sending data, and the channel is being closed, the SSHD server fail to send the last chunk of data to the target destination. In the attached trace file the problem is isolated as the following: *local port forwarding channel : [id=732 recipient=732]* *Nio2Session[local=/0:0:0:0:0:0:0:0:50047, remote=/192.168.2.107:62284 session against target server* Looking through the traces I see that when the local port forwarding channel is closed, the Nio2Session against the target server is closed gracefully, but instead of waiting to complete pending socket writes to the target server the Nio2Session is then closed immediately causing write failures. In the traces I see: 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-1] [AbstractCloseable.close] close(Nio2Session[local=/0:0:0:0:0:0:0:0:50047, remote=/192.168.2.107:62284]) Closing gracefully 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2] [AbstractCloseable.close] close(org.apache.sshd.common.io.nio2.Nio2Connector@77fcff14) Closing immediately^M 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2] [AbstractCloseable.close] close(Nio2Session[local=/0:0:0:0:0:0:0:0:50047, remote=/192.168.2.107:62284]) Closing immediately After that I see: 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2] [Nio2Session.doCloseImmediately] doCloseImmediately(Nio2Session[local=/0:0:0:0:0:0:0:0:50047, remote=/192.168.2.107:62284]) signal write abort for future=Nio2DefaultIoWriteFuture[id=/192.168.2.107:62284][value=null] 2018-10-16 16:20:19,167 DEBUG [xdmzdriverssh@/192.168.10.34:55335]]-thread-2] [TcpipServerChannel.handleWriteDataFailure] handleWriteDataFailure(TcpipServerChannel[id=732, recipient=732]-ServerSessionImpl[aixdmzdriverssh@/192.168.10.34:55335])[SSH_MSG_CHANNEL_DATA] failed (WriteAbortedException) to write len=16384: Write request aborted due to immediate session close These errors are repeated multiple times. The sum of bytes not written are equal to the chunk of data missing ad the target server. Can you troubleshoot this problem? Let me know if you need more info. Cheers Roberto -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (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&focusedCommentId=16653416#comment-16653416
]
Goldstein Lyor edited comment on SSHD-850 at 10/17/18 11:54 AM:
* {quote}
I know the two are different, and one (keyboard-interactive auth) is handled
fine by sshd. The other (passphrases for encrypted private keys) isn't.
{quote}
Then let's focus only on that - I am changing this issue to an appropriate
feature request.
I don't doubt that the functionality you describe is useful - however due to
lack of time/resources I doubt very much we will get to it (unless it becomes
popular). That being said, I do believe implementing your own
{{KeyPairProvider}} can be done much easier than you have described.
* {quote}
It even looks I'd have to implement a whole separate hierarchy of
KeyPairResourceParser
{quote}
I don't think it is necessary at all - the existing functionality can easily be
encapsulated/extended.
* {quote}
It also looks to me that I'd need a stateful FilePasswordProvider that
remembers if it had been called at all for the key so that I can query it – if
it hasn't even been called by the key parser, the key wasn't encrypted (or had
a problem before we even got to decrypting it) and re-trying would be futile.
{quote}
Indeed - hence the need to develop such a solution. However, the situation is
not as dire as it may seem - the {{FilePasswordProvider}} interface is invoked
with a "hint" (a.k.a. {{resourceKey}}) that tells you which resource is being
decoded.
If you are interested in pursuing this issue (and I encourage you to do so),
please implement it in the _sshd-contrib_ artifact and publish a PR for it - we
will be more than happy to incorporate into the project.
was (Author: lgoldstein):
* {quote}
I know the two are different, and one (keyboard-interactive auth) is handled
fine by sshd. The other (passphrases for encrypted private keys) isn't.
{quote}
Then let's focus only on that - I am changing this issue to an appropriate
feature request.
I don't doubt that the functionality you describe is useful - however due to
lack of time/resources I doubt very much we will get to it (unless it becomes
popular). That being said, I do believe implementing your own
{{KeyPairProvider}} can be done much easier than you have described.
* {quote}
It even looks I'd have to implement a whole separate hierarchy of
KeyPairResourceParser
{quote}
I don't think it is necessary at all - the existing functionality can easily be
encapsulated/extended.
* {quote}
It also looks to me that I'd need a stateful FilePasswordProvider that
remembers if it had been called at all for the key so that I can query it – if
it hasn't even been called by the key parser, the key wasn't encrypted (or had
a problem before we even got to decrypting it) and re-trying would be futile.
{quoted}
Indeed - hence the need to develop such a solution. However, the situation is
not as dire as it may seem - the {{FilePasswordProvider}} interface is invoked
with a "hint" (a.k.a. {{resourceKey}}) that tells you which resource is being
decoded.
If you are interested in pursuing this issue (and I encourage you to do so),
please implement it in the _sshd-contrib_ artifact and publish a PR for it - we
will be more than happy to incorporate into the project.
> 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.
--
T
[jira] [Updated] (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:all-tabpanel
]
Goldstein Lyor updated SSHD-850:
Summary: Add capability to retry a failed private key decryption when
client is decrypting private key file(s) (was: Add capability to interact with
the user when client is decrypting private key file(s))
> 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] [Updated] (SSHD-850) Add capability to interact with the user when decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-850:
Summary: Add capability to interact with the user when decrypting private
key file(s) (was: sshd client; encrypted private key identity file:
FilePasswordProvider called only once; should be called NumberOfPasswordPrompts
times)
> Add capability to interact with the user when decrypting private key file(s)
>
>
> Key: SSHD-850
> URL: https://issues.apache.org/jira/browse/SSHD-850
> Project: MINA SSHD
> Issue Type: Improvement
>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] [Updated] (SSHD-850) Add capability to interact with the user when client is decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-850:
Summary: Add capability to interact with the user when client is decrypting
private key file(s) (was: Add capability to interact with the user when
decrypting private key file(s))
> Add capability to interact with the user 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] [Updated] (SSHD-850) Add capability to interact with the user when decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-850:
Affects Version/s: 2.1.0
> Add capability to interact with the user when 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] [Updated] (SSHD-850) Add capability to interact with the user when decrypting private key file(s)
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor updated SSHD-850:
Issue Type: New Feature (was: Improvement)
> Add capability to interact with the user when 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] [Reopened] (SSHD-850) sshd client; encrypted private key identity file: FilePasswordProvider called only once; should be called NumberOfPasswordPrompts times
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goldstein Lyor reopened SSHD-850:
-
> sshd client; encrypted private key identity file: FilePasswordProvider called
> only once; should be called NumberOfPasswordPrompts times
> ---
>
> Key: SSHD-850
> URL: https://issues.apache.org/jira/browse/SSHD-850
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.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) sshd client; encrypted private key identity file: FilePasswordProvider called only once; should be called NumberOfPasswordPrompts times
[
https://issues.apache.org/jira/browse/SSHD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653416#comment-16653416
]
Goldstein Lyor commented on SSHD-850:
-
* {quote}
I know the two are different, and one (keyboard-interactive auth) is handled
fine by sshd. The other (passphrases for encrypted private keys) isn't.
{quote}
Then let's focus only on that - I am changing this issue to an appropriate
feature request.
I don't doubt that the functionality you describe is useful - however due to
lack of time/resources I doubt very much we will get to it (unless it becomes
popular). That being said, I do believe implementing your own
{{KeyPairProvider}} can be done much easier than you have described.
* {quote}
It even looks I'd have to implement a whole separate hierarchy of
KeyPairResourceParser
{quote}
I don't think it is necessary at all - the existing functionality can easily be
encapsulated/extended.
* {quote}
It also looks to me that I'd need a stateful FilePasswordProvider that
remembers if it had been called at all for the key so that I can query it – if
it hasn't even been called by the key parser, the key wasn't encrypted (or had
a problem before we even got to decrypting it) and re-trying would be futile.
{quoted}
Indeed - hence the need to develop such a solution. However, the situation is
not as dire as it may seem - the {{FilePasswordProvider}} interface is invoked
with a "hint" (a.k.a. {{resourceKey}}) that tells you which resource is being
decoded.
If you are interested in pursuing this issue (and I encourage you to do so),
please implement it in the _sshd-contrib_ artifact and publish a PR for it - we
will be more than happy to incorporate into the project.
> sshd client; encrypted private key identity file: FilePasswordProvider called
> only once; should be called NumberOfPasswordPrompts times
> ---
>
> Key: SSHD-850
> URL: https://issues.apache.org/jira/browse/SSHD-850
> Project: MINA SSHD
> Issue Type: Improvement
>Affects Versions: 2.0.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)
