[jira] [Commented] (SSHD-108) Add upload monitoring to sftp

[Goldstein Lyor (JIRA)]

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

Goldstein Lyor commented on SSHD-108:
-

As previously explained, there is no standard way the server can detect an 
"abort" from the client. If the client simply stops reading then it is 
indistinguishable from an "abort" (at least until the connection is broken). 
That being said, using a registered {{SftpEventListener}} in conjunction with a 
{{SessionListener}} enables *tracking* I/O operations on files (including 
read/write) and with some smart coding one could detect the fact that a file 
has been closed before it was fully read. The tracking code is not trivial, but 
possible by using these listeners.

Specifically have a look at the following {{SftpEventListener}} methods which I 
believe I would use if I were to implement such a feature:

* {{initialized}} - initialize the tracking mechanism for the session
* {{destroying}} - see which files are incomplete
* {{open}}, {{read}}, {{reading}} - track the reading process (make sure you 
are tracking only *files* since {{open}} is also called for directories)
* {{close}} - see if entire file has been read

BTW, if indeed you are able to implement it, please consider contributing the 
code the project via a pull request - preferably under the _sshd-contrib_ 
artifact.

P.S. in version 1.3 (soon to be released) the listener API has been augmented 
to include more information and facilitate even further this functionality.

> Add upload monitoring to sftp
> -
>
> Key: SSHD-108
> URL: https://issues.apache.org/jira/browse/SSHD-108
> Project: MINA SSHD
>  Issue Type: Improvement
>Affects Versions: 0.5.0
>Reporter: Richard Evans
>Assignee: Goldstein Lyor
>Priority: Minor
> Fix For: 1.1.0
>
>
> We have sshd integrated into our application and sftp is working fine.  One 
> of the requirements is to initiate some action when a file upload it 
> complete.  I have made this work by implementing handleClose in my SshFile 
> implementation and performing the action if createOutputStream had been 
> called previously.  This seems a bit ugly though; it might be nicer if there 
> was some plug in mechanism to monitor file transfers.
> Ideally the monitor would be able to distinguish between a successful upload 
> and a cancelled one (via ctrl-c at the client), but a quick perusal of the 
> sftp stuff seems to inidicate that this is not possible. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release SSHD 1.3.0

[Emmanuel Lécharny]

Le 19/09/16 à 09:27, Guillaume Nodet a écrit :
> I've prepared a candidate for SSHD 1.3.0 release at
>   https://repository.apache.org/content/repositories/orgapachemina-1024

Both tag and packages built, signature tested, N files checked : my +1

RE: [VOTE] Release SSHD 1.3.0

[Matthew.W.Pitts]

+1... as a bug reporter and user, if that counts

-Original Message-
From: Guillaume Nodet [mailto:gno...@apache.org]
Sent: Monday, September 19, 2016 3:28 AM
To: dev@mina.apache.org
Subject: [VOTE] Release SSHD 1.3.0

I've prepared a candidate for SSHD 1.3.0 release at
  https://repository.apache.org/content/repositories/orgapachemina-1024

Please review and vote.

Release
notes:
** Bug
* [SSHD-605] - VirtualFileSystemFactory allows escaping from root
* [SSHD-651] - Add an option to specify read/write Nio2 socket timeouts
* [SSHD-663] - Wrong if criteria in
org.apache.sshd.common.file.util.ImmutableList.subList()
* [SSHD-667] - RootedFileSystemProvider throws
ProviderMismatchException when calling newByteChannel
* [SSHD-668] - AccessControlException running under OSGi container
* [SSHD-671] - Internal hang (timeout) using ScpClient.upload()
* [SSHD-673] - "sendKexInit() no resolved signatures available" with
key-type "EC"
* [SSHD-692] - Cannot repeatedly call
ChannelSession#executeRemoteCommand
* [SSHD-695] - Client - support receiving of banner prior to auth()

** Improvement
* [SSHD-664] - Provide ReadOnly option in RootedFileSystemProvider
(sshd-core)
* [SSHD-665] - allow disable some features in SftpSubsystem (sshd-core)
* [SSHD-674] - Update minimum required Java version to 1.8
* [SSHD-675] - Provide default implementations for overloaded
configuration methods on Client/ServerFactoryManager interfaces
* [SSHD-676] - Provide command line option for specifying client/server
key file(s)
* [SSHD-677] - Provide a quick default implementation for executing a
single simple command that does not require any input
* [SSHD-679] - Support (or ignore) IUTF8 terminal mode (42)
* [SSHD-680] - Provide default implementations for
ClientAuthenticationManager#getSetUserAuthFactories overloading with strings
* [SSHD-681] - Provide default implementations for
ServerAuthenticationManager#getSetUserAuthFactories overloading with strings
* [SSHD-682] - Provide PortForwardingEventListener support
* [SSHD-683] - Provide an auto-closeable implementation for
establishing and tearing down local/remote port forwards
* [SSHD-684] - Move checkstyle definitions to external file so it can
be imported by the IDE
* [SSHD-686] - Provide configurable option to auto-generate welcome
banner consisting of the server's keys random art values
* [SSHD-687] - Provide indication of the negotiated options before
processing them
* [SSHD-688] - Attempt to send the welcome banner sooner in the
authentication protocol
* [SSHD-689] - Allow providing a file as a welcome banner configuration
option
* [SSHD-690] - Use by default the standard file(s) for SSH server
welcome banner
* [SSHD-691] - Attempt to create server instance only once per test as
much as possible
* [SSHD-694] - Provide README.md file(s) with useful code snippets
* [SSHD-696] - Allow loading the server's welcome banner from a URL
* [SSHD-697] - Add read/write methods to SftpClient that enable
read/write starting from some offset
* [SSHD-699] - Server receiving 0-length SSH_MSG_IGNORE causes Buffer
Underflow exception

** New Feature
* [SSHD-685] - Provide support for VisualHostKey (a.k.a. randomArt)

** Task
* [SSHD-698] - Code cleanup for JDK8


Cheers,
Guillaume Nodet


smime.p7s
Description: S/MIME cryptographic signature

[jira] [Commented] (DIRMINA-1044) Non-Secure (no TLS/SSL) based client could successfully send message to secure Mina endpoint after second attempt

[Emmanuel Lecharny (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506421#comment-15506421
 ] 

Emmanuel Lecharny commented on DIRMINA-1044:


Yes, we are most certainly going to release a 2.0.15 quite soon. I still have 
to double check that it works fine with SSHD and ApacheDS.

In any case, if I start a vote tomorrow, it will take 3 days to ht the world, 
so expect a release by next monday, at best.

Many thanks for having double checked teh fix :-)

> Non-Secure (no TLS/SSL) based client could successfully send message to 
> secure Mina endpoint after second attempt
> -
>
> Key: DIRMINA-1044
> URL: https://issues.apache.org/jira/browse/DIRMINA-1044
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 2.0.13, 2.0.14
>Reporter: Thomas Papke
> Attachments: testcase.patch
>
>
> Following scenario:
> - We have a server application using Mina2. This endpoint is configured with 
> Mina SSLFilter (clientAuth=MUST, no startTLS support)
> If a client application (not able to do any kind of SSL) try to connect, we 
> have identified the following.
> 1. TCP connection --> could be successfully established (might be Ok)
> {code}
> 2016-09-16T03:23:47,423 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslFilter(432) - Adding the SSL Filter ssl to the 
> chain
> 2016-09-16T03:23:47,455 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslHandler(147) - Session Server[2](no sslEngine) 
> Initializing the SSL Handler
> Using SSLEngineImpl.
> Allow unsafe renegotiation: false
> Allow legacy hello messages: true
> Is initial handshake: true
> Is secure renegotiation: false
> Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
> for TLSv1
> Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1
> Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
> Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1
> Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for 
> TLSv1
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for 
> TLSv1
> Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
> for TLSv1.1
> Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
> Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for 
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for 
> TLSv1.1
> 2016-09-16T03:23:47,455 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslHandler(198) - Session Server[2](no sslEngine) 
> SSL Handler Initialization done.
> 2016-09-16T03:23:47,455 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslFilter(718) - Session Server[2](ssl...) : 
> Starting the first handshake
> 2016-09-16T03:23:47,455 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslHandler(572) - Session Server[2](ssl...) 
> processing the NEED_UNWRAP state
> 2016-09-16T03:23:47,471 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.executor.OrderedThreadPoolExecutor(432) - Adding event 
> SESSION_OPENED to session 2
> Queue : [SESSION_OPENED, ]
> 2016-09-16T03:23:47,471 DEBUG [pool-32-thread-1] 
> org.apache.mina.core.filterchain.IoFilterEvent(68) - Firing a SESSION_OPENED 
> event for session 2
> 2016-09-16T03:23:47,486 DEBUG [pool-32-thread-1] 
> org.apache.mina.core.filterchain.IoFilterEvent(117) - Event SESSION_OPENED 
> has been fired for session 2
> {code}
> 2. Client transmit some non-ssl encrypted payload --> client run into a 
> timeout, TCP connection remain open
> {code}
> 2016-09-16T03:24:04,693 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslFilter(484) - Session Server[2](ssl...): 
> Message received : HeapBuffer[pos=0 lim=873 cap=2048: 0B 4D 53 48 7C 5E 7E 5C 
> 26 7C 4E 45 53 7C 4E 49...]
> 2016-09-16T03:24:04,693 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslHandler(346) - Session Server[2](ssl...) 
> Processing the received message
> 2016-09-16T03:24:04,693 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslHandler(572) - Session Server[2](ssl...) 
> processing the NEED_UNWRAP state
> NioProcessor-21, fatal error: 80: problem unwrapping net record
> javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> NioProcessor-21, SEND TLSv1.2 

[jira] [Commented] (DIRMINA-1044) Non-Secure (no TLS/SSL) based client could successfully send message to secure Mina endpoint after second attempt

[Thomas Papke (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506247#comment-15506247
 ] 

Thomas Papke commented on DIRMINA-1044:
---

I have reviewed the fix in it solve our issue.

>From my understanding this is important from security perspective, are there 
>plans to get a 2.0.15 patch release soon?

> Non-Secure (no TLS/SSL) based client could successfully send message to 
> secure Mina endpoint after second attempt
> -
>
> Key: DIRMINA-1044
> URL: https://issues.apache.org/jira/browse/DIRMINA-1044
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 2.0.13, 2.0.14
>Reporter: Thomas Papke
> Attachments: testcase.patch
>
>
> Following scenario:
> - We have a server application using Mina2. This endpoint is configured with 
> Mina SSLFilter (clientAuth=MUST, no startTLS support)
> If a client application (not able to do any kind of SSL) try to connect, we 
> have identified the following.
> 1. TCP connection --> could be successfully established (might be Ok)
> {code}
> 2016-09-16T03:23:47,423 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslFilter(432) - Adding the SSL Filter ssl to the 
> chain
> 2016-09-16T03:23:47,455 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslHandler(147) - Session Server[2](no sslEngine) 
> Initializing the SSL Handler
> Using SSLEngineImpl.
> Allow unsafe renegotiation: false
> Allow legacy hello messages: true
> Is initial handshake: true
> Is secure renegotiation: false
> Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
> for TLSv1
> Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1
> Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
> Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1
> Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for 
> TLSv1
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for 
> TLSv1
> Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 
> for TLSv1.1
> Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
> Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for 
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for 
> TLSv1.1
> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for 
> TLSv1.1
> 2016-09-16T03:23:47,455 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslHandler(198) - Session Server[2](no sslEngine) 
> SSL Handler Initialization done.
> 2016-09-16T03:23:47,455 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslFilter(718) - Session Server[2](ssl...) : 
> Starting the first handshake
> 2016-09-16T03:23:47,455 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslHandler(572) - Session Server[2](ssl...) 
> processing the NEED_UNWRAP state
> 2016-09-16T03:23:47,471 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.executor.OrderedThreadPoolExecutor(432) - Adding event 
> SESSION_OPENED to session 2
> Queue : [SESSION_OPENED, ]
> 2016-09-16T03:23:47,471 DEBUG [pool-32-thread-1] 
> org.apache.mina.core.filterchain.IoFilterEvent(68) - Firing a SESSION_OPENED 
> event for session 2
> 2016-09-16T03:23:47,486 DEBUG [pool-32-thread-1] 
> org.apache.mina.core.filterchain.IoFilterEvent(117) - Event SESSION_OPENED 
> has been fired for session 2
> {code}
> 2. Client transmit some non-ssl encrypted payload --> client run into a 
> timeout, TCP connection remain open
> {code}
> 2016-09-16T03:24:04,693 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslFilter(484) - Session Server[2](ssl...): 
> Message received : HeapBuffer[pos=0 lim=873 cap=2048: 0B 4D 53 48 7C 5E 7E 5C 
> 26 7C 4E 45 53 7C 4E 49...]
> 2016-09-16T03:24:04,693 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslHandler(346) - Session Server[2](ssl...) 
> Processing the received message
> 2016-09-16T03:24:04,693 DEBUG [NioProcessor-21] 
> org.apache.mina.filter.ssl.SslHandler(572) - Session Server[2](ssl...) 
> processing the NEED_UNWRAP state
> NioProcessor-21, fatal error: 80: problem unwrapping net record
> javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> NioProcessor-21, SEND TLSv1.2 ALERT:  fatal, description = internal_error
> NioProcessor-21, WRITE: TLSv1.2 Alert, length = 2
> 2016-09-16T03:24:04,694 DEBUG [NioProcessor-21] 
>