[jira] [Work logged] (SSHD-901) InterruptedByTimeoutException occurring in client despite keepalive global request being sent

2020-04-04 Thread ASF GitHub Bot (Jira) 


 [ 
https://issues.apache.org/jira/browse/SSHD-901?focusedWorklogId=416143&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-416143
 ]

ASF GitHub Bot logged work on SSHD-901:
---

Author: ASF GitHub Bot
Created on: 05/Apr/20 06:39
Start Date: 05/Apr/20 06:39
Worklog Time Spent: 10m 
  Work Description: lgoldstein commented on issue #95: SSHD-901 Provide 
'wantReply' option for client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609367159
 
 
   >> Don't you openSSH internally for SSHD? 
   
   MINA SSHD is a **pure Java** implementation - there is no _openSSH_ native 
code in it.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 416143)
Time Spent: 1h 20m  (was: 1h 10m)

> InterruptedByTimeoutException occurring in client despite keepalive global 
> request being sent
> -
>
> Key: SSHD-901
> URL: https://issues.apache.org/jira/browse/SSHD-901
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
> Environment: Windows 10
>Reporter: Jared Wiltshire
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> This may be related to SSHD-891 but I couldn't follow that issue exactly.
> I was noticed that after exactly 10 minutes and 15 minutes a 
> java.nio.channels.InterruptedByTimeoutException exception was being thrown by 
> the client. After a little digging I discovered that this is the default 
> value for NIO2_READ_TIMEOUT. This is the stack trace -
> {code:java}
> ERROR 2019-02-25T17:25:16,879 
> (com.infiniteautomation.mango.cloudConnect.client.CloudConnectClient$ClientSessionListener.sessionException:83)
>  - Session exception, session 
> ClientSessionImpl[mango@localhost/127.0.0.1:9005] 
> java.nio.channels.InterruptedByTimeoutException: null
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$ReadTask.timeout(WindowsAsynchronousSocketChannelImpl.java:614)
>  ~[?:1.8.0_144]
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$2.run(WindowsAsynchronousSocketChannelImpl.java:649)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[?:1.8.0_144]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  ~[?:1.8.0_144]
>   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> {code}
> Now I have the heat beat interval (ClientFactoryManager.HEARTBEAT_INTERVAL) 
> property set to less than 10 minutes and I verified that the global request 
> is indeed being sent and received by the server.
> However I think that the issue is that the global request is sent with 
> wantReply set to false. So the server does not reply with anything and the 
> client does not read any data from the socket and hence times out.
> Does it not make sense for the server to reply? I believe this is a self 
> defined global request (not in the SSH RFC) so we should be able change its 
> behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[GitHub] [mina-sshd] lgoldstein commented on issue #95: SSHD-901 Provide 'wantReply' option for client keep-alive heartbeat global request

2020-04-04 Thread GitBox 
lgoldstein commented on issue #95: SSHD-901 Provide 'wantReply' option for 
client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609367159
 
 
   >> Don't you openSSH internally for SSHD? 
   
   MINA SSHD is a **pure Java** implementation - there is no _openSSH_ native 
code in it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[GitHub] [mina-sshd] Arunapotti commented on issue #95: SSHD-901 Provide 'wantReply' option for client keep-alive heartbeat global request

2020-04-04 Thread GitBox 
Arunapotti commented on issue #95: SSHD-901 Provide 'wantReply' option for 
client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609096163
 
 
   [image: image.png]
   Don't you openSSH internally for SSHD? If you do, then I assume there
   should be a way to use openSSH supported "ClinetAliveInterval" through your
   SSHD.
   
   
   
   On Sat, Apr 4, 2020 at 9:07 AM Lyor Goldstein 
   wrote:
   
   > This seems like the idle timeout I mentioned - although I don't know how
   > they
   >
   > send a message through the encrypted channel to request a response from
   > the client.
   >
   > I am looking for an equivalent option with your SSHD.
   >
   > See my response regarding usage of SSH_MSG_IGNORE
   >
   > —
   > You are receiving this because you commented.
   > Reply to this email directly, view it on GitHub
   > , or
   > unsubscribe
   > 

   > .
   >
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Work logged] (SSHD-901) InterruptedByTimeoutException occurring in client despite keepalive global request being sent

2020-04-04 Thread ASF GitHub Bot (Jira) 


 [ 
https://issues.apache.org/jira/browse/SSHD-901?focusedWorklogId=416055&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-416055
 ]

ASF GitHub Bot logged work on SSHD-901:
---

Author: ASF GitHub Bot
Created on: 04/Apr/20 22:14
Start Date: 04/Apr/20 22:14
Worklog Time Spent: 10m 
  Work Description: Arunapotti commented on issue #95: SSHD-901 Provide 
'wantReply' option for client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609096163
 
 
   [image: image.png]
   Don't you openSSH internally for SSHD? If you do, then I assume there
   should be a way to use openSSH supported "ClinetAliveInterval" through your
   SSHD.
   
   
   
   On Sat, Apr 4, 2020 at 9:07 AM Lyor Goldstein 
   wrote:
   
   > This seems like the idle timeout I mentioned - although I don't know how
   > they
   >
   > send a message through the encrypted channel to request a response from
   > the client.
   >
   > I am looking for an equivalent option with your SSHD.
   >
   > See my response regarding usage of SSH_MSG_IGNORE
   >
   > —
   > You are receiving this because you commented.
   > Reply to this email directly, view it on GitHub
   > , or
   > unsubscribe
   > 

   > .
   >
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 416055)
Time Spent: 1h 10m  (was: 1h)

> InterruptedByTimeoutException occurring in client despite keepalive global 
> request being sent
> -
>
> Key: SSHD-901
> URL: https://issues.apache.org/jira/browse/SSHD-901
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
> Environment: Windows 10
>Reporter: Jared Wiltshire
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> This may be related to SSHD-891 but I couldn't follow that issue exactly.
> I was noticed that after exactly 10 minutes and 15 minutes a 
> java.nio.channels.InterruptedByTimeoutException exception was being thrown by 
> the client. After a little digging I discovered that this is the default 
> value for NIO2_READ_TIMEOUT. This is the stack trace -
> {code:java}
> ERROR 2019-02-25T17:25:16,879 
> (com.infiniteautomation.mango.cloudConnect.client.CloudConnectClient$ClientSessionListener.sessionException:83)
>  - Session exception, session 
> ClientSessionImpl[mango@localhost/127.0.0.1:9005] 
> java.nio.channels.InterruptedByTimeoutException: null
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$ReadTask.timeout(WindowsAsynchronousSocketChannelImpl.java:614)
>  ~[?:1.8.0_144]
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$2.run(WindowsAsynchronousSocketChannelImpl.java:649)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[?:1.8.0_144]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  ~[?:1.8.0_144]
>   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> {code}
> Now I have the heat beat interval (ClientFactoryManager.HEARTBEAT_INTERVAL) 
> property set to less than 10 minutes and I verified that the global request 
> is indeed being sent and received by the server.
> However I think that the issue is that the global request is sent with 
> wantReply set to false. So the server does not reply with anything and the 
> client does not read any data from the socket and hence times out.
> Does it not make sense for the server to reply? I believe this is a self 
> defined global request (not in the SSH RFC) so we should be able change its 
> behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---

[GitHub] [mina-sshd] lgoldstein commented on issue #95: SSHD-901 Provide 'wantReply' option for client keep-alive heartbeat global request

2020-04-04 Thread GitBox 
lgoldstein commented on issue #95: SSHD-901 Provide 'wantReply' option for 
client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609050783
 
 
   This seems like the idle timeout I mentioned - although I  don't know how 
they
   >> send a message through the encrypted channel to request a response from 
the client.
   
   
   >> I am looking for an equivalent option with your SSHD.
   
   See my response regarding usage of `SSH_MSG_IGNORE`
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Work logged] (SSHD-901) InterruptedByTimeoutException occurring in client despite keepalive global request being sent

2020-04-04 Thread ASF GitHub Bot (Jira) 


 [ 
https://issues.apache.org/jira/browse/SSHD-901?focusedWorklogId=415984&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-415984
 ]

ASF GitHub Bot logged work on SSHD-901:
---

Author: ASF GitHub Bot
Created on: 04/Apr/20 16:07
Start Date: 04/Apr/20 16:07
Worklog Time Spent: 10m 
  Work Description: lgoldstein commented on issue #95: SSHD-901 Provide 
'wantReply' option for client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609050783
 
 
   This seems like the idle timeout I mentioned - although I  don't know how 
they
   >> send a message through the encrypted channel to request a response from 
the client.
   
   
   >> I am looking for an equivalent option with your SSHD.
   
   See my response regarding usage of `SSH_MSG_IGNORE`
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 415984)
Time Spent: 1h  (was: 50m)

> InterruptedByTimeoutException occurring in client despite keepalive global 
> request being sent
> -
>
> Key: SSHD-901
> URL: https://issues.apache.org/jira/browse/SSHD-901
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
> Environment: Windows 10
>Reporter: Jared Wiltshire
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This may be related to SSHD-891 but I couldn't follow that issue exactly.
> I was noticed that after exactly 10 minutes and 15 minutes a 
> java.nio.channels.InterruptedByTimeoutException exception was being thrown by 
> the client. After a little digging I discovered that this is the default 
> value for NIO2_READ_TIMEOUT. This is the stack trace -
> {code:java}
> ERROR 2019-02-25T17:25:16,879 
> (com.infiniteautomation.mango.cloudConnect.client.CloudConnectClient$ClientSessionListener.sessionException:83)
>  - Session exception, session 
> ClientSessionImpl[mango@localhost/127.0.0.1:9005] 
> java.nio.channels.InterruptedByTimeoutException: null
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$ReadTask.timeout(WindowsAsynchronousSocketChannelImpl.java:614)
>  ~[?:1.8.0_144]
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$2.run(WindowsAsynchronousSocketChannelImpl.java:649)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[?:1.8.0_144]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  ~[?:1.8.0_144]
>   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> {code}
> Now I have the heat beat interval (ClientFactoryManager.HEARTBEAT_INTERVAL) 
> property set to less than 10 minutes and I verified that the global request 
> is indeed being sent and received by the server.
> However I think that the issue is that the global request is sent with 
> wantReply set to false. So the server does not reply with anything and the 
> client does not read any data from the socket and hence times out.
> Does it not make sense for the server to reply? I believe this is a self 
> defined global request (not in the SSH RFC) so we should be able change its 
> behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Work logged] (SSHD-901) InterruptedByTimeoutException occurring in client despite keepalive global request being sent

2020-04-04 Thread ASF GitHub Bot (Jira) 


 [ 
https://issues.apache.org/jira/browse/SSHD-901?focusedWorklogId=415983&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-415983
 ]

ASF GitHub Bot logged work on SSHD-901:
---

Author: ASF GitHub Bot
Created on: 04/Apr/20 15:54
Start Date: 04/Apr/20 15:54
Worklog Time Spent: 10m 
  Work Description: Arunapotti commented on issue #95: SSHD-901 Provide 
'wantReply' option for client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609048804
 
 
   Hi Goldstein,
   
   OpenSSH has ClinetAliveInterval support that the servers can use to detect
   and clean up dead/dangling clients besides for the keep-alive support.
   
   ClientAliveInterval 
   Sets a timeout interval in seconds after which if no data has been received
   from the client, sshd(8) will send a message
   through the encrypted channel to request a response from the client. The
   default is 0, indicating that these messages will not be sent to the client.
   
   I am looking for an equivalent option with your SSHD.
   
   Thanks
   
   On Sat, Apr 4, 2020 at 8:02 AM Lyor Goldstein 
   wrote:
   
   > to close any dangling client sessions from server due to network issues
   >
   > Please bear in mind that this mechanism is a *client side* one - i.e., it
   > is used by the client in order to detect a non-responsive server sooner
   > than the regular TCP/IP timeout would. AFAIK there is no server side
   > mechanism to detect "dangling" client sessions. We do have an idle-timeout
   > mechanism that closes a session if there is no traffic for the specified
   > amount of time (current default=10 minutes). The purpose of the keepalive@
   > mechanism (besides early detection) is also to generate some traffic so
   > that the client does not time out if there is no traffic. By activating the
   > wantReply option (default=disabled) we try to ensure that the server does
   > not time out due to no traffic. Therefore, the keepalive@ mechanism is
   > not likely to detect "dangling clients" on the server side.
   >
   > See
   > 
https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#keeping-the-session-alive-while-no-traffic
   > on client heartbeat details, and the code for SessionHelper#getIdleTimeout
   >
   > There is a way to do this on the server side but it is rather
   > *non-standard* (which we support) and it involves sending
   > {{SSH_MSG_IGNORE}} messages from the server to the client thus maintaining
   > some traffic on the session as well as detecting "dangling clients". See
   > setSessionHeartbeat API with a {{HeartbeatType}} of IGNORE.
   >
   > —
   > You are receiving this because you commented.
   > Reply to this email directly, view it on GitHub
   > , or
   > unsubscribe
   > 

   > .
   >
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 415983)
Time Spent: 50m  (was: 40m)

> InterruptedByTimeoutException occurring in client despite keepalive global 
> request being sent
> -
>
> Key: SSHD-901
> URL: https://issues.apache.org/jira/browse/SSHD-901
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
> Environment: Windows 10
>Reporter: Jared Wiltshire
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> This may be related to SSHD-891 but I couldn't follow that issue exactly.
> I was noticed that after exactly 10 minutes and 15 minutes a 
> java.nio.channels.InterruptedByTimeoutException exception was being thrown by 
> the client. After a little digging I discovered that this is the default 
> value for NIO2_READ_TIMEOUT. This is the stack trace -
> {code:java}
> ERROR 2019-02-25T17:25:16,879 
> (com.infiniteautomation.mango.cloudConnect.client.CloudConnectClient$ClientSessionListener.sessionException:83)
>  - Session exception, session 
> ClientSessionImpl[mango@localhost/127.0.0.1:9005] 
> java.nio.channels.InterruptedByTimeoutException: null
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$ReadTask.timeout(WindowsAsynchronousSocketChannelImpl.java:614)
>  ~[?:1.8.0

[GitHub] [mina-sshd] Arunapotti commented on issue #95: SSHD-901 Provide 'wantReply' option for client keep-alive heartbeat global request

2020-04-04 Thread GitBox 
Arunapotti commented on issue #95: SSHD-901 Provide 'wantReply' option for 
client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609048804
 
 
   Hi Goldstein,
   
   OpenSSH has ClinetAliveInterval support that the servers can use to detect
   and clean up dead/dangling clients besides for the keep-alive support.
   
   ClientAliveInterval 
   Sets a timeout interval in seconds after which if no data has been received
   from the client, sshd(8) will send a message
   through the encrypted channel to request a response from the client. The
   default is 0, indicating that these messages will not be sent to the client.
   
   I am looking for an equivalent option with your SSHD.
   
   Thanks
   
   On Sat, Apr 4, 2020 at 8:02 AM Lyor Goldstein 
   wrote:
   
   > to close any dangling client sessions from server due to network issues
   >
   > Please bear in mind that this mechanism is a *client side* one - i.e., it
   > is used by the client in order to detect a non-responsive server sooner
   > than the regular TCP/IP timeout would. AFAIK there is no server side
   > mechanism to detect "dangling" client sessions. We do have an idle-timeout
   > mechanism that closes a session if there is no traffic for the specified
   > amount of time (current default=10 minutes). The purpose of the keepalive@
   > mechanism (besides early detection) is also to generate some traffic so
   > that the client does not time out if there is no traffic. By activating the
   > wantReply option (default=disabled) we try to ensure that the server does
   > not time out due to no traffic. Therefore, the keepalive@ mechanism is
   > not likely to detect "dangling clients" on the server side.
   >
   > See
   > 
https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#keeping-the-session-alive-while-no-traffic
   > on client heartbeat details, and the code for SessionHelper#getIdleTimeout
   >
   > There is a way to do this on the server side but it is rather
   > *non-standard* (which we support) and it involves sending
   > {{SSH_MSG_IGNORE}} messages from the server to the client thus maintaining
   > some traffic on the session as well as detecting "dangling clients". See
   > setSessionHeartbeat API with a {{HeartbeatType}} of IGNORE.
   >
   > —
   > You are receiving this because you commented.
   > Reply to this email directly, view it on GitHub
   > , or
   > unsubscribe
   > 

   > .
   >
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (SSHD-660) Add support for authentication using signed client/server keys

2020-04-04 Thread Lyor Goldstein (Jira) 


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

Lyor Goldstein commented on SSHD-660:
-

The link you provided adds some information, but it is not the main problem. 
The issue here is that I expect implementing the feature would require a 
significant amount of time - something we are very short of. Therefore, we try 
and invest the little time we have on bug fixes and widely used features - this 
does not seem to be one. Furthermore, even if we had the time, we still need a 
client/server that also also support this feature so we can check for 
interoperability - something I have not been able to find. Therefore, 
unfortunately I don't see us getting around to it any time soon (unless it 
suddenly becomes in high demand).

That being said, we always welcome contributions - so if you would like to 
undertake to implement this feature I would be happy to assist with advice and 
pointers for issues you may encounter.

> Add support for authentication using signed client/server keys
> --
>
> Key: SSHD-660
> URL: https://issues.apache.org/jira/browse/SSHD-660
> Project: MINA SSHD
>  Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Minor
>
> Similar to _HostCertificate_ and _TrustedUserCAKeys_ configuration values - 
> see https://ef.gy/hardening-ssh



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Work logged] (SSHD-901) InterruptedByTimeoutException occurring in client despite keepalive global request being sent

2020-04-04 Thread ASF GitHub Bot (Jira) 


 [ 
https://issues.apache.org/jira/browse/SSHD-901?focusedWorklogId=415978&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-415978
 ]

ASF GitHub Bot logged work on SSHD-901:
---

Author: ASF GitHub Bot
Created on: 04/Apr/20 15:02
Start Date: 04/Apr/20 15:02
Worklog Time Spent: 10m 
  Work Description: lgoldstein commented on issue #95: SSHD-901 Provide 
'wantReply' option for client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609041673
 
 
   >> to close any dangling client sessions from server due to network issues
   
   Please bear in mind that this mechanism is a **client side** one - i.e., it 
is used by the client in order to detect a non-responsive server sooner than 
the regular TCP/IP timeout would. AFAIK there is no server side mechanism to 
detect "dangling" client sessions. We do have an idle-timeout mechanism that 
closes a session if there is no traffic for the specified amount of time 
(current default=10 minutes). The purpose of the `keepalive@` mechanism 
(besides early detection) is also to generate some traffic so that the client 
does not time out if there is no traffic. By activating the `wantReply` option 
(default=disabled) we try to ensure that the server does not time out due to no 
traffic. Therefore, the `keepalive@` mechanism is not likely to detect 
"dangling clients" on the server side.
   
   See 
https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#keeping-the-session-alive-while-no-traffic
 on client heartbeat details, and the code for `SessionHelper#getIdleTimeout`
   
   There is a way to do this on the server side but it is rather 
**non-standard** (which we support) and it involves sending {{SSH_MSG_IGNORE}} 
messages from the server to the client thus maintaining some traffic on the 
session as well as detecting "dangling clients". See `setSessionHeartbeat` API 
with a {{HeartbeatType}} of `IGNORE`.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 415978)
Time Spent: 40m  (was: 0.5h)

> InterruptedByTimeoutException occurring in client despite keepalive global 
> request being sent
> -
>
> Key: SSHD-901
> URL: https://issues.apache.org/jira/browse/SSHD-901
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
> Environment: Windows 10
>Reporter: Jared Wiltshire
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This may be related to SSHD-891 but I couldn't follow that issue exactly.
> I was noticed that after exactly 10 minutes and 15 minutes a 
> java.nio.channels.InterruptedByTimeoutException exception was being thrown by 
> the client. After a little digging I discovered that this is the default 
> value for NIO2_READ_TIMEOUT. This is the stack trace -
> {code:java}
> ERROR 2019-02-25T17:25:16,879 
> (com.infiniteautomation.mango.cloudConnect.client.CloudConnectClient$ClientSessionListener.sessionException:83)
>  - Session exception, session 
> ClientSessionImpl[mango@localhost/127.0.0.1:9005] 
> java.nio.channels.InterruptedByTimeoutException: null
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$ReadTask.timeout(WindowsAsynchronousSocketChannelImpl.java:614)
>  ~[?:1.8.0_144]
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$2.run(WindowsAsynchronousSocketChannelImpl.java:649)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[?:1.8.0_144]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  ~[?:1.8.0_144]
>   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> {code}
> Now I have the heat beat interval (ClientFactoryManager.HEARTBEAT_INTERVAL) 
> property set to less than 10 minutes and I verified that the global request 
> is indeed being sent a

[GitHub] [mina-sshd] lgoldstein commented on issue #95: SSHD-901 Provide 'wantReply' option for client keep-alive heartbeat global request

2020-04-04 Thread GitBox 
lgoldstein commented on issue #95: SSHD-901 Provide 'wantReply' option for 
client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609041673
 
 
   >> to close any dangling client sessions from server due to network issues
   
   Please bear in mind that this mechanism is a **client side** one - i.e., it 
is used by the client in order to detect a non-responsive server sooner than 
the regular TCP/IP timeout would. AFAIK there is no server side mechanism to 
detect "dangling" client sessions. We do have an idle-timeout mechanism that 
closes a session if there is no traffic for the specified amount of time 
(current default=10 minutes). The purpose of the `keepalive@` mechanism 
(besides early detection) is also to generate some traffic so that the client 
does not time out if there is no traffic. By activating the `wantReply` option 
(default=disabled) we try to ensure that the server does not time out due to no 
traffic. Therefore, the `keepalive@` mechanism is not likely to detect 
"dangling clients" on the server side.
   
   See 
https://github.com/apache/mina-sshd/blob/master/docs/client-setup.md#keeping-the-session-alive-while-no-traffic
 on client heartbeat details, and the code for `SessionHelper#getIdleTimeout`
   
   There is a way to do this on the server side but it is rather 
**non-standard** (which we support) and it involves sending {{SSH_MSG_IGNORE}} 
messages from the server to the client thus maintaining some traffic on the 
session as well as detecting "dangling clients". See `setSessionHeartbeat` API 
with a {{HeartbeatType}} of `IGNORE`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[GitHub] [mina-sshd] Arunapotti commented on issue #95: SSHD-901 Provide 'wantReply' option for client keep-alive heartbeat global request

2020-04-04 Thread GitBox 
Arunapotti commented on issue #95: SSHD-901 Provide 'wantReply' option for 
client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609023828
 
 
   If I am using MINA SSHD and I want to use keepalive@... with wantReply  to 
close any dangling client sessions from server due to network issues, do you 
support this mechanism?
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Work logged] (SSHD-901) InterruptedByTimeoutException occurring in client despite keepalive global request being sent

2020-04-04 Thread ASF GitHub Bot (Jira) 


 [ 
https://issues.apache.org/jira/browse/SSHD-901?focusedWorklogId=415960&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-415960
 ]

ASF GitHub Bot logged work on SSHD-901:
---

Author: ASF GitHub Bot
Created on: 04/Apr/20 12:49
Start Date: 04/Apr/20 12:49
Worklog Time Spent: 10m 
  Work Description: Arunapotti commented on issue #95: SSHD-901 Provide 
'wantReply' option for client keep-alive heartbeat global request
URL: https://github.com/apache/mina-sshd/pull/95#issuecomment-609023828
 
 
   If I am using MINA SSHD and I want to use keepalive@... with wantReply  to 
close any dangling client sessions from server due to network issues, do you 
support this mechanism?
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 415960)
Time Spent: 0.5h  (was: 20m)

> InterruptedByTimeoutException occurring in client despite keepalive global 
> request being sent
> -
>
> Key: SSHD-901
> URL: https://issues.apache.org/jira/browse/SSHD-901
> Project: MINA SSHD
>  Issue Type: Bug
>Affects Versions: 2.2.0
> Environment: Windows 10
>Reporter: Jared Wiltshire
>Assignee: Lyor Goldstein
>Priority: Major
> Fix For: 2.3.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This may be related to SSHD-891 but I couldn't follow that issue exactly.
> I was noticed that after exactly 10 minutes and 15 minutes a 
> java.nio.channels.InterruptedByTimeoutException exception was being thrown by 
> the client. After a little digging I discovered that this is the default 
> value for NIO2_READ_TIMEOUT. This is the stack trace -
> {code:java}
> ERROR 2019-02-25T17:25:16,879 
> (com.infiniteautomation.mango.cloudConnect.client.CloudConnectClient$ClientSessionListener.sessionException:83)
>  - Session exception, session 
> ClientSessionImpl[mango@localhost/127.0.0.1:9005] 
> java.nio.channels.InterruptedByTimeoutException: null
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$ReadTask.timeout(WindowsAsynchronousSocketChannelImpl.java:614)
>  ~[?:1.8.0_144]
>   at 
> sun.nio.ch.WindowsAsynchronousSocketChannelImpl$2.run(WindowsAsynchronousSocketChannelImpl.java:649)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[?:1.8.0_144]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[?:1.8.0_144]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  ~[?:1.8.0_144]
>   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_144]
> {code}
> Now I have the heat beat interval (ClientFactoryManager.HEARTBEAT_INTERVAL) 
> property set to less than 10 minutes and I verified that the global request 
> is indeed being sent and received by the server.
> However I think that the issue is that the global request is sent with 
> wantReply set to false. So the server does not reply with anything and the 
> client does not read any data from the socket and hence times out.
> Does it not make sense for the server to reply? I believe this is a self 
> defined global request (not in the SSH RFC) so we should be able change its 
> behavior.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[jira] [Commented] (SSHD-660) Add support for authentication using signed client/server keys

2020-04-04 Thread FliegenKLATSCH (Jira) 


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

FliegenKLATSCH commented on SSHD-660:
-

My question (and the linked doc as well I believe) was about support for host 
key verification via 
[ssh-ed25519-cert-...@openssh.com|mailto:ssh-ed25519-cert-...@openssh.com] see 
[https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.certkeys]

> Add support for authentication using signed client/server keys
> --
>
> Key: SSHD-660
> URL: https://issues.apache.org/jira/browse/SSHD-660
> Project: MINA SSHD
>  Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Minor
>
> Similar to _HostCertificate_ and _TrustedUserCAKeys_ configuration values - 
> see https://ef.gy/hardening-ssh



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org