[GitHub] [mina-sshd] 07070529 commented on pull request #362: [SSHD-1324] Rooted file system can leak informations
07070529 commented on PR #362: URL: https://github.com/apache/mina-sshd/pull/362#issuecomment-1664847859 Thanks a lot for your reply, and we appreciate your prompt attention to this issue. -- 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. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] gnodet commented on pull request #362: [SSHD-1324] Rooted file system can leak informations
gnodet commented on PR #362: URL: https://github.com/apache/mina-sshd/pull/362#issuecomment-1664219647 > We'd greatly appreciate it if you could give us some advice on whether the [CVE-2023-35887](https://github.com/advisories/GHSA-mjmq-gwgm-5qhm) vulnerability affects Apache MINA 2.1.X and 2.2.X? The issue affects the Apache Mina *SSHD* project, not the Apache Mina library. -- 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. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the exit status result, and
there is a dedicated property to adjust this timeout. Though, this is not
really a solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
Path based logging:
{code:java}
2023-08-02 14:17:50 DEBUG ScpHelper:597 -
sendStream(ScpHelper[ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]])[/Users/ryanlivingston/tmp/testfile.txt]
command='C0644 9 testfile.txt' ACK=0
2023-08-02 14:17:50 DEBUG ChannelExec:940 - sendEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF (state=Opened)
2023-08-02 14:17:50 DEBUG ClientSessionImpl:1402 -
encode(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) packet #11
sending command=96[SSH_MSG_CHANNEL_EOF] len=5
2023-08-02 14:17:50 DEBUG Nio2Session:179 -
writeBuffer(Nio2Session[local=/127.0.0.1:54429, remote=localhost/127.0.0.1:22])
writing 36 bytes
2023-08-02 14:17:50 DEBUG DefaultScpClient:155 -
runUpload(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
/Users/ryanlivingston/tmp/testfile2.txt =>
[/Users/ryanlivingston/tmp/testfile.txt] - failed
(UnsupportedOperationException) to close file
system=sun.nio.fs.MacOSXFileSystem@9ebe38b: null
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #16 SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ChannelExec:873 - handleEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #17 SSH_MSG_CHANNEL_REQUEST
2023-08-02 14:17:50 DEBUG ChannelExec:271 -
handleChannelRequest(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_REQUEST exit-status wantReply=false
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:50 -
processRequestValue(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) status=0
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:59 -
process(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
wantReply=false: 0
2023-08-02 14:17:50 DEBUG ChannelExec:114 - notifyEvent(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]):
exit-status
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:101 -
notifyStateChanged(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
event=exit-status
2023-08-02 14:17:50 DEBUG ChannelExec:345 - sendResponse(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
request=exit-status result=ReplySuccess, want-reply=false
2023-08-02 14:17:50 DEBUG ChannelExec:247 - waitFor(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
mask=[CLOSED, EXIT_STATUS] - exit status=0
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #18 SSH_MSG_CHANNEL_CLOSE
2023-08-02 14:17:50 DEBUG DefaultScpClient:176 -
handleCommandExitStatus(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
cmd='scp -t -- /Users/ryanlivingston/tmp/testfile2.txt', waited=636667 nanos,
events=[EOF, EXIT_STATUS, OPENED]
2023-08-02 14:17:50 DEBUG
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the exit status result, and
there is a dedicated property to adjust this timeout. Though, this is not
really a solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like {_}runUpload(){_}, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
Path based logging:
{code:java}
2023-08-02 14:17:50 DEBUG ScpHelper:597 -
sendStream(ScpHelper[ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]])[/Users/ryanlivingston/tmp/testfile.txt]
command='C0644 9 testfile.txt' ACK=0
2023-08-02 14:17:50 DEBUG ChannelExec:940 - sendEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF (state=Opened)
2023-08-02 14:17:50 DEBUG ClientSessionImpl:1402 -
encode(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) packet #11
sending command=96[SSH_MSG_CHANNEL_EOF] len=5
2023-08-02 14:17:50 DEBUG Nio2Session:179 -
writeBuffer(Nio2Session[local=/127.0.0.1:54429, remote=localhost/127.0.0.1:22])
writing 36 bytes
2023-08-02 14:17:50 DEBUG DefaultScpClient:155 -
runUpload(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
/Users/ryanlivingston/tmp/testfile2.txt =>
[/Users/ryanlivingston/tmp/testfile.txt] - failed
(UnsupportedOperationException) to close file
system=sun.nio.fs.MacOSXFileSystem@9ebe38b: null
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #16 SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ChannelExec:873 - handleEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #17 SSH_MSG_CHANNEL_REQUEST
2023-08-02 14:17:50 DEBUG ChannelExec:271 -
handleChannelRequest(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_REQUEST exit-status wantReply=false
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:50 -
processRequestValue(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) status=0
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:59 -
process(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
wantReply=false: 0
2023-08-02 14:17:50 DEBUG ChannelExec:114 - notifyEvent(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]):
exit-status
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:101 -
notifyStateChanged(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
event=exit-status
2023-08-02 14:17:50 DEBUG ChannelExec:345 - sendResponse(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
request=exit-status result=ReplySuccess, want-reply=false
2023-08-02 14:17:50 DEBUG ChannelExec:247 - waitFor(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
mask=[CLOSED, EXIT_STATUS] - exit status=0
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #18 SSH_MSG_CHANNEL_CLOSE
2023-08-02 14:17:50 DEBUG DefaultScpClient:176 -
handleCommandExitStatus(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
cmd='scp -t -- /Users/ryanlivingston/tmp/testfile2.txt', waited=636667 nanos,
events=[EOF, EXIT_STATUS, OPENED]
2023-08-02 14:17:50
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
Path based logging:
{code:java}
2023-08-02 14:17:50 DEBUG ScpHelper:597 -
sendStream(ScpHelper[ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]])[/Users/ryanlivingston/tmp/testfile.txt]
command='C0644 9 testfile.txt' ACK=0
2023-08-02 14:17:50 DEBUG ChannelExec:940 - sendEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF (state=Opened)
2023-08-02 14:17:50 DEBUG ClientSessionImpl:1402 -
encode(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) packet #11
sending command=96[SSH_MSG_CHANNEL_EOF] len=5
2023-08-02 14:17:50 DEBUG Nio2Session:179 -
writeBuffer(Nio2Session[local=/127.0.0.1:54429, remote=localhost/127.0.0.1:22])
writing 36 bytes
2023-08-02 14:17:50 DEBUG DefaultScpClient:155 -
runUpload(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
/Users/ryanlivingston/tmp/testfile2.txt =>
[/Users/ryanlivingston/tmp/testfile.txt] - failed
(UnsupportedOperationException) to close file
system=sun.nio.fs.MacOSXFileSystem@9ebe38b: null
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #16 SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ChannelExec:873 - handleEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #17 SSH_MSG_CHANNEL_REQUEST
2023-08-02 14:17:50 DEBUG ChannelExec:271 -
handleChannelRequest(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_REQUEST exit-status wantReply=false
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:50 -
processRequestValue(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) status=0
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:59 -
process(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
wantReply=false: 0
2023-08-02 14:17:50 DEBUG ChannelExec:114 - notifyEvent(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]):
exit-status
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:101 -
notifyStateChanged(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
event=exit-status
2023-08-02 14:17:50 DEBUG ChannelExec:345 - sendResponse(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
request=exit-status result=ReplySuccess, want-reply=false
2023-08-02 14:17:50 DEBUG ChannelExec:247 - waitFor(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
mask=[CLOSED, EXIT_STATUS] - exit status=0
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #18 SSH_MSG_CHANNEL_CLOSE
2023-08-02 14:17:50 DEBUG DefaultScpClient:176 -
handleCommandExitStatus(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
cmd='scp -t -- /Users/ryanlivingston/tmp/testfile2.txt', waited=636667 nanos,
events=[EOF, EXIT_STATUS, OPENED]
2023-08-02 14:17:50 DEBUG
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
Path based logging:
{code:java}
2023-08-02 14:17:50 DEBUG ScpHelper:597 -
sendStream(ScpHelper[ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]])[/Users/ryanlivingston/tmp/testfile.txt]
command='C0644 9 testfile.txt' ACK=0
2023-08-02 14:17:50 DEBUG ChannelExec:940 - sendEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF (state=Opened)
2023-08-02 14:17:50 DEBUG ClientSessionImpl:1402 -
encode(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) packet #11
sending command=96[SSH_MSG_CHANNEL_EOF] len=5
2023-08-02 14:17:50 DEBUG Nio2Session:179 -
writeBuffer(Nio2Session[local=/127.0.0.1:54429, remote=localhost/127.0.0.1:22])
writing 36 bytes
2023-08-02 14:17:50 DEBUG DefaultScpClient:155 -
runUpload(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
/Users/ryanlivingston/tmp/testfile2.txt =>
[/Users/ryanlivingston/tmp/testfile.txt] - failed
(UnsupportedOperationException) to close file
system=sun.nio.fs.MacOSXFileSystem@9ebe38b: null
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #16 SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ChannelExec:873 - handleEof(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_EOF
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #17 SSH_MSG_CHANNEL_REQUEST
2023-08-02 14:17:50 DEBUG ChannelExec:271 -
handleChannelRequest(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
SSH_MSG_CHANNEL_REQUEST exit-status wantReply=false
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:50 -
processRequestValue(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]) status=0
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:59 -
process(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
wantReply=false: 0
2023-08-02 14:17:50 DEBUG ChannelExec:114 - notifyEvent(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22]):
exit-status
2023-08-02 14:17:50 DEBUG ExitStatusChannelRequestHandler:101 -
notifyStateChanged(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])[exit-status]
event=exit-status
2023-08-02 14:17:50 DEBUG ChannelExec:345 - sendResponse(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
request=exit-status result=ReplySuccess, want-reply=false
2023-08-02 14:17:50 DEBUG ChannelExec:247 - waitFor(ChannelExec[id=0,
recipient=0]-ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
mask=[CLOSED, EXIT_STATUS] - exit status=0
2023-08-02 14:17:50 DEBUG ClientSessionImpl:544 -
doHandleMessage(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
process #18 SSH_MSG_CHANNEL_CLOSE
2023-08-02 14:17:50 DEBUG DefaultScpClient:176 -
handleCommandExitStatus(ClientSessionImpl[ryanlivingston@localhost/127.0.0.1:22])
cmd='scp -t -- /Users/ryanlivingston/tmp/testfile2.txt', waited=636667 nanos,
events=[EOF, EXIT_STATUS, OPENED]
2023-08-02 14:17:50 DEBUG
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the ```handleCommandExitStatus(cmd,
channel)``` is called before the In/Out channels are auto-closed by the
try-with-resources block, and thus the EOF is not sent to the remote prior to
handling the exit status. The current implementation always times out first and
then sends an EOF while closing the channels.
Using the API to send based on file paths will invoke
`DefaultScpClient::runUpload()` which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
was:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the `handleCommandExitStatus(cmd, channel)`
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
`DefaultScpClient::runUpload()` which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
> DefaultScpClient::upload(InputStream, ...) will always hit the exit status
> timeout
> --
>
> Key: SSHD-1334
> URL: https://issues.apache.org/jira/browse/SSHD-1334
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Ryan Livingston
>Priority: Major
> Attachments: file-based.txt, stream-based.txt
>
>
> When attempting to upload/scp a byte stream using the below method, the main
> thread will always block until the exit status timeout is reached.
> {code:java}
> DefaultScpClient::upload(InputStream local, String remote, long
> size,Collection perms, ScpTimestampCommandDetails
> time){code}
> It appears this is the case because the ```handleCommandExitStatus(cmd,
> channel)``` is called before the In/Out channels are auto-closed by the
> try-with-resources block, and thus the EOF is not sent to the remote prior to
> handling the exit status. The current implementation always times out first
> and then sends an EOF while closing the channels.
> Using the API to send based on file paths will invoke
> `DefaultScpClient::runUpload()` which first closes the channel resources and
> then waits for the exit status. This API works well without the exit status
> blocking the thread.
> I have overridden the default client to ignore the status exit, and there is
> a dedicated property to adjust this timeout. Though, this is not really a
> solution to this issue.
> I attempted to override and close the channels first prior to handling the
> exit status like `runUpload()`, but this introduced some async issues when
> processing some remaining inbound messages from the remote after the pipe is
> closed.
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Description:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the _handleCommandExitStatus(cmd, channel)_
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
_DefaultScpClient::runUpload()_ which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
was:
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the ```handleCommandExitStatus(cmd,
channel)``` is called before the In/Out channels are auto-closed by the
try-with-resources block, and thus the EOF is not sent to the remote prior to
handling the exit status. The current implementation always times out first and
then sends an EOF while closing the channels.
Using the API to send based on file paths will invoke
`DefaultScpClient::runUpload()` which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
> DefaultScpClient::upload(InputStream, ...) will always hit the exit status
> timeout
> --
>
> Key: SSHD-1334
> URL: https://issues.apache.org/jira/browse/SSHD-1334
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Ryan Livingston
>Priority: Major
> Attachments: file-based.txt, stream-based.txt
>
>
> When attempting to upload/scp a byte stream using the below method, the main
> thread will always block until the exit status timeout is reached.
> {code:java}
> DefaultScpClient::upload(InputStream local, String remote, long
> size,Collection perms, ScpTimestampCommandDetails
> time){code}
> It appears this is the case because the _handleCommandExitStatus(cmd,
> channel)_ is called before the In/Out channels are auto-closed by the
> try-with-resources block, and thus the EOF is not sent to the remote prior to
> handling the exit status. The current implementation always times out first
> and then sends an EOF while closing the channels.
> Using the API to send based on file paths will invoke
> _DefaultScpClient::runUpload()_ which first closes the channel resources and
> then waits for the exit status. This API works well without the exit status
> blocking the thread.
> I have overridden the default client to ignore the status exit, and there is
> a dedicated property to adjust this timeout. Though, this is not really a
> solution to this issue.
> I attempted to override and close the channels first prior to handling the
> exit status like `runUpload()`, but this introduced some async issues when
> processing some remaining inbound messages from the remote after the pipe is
> closed.
>
[jira] [Created] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
Ryan Livingston created SSHD-1334:
-
Summary: DefaultScpClient::upload(InputStream, ...) will always
hit the exit status timeout
Key: SSHD-1334
URL: https://issues.apache.org/jira/browse/SSHD-1334
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 2.10.0
Reporter: Ryan Livingston
Attachments: file-based.txt, stream-based.txt
When attempting to upload/scp a byte stream using the below method, the main
thread will always block until the exit status timeout is reached.
{code:java}
DefaultScpClient::upload(InputStream local, String remote, long
size,Collection perms, ScpTimestampCommandDetails
time){code}
It appears this is the case because the `handleCommandExitStatus(cmd, channel)`
is called before the In/Out channels are auto-closed by the try-with-resources
block, and thus the EOF is not sent to the remote prior to handling the exit
status. The current implementation always times out first and then sends an EOF
while closing the channels.
Using the API to send based on file paths will invoke
`DefaultScpClient::runUpload()` which first closes the channel resources and
then waits for the exit status. This API works well without the exit status
blocking the thread.
I have overridden the default client to ignore the status exit, and there is a
dedicated property to adjust this timeout. Though, this is not really a
solution to this issue.
I attempted to override and close the channels first prior to handling the exit
status like `runUpload()`, but this introduced some async issues when
processing some remaining inbound messages from the remote after the pipe is
closed.
This issue is persistent on remote SSH servers running with CentOS and MacOS.
This example is being run on MacOS 13.3.1 with a remote SSH server that has no
explicit SSH configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1334) DefaultScpClient::upload(InputStream, ...) will always hit the exit status timeout
[
https://issues.apache.org/jira/browse/SSHD-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Livingston updated SSHD-1334:
--
Attachment: file-based.txt
stream-based.txt
> DefaultScpClient::upload(InputStream, ...) will always hit the exit status
> timeout
> --
>
> Key: SSHD-1334
> URL: https://issues.apache.org/jira/browse/SSHD-1334
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Ryan Livingston
>Priority: Major
> Attachments: file-based.txt, stream-based.txt
>
>
> When attempting to upload/scp a byte stream using the below method, the main
> thread will always block until the exit status timeout is reached.
> {code:java}
> DefaultScpClient::upload(InputStream local, String remote, long
> size,Collection perms, ScpTimestampCommandDetails
> time){code}
> It appears this is the case because the `handleCommandExitStatus(cmd,
> channel)` is called before the In/Out channels are auto-closed by the
> try-with-resources block, and thus the EOF is not sent to the remote prior to
> handling the exit status. The current implementation always times out first
> and then sends an EOF while closing the channels.
> Using the API to send based on file paths will invoke
> `DefaultScpClient::runUpload()` which first closes the channel resources and
> then waits for the exit status. This API works well without the exit status
> blocking the thread.
> I have overridden the default client to ignore the status exit, and there is
> a dedicated property to adjust this timeout. Though, this is not really a
> solution to this issue.
> I attempted to override and close the channels first prior to handling the
> exit status like `runUpload()`, but this introduced some async issues when
> processing some remaining inbound messages from the remote after the pipe is
> closed.
> This issue is persistent on remote SSH servers running with CentOS and MacOS.
> This example is being run on MacOS 13.3.1 with a remote SSH server that has
> no explicit SSH configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] 07070529 commented on pull request #362: [SSHD-1324] Rooted file system can leak informations
07070529 commented on PR #362: URL: https://github.com/apache/mina-sshd/pull/362#issuecomment-1663958270 @gnodet Hi, we see from the NVD that this issue is related to vulnerability CVE-2023-35887 (https://nvd.nist.gov/vuln/detail/CVE-2023-35887).  Then in the content of the reference link (https://lists.apache.org/thread/b9qgtqvhnvgfpn0w1gz918p21p53tqk2), we see: This issue affects Apache MINA: from 1.0 before 2.10.  Sorry, we're a little confused: 1. The affected software scope is different with the title (Affected versions: Apache MINA SSHD 1.0 before 2.10). 2. We looked for a lot of information, including the Apache MINA community, but we didn't see any discussion about whether this issue affected the Apache MINA. We'd greatly appreciate it if you could give us some advice on whether the CVE-2023-35887 vulnerability affects Apache MINA? -- 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. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Gierke closed SSHD-1329.
---
Resolution: Not A Bug
Closing as this breaking change seems to be intentional behaviour.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] TRACE
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
>
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750651#comment-17750651
]
Tobias Gierke commented on SSHD-1329:
-
To answer my own question: One can simply do
{code:java}
sshClient.setHostConfigEntryResolver( (host, port, localAddress, username,
proxyJump, context) -> null ); {code}
to completely disable the ~/.ssh/config file.
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]) no
> initial request sent by
[jira] [Commented] (SSHD-1329) SSH Public key authentication works with 2.9.2 but fails with 2.10.0
[
https://issues.apache.org/jira/browse/SSHD-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750632#comment-17750632
]
Tobias Gierke commented on SSHD-1329:
-
I feel tempted to close this ticket as it seems the breakage observed by me
(introduced by
[https://github.com/apache/mina-sshd/commit/c11bfccaa39d5c89c3f3059f976dd1e4d0947cb6])
was done deliberately so nothing will be changed about it (which is fine with
me).
Is there a way to configure the client so that it completely ignores any local
~/.ssh/config file ? If yes, how to do so ?
> SSH Public key authentication works with 2.9.2 but fails with 2.10.0
>
>
> Key: SSHD-1329
> URL: https://issues.apache.org/jira/browse/SSHD-1329
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: failure_2.10.0.log, image-2023-06-26-17-10-43-547.png,
> image-2023-07-10-11-16-03-470.png, image-2023-07-10-11-31-54-206.png,
> image-2023-07-10-11-48-25-736.png, image-2023-07-10-11-54-05-391.png,
> image-2023-07-10-11-56-35-508.png, image-2023-07-10-12-04-00-532.png,
> image-2023-07-10-12-08-39-123.png, image-2023-07-10-12-12-02-825.png,
> image-2023-07-10-12-24-22-392.png, image-2023-07-10-12-25-51-220.png,
> image-2023-07-10-12-28-40-339.png, image-2023-07-10-12-38-23-160.png,
> image-2023-07-10-12-39-26-768.png, image-2023-07-10-12-40-44-093.png,
> image-2023-07-10-12-43-11-445.png, image-2023-07-10-12-53-51-624.png,
> image-2023-07-10-13-04-05-241.png, image-2023-07-10-13-06-17-767.png,
> image-2023-07-10-13-08-54-869.png, image-2023-07-10-13-12-39-566.png,
> image-2023-07-10-13-16-35-068.png, image-2023-07-10-13-19-06-606.png,
> image-2023-07-10-13-55-03-270.png, sshd-bug-test.tgz, success_2.9.2.log
>
>
> After upgrading to Apache SSHD 2.10.0 we noticed that SSH public key
> authentication stopped working.
> On 2.9.2 the handshake looks like this:
> {code:java}
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22]
> ) Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starti
> ng authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:12:18,405 [sshd-SshClient[1255b1d1]-nio2-thread-4|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:12:18,416 [sshd-SshClient[1255b1d1]-nio2-thread-4|] TRACE
> org.apache.sshd.common.config.keys.loader.pem.RSAPEMResourceKeyPairParser []
> - -BEGIN RSA PRIVATE KEY- [chunk #1](16/609)
> 30:82:02:5d:02:01:00:02:81:81:00:c1:a3:3a:25:23 0..].:%#
> . {code}
> while on 2.10.0 the key is not found/loaded:
> {code:java}
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl [] -
> doHandleMessage(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> process #5 SSH_MSG_USERAUTH_FAILURE
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> processUserAuth(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> Received SSH_MSG_USERAUTH_FAILURE - partial=false,
> methods=publickey,gssapi-keyex,gssapi-with-mic,password
> 2023-06-19T13:13:41,529 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> starting authentication mechanisms: client=[publickey, keyboard-interactive,
> password], server=[publickey, gssapi-keyex, gssapi-with-mic, password]
> 2023-06-19T13:13:41,530 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.session.ClientUserAuthService [] -
> tryNext(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])
> attempting method=publickey
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|] DEBUG
> org.apache.sshd.client.auth.pubkey.UserAuthPublicKey [] -
> resolveAttemptedPublicKeyIdentity(ClientSessionImpl[r...@vmtobilocal.fritz.box/192.168.188.250:22])[ssh-connection]
> no more keys to send
> 2023-06-19T13:13:41,532 [sshd-SshClient[495083a0]-nio2-thread-6|]
