subject:"Re\:"

Re: [I] Race condition in BufferedIoOutputStream [mina-sshd]

2024-08-05 Thread via GitHub



116-7 commented on issue #263:
URL: https://github.com/apache/mina-sshd/issues/263#issuecomment-2268459993

   @tomaswolf providing the Wireshark cap files will probably not be possible 
given the aforementioned bureaucracy. For context it's probably safe to assume 
that there are VPN tunnels, firewalls, and probably proxies in-between the 
client and server.
   
   For context the server is a Bitbucket server and clients are openssh through 
the git command.
   
   Given that the issue only occurs about 1/20 times even when attempting from 
the same client in the space of about 2 minutes and even when testing during 
times of low network activity (e.g. very early hours of the morning) my gut 
feel is that it may be mina-sshd related. There does seem to be an increase in 
the frequency of the error during times of server load e.g. towards the end of 
day when more people are committing their code.
   
   It's possible that there is some network path that is terminating and 
re-writing the packets incorrectly but given all the possible intermediate 
network hardware as well as the general opaqueness of the network/vlan/vpn/etc. 
it's not possible to trace the issue of such a device.
   
   I do have some screenshots from Wireshark though.
   
   1) In the unsuccessful case the TCP handshake completes, the client sends 
its protocol negotiation but the server responds with its key exchange which 
then makes its way to the application layer which then panics when it seems the 
null chars at the start of the key exchange packet.
   
   https://github.com/user-attachments/assets/6035deba-48a4-44bb-bcd3-316e63621d99;>
   https://github.com/user-attachments/assets/6feca034-be42-402c-9c09-bed3db9df1bc;>
   
   2) In the successful case the server's protocol negotiation comes through as 
expected with a relative sequence of 1 and the following server key exchange 
init has a sequence of 28.
   
   https://github.com/user-attachments/assets/1eab9c4e-c63a-491a-89f7-fed7a93f85e4;>
   https://github.com/user-attachments/assets/811ca942-fbf4-45b3-9193-c456186ef893;>
   https://github.com/user-attachments/assets/8b129ba6-95d6-41ac-89d4-b343d63119d4;>


-- 
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

Re: [I] Race condition in BufferedIoOutputStream [mina-sshd]

2024-08-05 Thread via GitHub

tomaswolf commented on issue #263:
URL: https://github.com/apache/mina-sshd/issues/263#issuecomment-2268364233

@116-7 I've never seen this in any Apache MINA sshd version. In any case it
would be unrelated to the race condition mentioned in this issue.

We _did_ have one report of what you describe:
[SSHD-1204](https://issues.apache.org/jira/browse/SSHD-1204), but it involved
an unknown server behind a Palto Alto Networks firewall appliance that
identified as "SSH2.0-PaloAltoNetworks_0.2" and an Apache MINA sshd _client_.
With a packet trace obtained via Wireshark we were able to prove that this
server did send its initial key exchange proposal first, and only afterwards
the protocol negotiation, i.e., its identification string. (The packet traces
are attached to that issue SSHD-1204.) This firewall thing appeared to be a
decrypting SSH proxy, so it's most likely the fault of that Palo Alto firewall,
not of whatever server was behind it.

Other people also had [trouble with that
firewall](https://tanzu.vmware.com/content/pivotal-engineering-journal/troubleshooting-obscure-openssh-failures-2).

If you can provide a Wireshark packet trace of the first few packets, which
are unencrypted, I could take a look to see if your case is similar.

--
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

Re: [I] Can mina sshd be used in Android? [mina-sshd]

2024-08-04 Thread via GitHub



albertvaka commented on issue #322:
URL: https://github.com/apache/mina-sshd/issues/322#issuecomment-2267725568

   Hey, just FYI we do use mina-sshd in Android in the KDE Connect project  
   
   We just updated from v0.14.0 (from 10 years ago) to v2.13.1 
   
   We haven't seen an issue with the Exceptions (yet?), but we did have to add 
a 
[workaround](https://invent.kde.org/network/kdeconnect-android/-/blob/90dbdee282e77e00fa88bc13fb1fc2cd6751b1ed/src/org/kde/kdeconnect/Plugins/SftpPlugin/SimpleSftpServer.kt#L213)
 to not use the `user.home` property.
   
   Other than that, Mina SSHD runs quite well on Android. Since Android 11 (API 
version  30) it can run unmodified. On older versions it's not possible to use 
the `NativeFileSystemFactory` because to access the filesystem you have to use 
the Storage Access Framework API, so we had to implement our own 
`FileSystemFactory ` using that, and we even went further and added more 
compatibility hacks to support down to Android 5.0, but you probably don't want 
to go that far.


-- 
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

Re: [I] Can mina sshd be used in Android? [mina-sshd]

2024-08-04 Thread via GitHub



albertvaka commented on issue #322:
URL: https://github.com/apache/mina-sshd/issues/322#issuecomment-2267710592

   Hey, just FYI we do use mina-sshd in Android in the KDE Connect project  
   
   We just updated from v0.14.0 (from 10 years ago) to v2.13.1 
   
   We haven't seen an issue with the Exceptions (yet?), but we did have to add 
a 
[workaround](https://invent.kde.org/network/kdeconnect-android/-/blob/90dbdee282e77e00fa88bc13fb1fc2cd6751b1ed/src/org/kde/kdeconnect/Plugins/SftpPlugin/SimpleSftpServer.kt#L213)
 to not use the `user.home` property.
   


-- 
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

Re: [I] Race condition in BufferedIoOutputStream [mina-sshd]

2024-08-04 Thread via GitHub



116-7 commented on issue #263:
URL: https://github.com/apache/mina-sshd/issues/263#issuecomment-2267570753

   @tomaswolf sorry to bring this up in this old thread but I have run into an 
issue with an older version of mina-sshd, 2.8.0 and I am wondering if this fix 
would resolve the issue. Unfortunately I cannot just update the version myself 
as the dependency is deep within a piece of software that I do not control the 
source code to and is also behind multiple layers of corporate bureaucracy 
let's say.
   
   The gist of the issue is that when attempting to establish an ssh session to 
a mina-sshd 2.8.0 instance there appears to be a race condition that shows up 
intermittently as a "banner exchange: Connection to xxx.xxx.xxx.xxx port 22: 
invalid format" error.
   
   The sequence appears to be the following:
   
   1) The client opens the connection and the initial TCP handshake completes 
successfully
   2) The server's first data packet with a relative TCP sequence number of 1 
(e.g. first packet after the SYN,ACK) is the key exchange init rather than the 
protocol negotiation.
   3) OpenSSH sends a TCP RST and the connection attempt fails because it 
panics if the first input on the socket isn't the protocol negotiation packet.
   
   At step 2 for a successful connection the protocol negotiation packet is 
sent first and the connection opens as expected but it seems that around 1/20 
attempts to connect result in the key exchange init being sent first.
   
   Java, and especially multi-threaded Java is not my area of expertise so I'm 
not sure if this patch would also fix the above issue. I had a look around the 
project's code to see if I could see anything and it seems like there are some 
futures and whatnot at play during a session initialisation but I couldn't tell 
if the key exchange waited for the protocol negotiation to complete. I'm also 
not sure if your patch being at the level of the output stream writing phase 
would side-step the need for key exchange to wait for the protocol negotiation 
future to complete.


-- 
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

Re: [I] Can mina-sshd Implement traffic diversion after ssh and sftp channels are opened? [mina-sshd]

2024-08-03 Thread via GitHub



czldb2 closed issue #576: Can mina-sshd Implement traffic diversion after ssh 
and sftp channels are opened?
URL: https://github.com/apache/mina-sshd/issues/576


-- 
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

Re: [I] server host key algorithms = ssh-rsa but still try to encryp the key using rsa-sha2-512 [mina-sshd]

2024-07-31 Thread via GitHub



baiglin commented on issue #531:
URL: https://github.com/apache/mina-sshd/issues/531#issuecomment-2259884314

   Thanks a lot @tomaswolf  for all the feedback and reactivity. I have forced 
the rsa signature on our side to indeed cope with the 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

Re: [VOTE] Release Apache MINA SSHD 2.13.2

2024-07-29 Thread Emmanuel Lécharny





On 28/07/2024 13:18, Thomas Wolf wrote:

On 25.07.24 20:08 , Gary Gregory wrote:

Is there something special I have to do on macOS?

I'm getting a lot of:
IllegalState Previous attempts to find a Docker environment failed.
Will not retry. Please see logs and check configuration

I have Docker Desktop 4.33.0 (160616).

I tested the src zip file.


That's it. In the ZIP file, even bash scripts and SSH private keys have
Windows line endings.

Bash fails with the most crazy errors if a bash script has CR-LF line
endings, and OpenSSH running inside a container may bail on private
keys containing CR-LFs instead of plain LFs.


O.
M.
G.

Thanks for having investigating the issue and fixed it.



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

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

Re: [I] Client auth: "authentication methods that can continue" is mishandled [mina-sshd]

2024-07-29 Thread via GitHub



tomaswolf closed issue #533: Client auth: "authentication methods that can 
continue" is mishandled
URL: https://github.com/apache/mina-sshd/issues/533


-- 
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

Re: [PR] GH-533: Fix ClientUserAuthService iteration through methods [mina-sshd]

2024-07-29 Thread via GitHub



tomaswolf merged PR #547:
URL: https://github.com/apache/mina-sshd/pull/547


-- 
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

Re: [PR] Bump org.apache:apache from 32 to 33 [mina-sshd]

2024-07-29 Thread via GitHub



gnodet merged PR #572:
URL: https://github.com/apache/mina-sshd/pull/572


-- 
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

Re: [PR] Bump bytebuddy.version from 1.12.6 to 1.14.18 [mina-sshd]

2024-07-29 Thread via GitHub



gnodet merged PR #569:
URL: https://github.com/apache/mina-sshd/pull/569


-- 
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

Re: [PR] [GH-539] Implement no-flow-control extension [mina-sshd]

2024-07-29 Thread via GitHub



tomaswolf commented on code in PR #565:
URL: https://github.com/apache/mina-sshd/pull/565#discussion_r1695310491


##
sshd-core/src/main/java/org/apache/sshd/common/kex/extension/DefaultClientKexExtensionHandler.java:
##
@@ -133,4 +151,39 @@ protected void handleServerSignatureAlgorithms(Session 
session, Collection

Re: [VOTE] Release Apache MINA SSHD 2.13.2

2024-07-28 Thread Guillaume Nodet

+1

Le mar. 23 juil. 2024 à 18:24, Guillaume Nodet  a écrit :
>
> Hey,
>
> I've staged a candidate release for an SSHD 2.13.2 release.
> This release contains a single bug fix:
> * Fix sntrup761x25519-sha512 (https://github.com/apache/mina-sshd/issues/525)
>
> Official staging repo:
>   https://dist.apache.org/repos/dist/dev/mina/sshd/2.13.2/
> Maven staging repo:
>   https://repository.apache.org/content/repositories/orgapachemina-1099
> Git tag:
>   https://github.com/apache/mina-sshd/commits/sshd-2.13.2
>
> Please review and vote !
>
> --
> 
> Guillaume Nodet



-- 

Guillaume Nodet

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

Re: [VOTE] Release Apache MINA SSHD 2.13.2

2024-07-28 Thread Thomas Wolf


On 25.07.24 20:08 , Gary Gregory wrote:

Is there something special I have to do on macOS?

I'm getting a lot of:
IllegalState Previous attempts to find a Docker environment failed.
Will not retry. Please see logs and check configuration

I have Docker Desktop 4.33.0 (160616).

I tested the src zip file.


That's it. In the ZIP file, even bash scripts and SSH private keys have
Windows line endings.

Bash fails with the most crazy errors if a bash script has CR-LF line
endings, and OpenSSH running inside a container may bail on private
keys containing CR-LFs instead of plain LFs.

I was testing the .tar.gz, and that one works (LF line endings).

Commit https://github.com/apache/mina-sshd/commit/5a6cf2f47 should fix
this for the next release.

Cheers,

  Thomas

P.S.: I don't quite understand why the ZIP worked on Windows; containers
should have the same problem on Windows.


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

Re: [I] Plan SSHD 3.0 [mina-sshd]

2024-07-28 Thread via GitHub



tomaswolf commented on issue #564:
URL: https://github.com/apache/mina-sshd/issues/564#issuecomment-2254478276

   One more thing:
   
   - Pass on the HostConfigEntry to the created session. It needs access to it 
for various advanced configs (like AddKeysToAgent, to mention just one).


-- 
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

Re: [VOTE] Release Apache MINA SSHD 2.13.2

2024-07-27 Thread Gary D. Gregory

I switched to Windows and it works, so +1

Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
Maven home: C:\java\apache-maven-3.9.8
Java version: 17.0.11, vendor: Eclipse Adoptium, runtime: C:\Program 
Files\Eclipse Adoptium\jdk-17.0.11.9-hotspot
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Docker Desktop 4.33.0 (160616)
Docker version 27.1.1, build 6312585

Gary

On 2024/07/27 16:43:52 Emmanuel Lécharny wrote:
> FTR I'm using Docker Desktop 4.3.0 (157355)
> 
> On 27/07/2024 00:48, Gary Gregory wrote:
> > Hm, odd this is on an Intel mac mini. I'll try again in the AM...
> > 
> > On Fri, Jul 26, 2024 at 6:32 PM Emmanuel Lécharny  
> > wrote:
> >>
> >> Weird.
> >>
> >> I ran the build on mac OS, worked like a charm.
> >>
> >> But I was on my old Intel based mac, not on my new M3 Mac OS.
> >>
> >> Could it be something like that,
> >>
> >> On 26/07/2024 15:33, Gary Gregory wrote:
> >>> I have Docker Desktop up and running and "docker ps" returns nothing
> >>> running before or after I try to build.
> >>>
> >>> What am I missing?
> >>>
> >>> Gary
> >>>
> >>>
> >>> On Thu, Jul 25, 2024 at 5:35 PM Thomas Wolf  wrote:
> 
>  On 25.07.24 20:08 , Gary Gregory wrote:
> > Is there something special I have to do on macOS?
> 
>  Not really.
> 
> > I'm getting a lot of:
> > IllegalState Previous attempts to find a Docker environment failed.
> > Will not retry. Please see logs and check configuration
> >
> > I have Docker Desktop 4.33.0 (160616).
> 
>  The docker engine must be running. But that's all. I'm not aware of
>  anything special in addition to that.
> 
>  Cheers,
> 
>   Thomas
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> >>> For additional commands, e-mail: dev-h...@mina.apache.org
> >>>
> >>
> >> --
> >> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> >> elecha...@apache.org
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> >> For additional commands, e-mail: dev-h...@mina.apache.org
> >>
> 
> -- 
> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> elecha...@apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
> 
> 

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

Re: [VOTE] Release Apache MINA SSHD 2.13.2

2024-07-27 Thread Emmanuel Lécharny


FTR I'm using Docker Desktop 4.3.0 (157355)

On 27/07/2024 00:48, Gary Gregory wrote:

Hm, odd this is on an Intel mac mini. I'll try again in the AM...

On Fri, Jul 26, 2024 at 6:32 PM Emmanuel Lécharny  wrote:


Weird.

I ran the build on mac OS, worked like a charm.

But I was on my old Intel based mac, not on my new M3 Mac OS.

Could it be something like that,

On 26/07/2024 15:33, Gary Gregory wrote:

I have Docker Desktop up and running and "docker ps" returns nothing
running before or after I try to build.

What am I missing?

Gary


On Thu, Jul 25, 2024 at 5:35 PM Thomas Wolf  wrote:


On 25.07.24 20:08 , Gary Gregory wrote:

Is there something special I have to do on macOS?


Not really.


I'm getting a lot of:
IllegalState Previous attempts to find a Docker environment failed.
Will not retry. Please see logs and check configuration

I have Docker Desktop 4.33.0 (160616).


The docker engine must be running. But that's all. I'm not aware of
anything special in addition to that.

Cheers,

 Thomas


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



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

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



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

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

Re: [PR] [GH-539] Implement no-flow-control extension [mina-sshd]

2024-07-27 Thread via GitHub



tomaswolf commented on code in PR #565:
URL: https://github.com/apache/mina-sshd/pull/565#discussion_r1693977545


##
sshd-core/src/main/java/org/apache/sshd/common/session/helpers/KeyExchangeMessageHandler.java:
##
@@ -236,7 +237,7 @@ public IoWriteFuture writePacket(Buffer buffer, long 
timeout, TimeUnit unit) thr
 int cmd = bufData[buffer.rpos()] & 0xFF;
 boolean enqueued = false;
 boolean isLowLevelMessage = cmd <= SshConstants.SSH_MSG_KEX_LAST && 
cmd != SshConstants.SSH_MSG_SERVICE_REQUEST
-&& cmd != SshConstants.SSH_MSG_SERVICE_ACCEPT;
+&& cmd != SshConstants.SSH_MSG_SERVICE_ACCEPT && cmd != 
KexExtensions.SSH_MSG_EXT_INFO;

Review Comment:
   Crap. I misread the code.



-- 
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

Re: [PR] [GH-539] Implement no-flow-control extension [mina-sshd]

2024-07-27 Thread via GitHub



tomaswolf commented on code in PR #565:
URL: https://github.com/apache/mina-sshd/pull/565#discussion_r1693977545


##
sshd-core/src/main/java/org/apache/sshd/common/session/helpers/KeyExchangeMessageHandler.java:
##
@@ -236,7 +237,7 @@ public IoWriteFuture writePacket(Buffer buffer, long 
timeout, TimeUnit unit) thr
 int cmd = bufData[buffer.rpos()] & 0xFF;
 boolean enqueued = false;
 boolean isLowLevelMessage = cmd <= SshConstants.SSH_MSG_KEX_LAST && 
cmd != SshConstants.SSH_MSG_SERVICE_REQUEST
-&& cmd != SshConstants.SSH_MSG_SERVICE_ACCEPT;
+&& cmd != SshConstants.SSH_MSG_SERVICE_ACCEPT && cmd != 
KexExtensions.SSH_MSG_EXT_INFO;

Review Comment:
   Crap. I misread the code.



##
sshd-core/src/main/java/org/apache/sshd/common/session/helpers/KeyExchangeMessageHandler.java:
##
@@ -236,7 +237,7 @@ public IoWriteFuture writePacket(Buffer buffer, long 
timeout, TimeUnit unit) thr
 int cmd = bufData[buffer.rpos()] & 0xFF;
 boolean enqueued = false;
 boolean isLowLevelMessage = cmd <= SshConstants.SSH_MSG_KEX_LAST && 
cmd != SshConstants.SSH_MSG_SERVICE_REQUEST
-&& cmd != SshConstants.SSH_MSG_SERVICE_ACCEPT;
+&& cmd != SshConstants.SSH_MSG_SERVICE_ACCEPT && cmd != 
KexExtensions.SSH_MSG_EXT_INFO;

Review Comment:
   I disagree with this. Yes, it's message number 7, so technically a 
"transport layer generic messages" as RFC 4253 puts it. However, RFC 4253 was 
written before RFC 8308, and RFC 4253 excludes already two messages from the 
range 1-19.
   
   Let's see: according to RFC 8308, a client may send SSH_MSG_EXT_INFO only 
once immediately after its initial SSH_MSG_NEWKEYS. At that point, there is 
definitely no KEX ongoing (even if the server required an immediate re-KEX by 
sending another SSH_MSG_KEXINIT, that new KEX can only start once the client 
has sent _its_ SSH_MSG_KEXINIT, which by definition must be after that 
SSH_MSG_EXT_INFO message -- otherwise the client would send SSH_MSG_NEWKEYS - 
SSH_MSG_KEXINIT - SSH_MSG_EXT_INFO, which is illegal according to RFC 8308.
   
   A _server_ can likewise send SSH_MSG_EXT_INFO immediately after its initial 
SSH_MSG_NEWKEYS. The same reasoning as above applies.
   
   A server can also send the message immediately preceeding its 
SSH_MSG_USERAUTH_SUCCESS. But that message cannot be sent while a KEX is 
on-going; it would be delayed. So to send it immediately preceeding, the 
SSH_MSG_EXT_INFO _must_ equally be delayed, otherwise one could get the 
sequence  - SSH_MSG_EXT_INFO - SSH_MSG_NEWKEYS - 
SSH_MSG_USERAUTH_SUCCESS, which also violates RFC 8308.
   
   Therefore, SSH_MSG_EXT_INFO **must not** be treated as a "transport layer 
generic message", and it must never be sent while a KEX is on-going.
   
   The other message from RFC 8308, SSH_MSG_NEWCOMPRESS, also cannot be sent 
during a KEX per section 3.2.1.



-- 
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

Re: [I] Plan SSHD 3.0 [mina-sshd]

2024-07-27 Thread via GitHub



tomaswolf commented on issue #564:
URL: https://github.com/apache/mina-sshd/issues/564#issuecomment-2254142413

   For 3.0.0, I have quite a few things that I'd like to do:
   
   * Break API big style :-) Seriously. There are a things in the list below 
that just cannot be done without breaking API.
   * Undo that awful sshd-common/sshd-core split. Instead, have 
sshd-common/sshd-client/sshd-server, _without split packages_. Make then all 
three proper OSGi bundles, and drop the sshd-osgi re-amalgamation.
   * A similar split might make sense on SFTP level 
(sshd-sftp-common/sshd-sftp-client/sshd-sftp-server).
   * Change the session initialization. Sessions should _not_ initiate 
communication in their constructor! Have an explicit `start()` method instead, 
and make sure it's called at an appropriate time.
   * Have a mechanism to configure a session after it has been instantiated, 
but before it starts. (Other than global properties on the SshClient!) There 
needs to be a simple way to configure sessions individually right after they 
have been created.
   * Refactor the SSH protocol implementation. It's a mess IMO, split over 
various levels of inheritance, which just feels wrong. Use composition instead. 
Give each session a filter chain. Implement the transport layer as a filter in 
that filter chain. Implement the authentication protocol as a filter atop. 
Implement the connection protocol atop. A callback from transportation layer to 
connection layer will be needed to handle getting "unsupported" replies 
(transport layer) to unknown global requests (connection layer).
   * Implement client-side proxy protocol (SOCKS, HTTP CONNECT) as a filter 
that can be inserted beneath the transport layer filter.
   * Don't require Bouncy Castle for EC keys. Java has built-in support for 
these even in Java 8.
   * Don't require net.i2p for ed25519/curve25519. It has a security flaw. Make 
our code work with any of Java ed25519 (since Java 15), BC ed25519, or net.i2p. 
(Tried already, but it's messy, and not possible without API breaks. Now that 
we require Java 17 for building, it would be easier to do.)
   * Have multi-release JARs (especially for the cipher algorithms and ed25519)
   * Rethink whether all the machinery for SecurityRegistrars is really needed 
and worth the maintenance effort. Can't we just use whatever Security providers 
are installed, and leave it at that? All that dynamic class loading is so 
fragile, and it might not always use the appropriate class loaders... (see e.g. 
GH issue 502)
   
   Plus umpteen little details changes that I can't enumerate all right now.
   
   Some of these ideas might need to be written down in more detail first. Do 
we have a wiki somewhere? (Confluence? GH wiki pages? Or collaborate in a 
Google doc?)


-- 
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

Re: [PR] [GH-545] Implements global-requests-ok extension [mina-sshd]

2024-07-27 Thread via GitHub



tomaswolf commented on PR #568:
URL: https://github.com/apache/mina-sshd/pull/568#issuecomment-2254136432

   Could you add tests, please?


-- 
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

Re: [PR] [GH-563] Implement p...@openssh.com extension and keystroke obfuscation [mina-sshd]

2024-07-27 Thread via GitHub



tomaswolf commented on PR #567:
URL: https://github.com/apache/mina-sshd/pull/567#issuecomment-2254135991

   Please double-check on the [OpenSSH mailing 
list](https://marc.info/?l=openssh-unix-dev=1=2) and the 
[bugtracker](https://bugzilla.mindrot.org) what problems cropped up in OpenSSH 
with this "keystroke obfuscation". Off the top of my head: 
https://bugzilla.mindrot.org/show_bug.cgi?id=3655 .


-- 
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

Re: [PR] [GH-539] Implement no-flow-control extension [mina-sshd]

2024-07-27 Thread via GitHub

mers, and it needs tests involving 
port forwarding with slow consumers. I'm a bit worried that `no-flow-control` 
may lead to a lot of data ending up being buffered somewhere. Especially if 
it's done like in this test: I suspect the "pending queue" will then get very 
large. That would be a no-go for a server, and might be a problem for a client.
   
   If someone tunes a high latency connection by increasing send and receive 
buffer sizes, might we get into trouble? (Especially on a server. Consider a 
server with 1000 connections all having `no-flow-control` enabled and streaming 
lots of data.)



##
sshd-core/src/main/java/org/apache/sshd/common/session/helpers/KeyExchangeMessageHandler.java:
##
@@ -236,7 +237,7 @@ public IoWriteFuture writePacket(Buffer buffer, long 
timeout, TimeUnit unit) thr
 int cmd = bufData[buffer.rpos()] & 0xFF;
 boolean enqueued = false;
 boolean isLowLevelMessage = cmd <= SshConstants.SSH_MSG_KEX_LAST && 
cmd != SshConstants.SSH_MSG_SERVICE_REQUEST
-&& cmd != SshConstants.SSH_MSG_SERVICE_ACCEPT;
+&& cmd != SshConstants.SSH_MSG_SERVICE_ACCEPT && cmd != 
KexExtensions.SSH_MSG_EXT_INFO;

Review Comment:
   I disagree with this. Yes, it's message number 7, so technically a 
"transport layer generic messages" as RFC 4253 puts it. However, RFC 4253 was 
written before RFC 8308, and RFC 4253 excludes already two messages from the 
range 1-19.
   
   Let's see: according to RFC 8308, a client may send SSH_MSG_EXT_INFO only 
once immediately after its initial SSH_MSG_NEWKEYS. At that point, there is 
definitely no KEX ongoing (even if the server required an immediate re-KEX by 
sending another SSH_MSG_KEXINIT, that new KEX can only start once the client 
has sent _its_ SSH_MSG_KEXINIT, which by definition must be after that 
SSH_MSG_EXT_INFO message -- otherwise the client would send SSH_MSG_NEWKEYS - 
SSH_MSG_KEXINIT - SSH_MSG_EXT_INFO, which is illegal according to RFC 8308.
   
   A _server_ can likewise send SSH_MSG_EXT_INFO immediately after its initial 
SSH_MSG_NEWKEYS. The same reasoning as above applies.
   
   A server can also send the message immediately preceeding its 
SSH_MSG_USERAUTH_SUCCESS. But that message cannot be sent while a KEX is 
on-going; it would be delayed. So to send it immediately preceeding, the 
SSH_MSG_EXT_INFO _must_ equally be delayed, otherwise one could get the 
sequence  - SSH_MSG_EXT_INFO - SSH_MSG_NEWKEYS - 
SSH_MSG_USERAUTH_SUCCESS, which also violates RFC 8308.
   
   Therefore, SSH_MSG_EXT_INFO **must not** be treated as a "transport layer 
generic message", and it must never be sent while a KEX is on-going.
   
   The other message from RFC 8308, SSH_MSG_NEWCOMPRESS, also cannot be sent 
during a KEX per section 3.2.1.



##
sshd-core/src/main/java/org/apache/sshd/common/channel/RemoteWindow.java:
##
@@ -67,6 +67,11 @@ public void consume(long len) {
 BufferUtils.validateUint32Value(len, "Invalid consumption length: %d");
 checkInitialized("consume");
 
+if (noFlowControl) {
+// flow control is disabled, so just bail out
+return;
+}
+

Review Comment:
   Additionally, `waitAndConsume()` and `waitForSpace()`should also do an early 
return. The should not wait for anything. `expand` must not do anything.



##
sshd-core/src/main/java/org/apache/sshd/common/kex/extension/DefaultServerKexExtensionHandler.java:
##
@@ -130,6 +136,23 @@ public void sendKexExtensions(Session session, KexPhase 
phase) throws Exception
 }
 }
 
+@Override
+public boolean handleKexExtensionRequest(
+Session session, int index, int count, String name, byte[] data)
+throws IOException {
+if (NoFlowControl.NAME.equals(name)) {
+String o = NoFlowControl.INSTANCE.parseExtension(data);
+Optional nfc = 
CoreModuleProperties.NO_FLOW_CONTROL.get(session);
+if (NoFlowControl.PREFERRED.equals(o) && nfc.orElse(Boolean.TRUE)
+|| NoFlowControl.SUPPORTED.equals(o) && 
nfc.orElse(Boolean.FALSE)) {
+AbstractSession abstractSession
+= ValidateUtils.checkInstanceOf(session, 
AbstractSession.class, "Not a supported session: %s", session);
+abstractSession.activateNoFlowControl();
+}
+}

Review Comment:
   Can we avoid this code duplication between client & server?



##
sshd-core/src/main/java/org/apache/sshd/common/channel/Window.java:
##
@@ -94,6 +97,8 @@ protected void init(long size, long packetSize, 
PropertyResolver resolver) {
 }
 
 synchronized (lock) {
+Session session = channelInstance.getSession(); // this should 
only be null during tests
+this.noFlowControl = sess

Re: [VOTE] Release Apache MINA SSHD 2.13.2

2024-07-26 Thread Gary Gregory

Hm, odd this is on an Intel mac mini. I'll try again in the AM...

On Fri, Jul 26, 2024 at 6:32 PM Emmanuel Lécharny  wrote:
>
> Weird.
>
> I ran the build on mac OS, worked like a charm.
>
> But I was on my old Intel based mac, not on my new M3 Mac OS.
>
> Could it be something like that,
>
> On 26/07/2024 15:33, Gary Gregory wrote:
> > I have Docker Desktop up and running and "docker ps" returns nothing
> > running before or after I try to build.
> >
> > What am I missing?
> >
> > Gary
> >
> >
> > On Thu, Jul 25, 2024 at 5:35 PM Thomas Wolf  wrote:
> >>
> >> On 25.07.24 20:08 , Gary Gregory wrote:
> >>> Is there something special I have to do on macOS?
> >>
> >> Not really.
> >>
> >>> I'm getting a lot of:
> >>> IllegalState Previous attempts to find a Docker environment failed.
> >>> Will not retry. Please see logs and check configuration
> >>>
> >>> I have Docker Desktop 4.33.0 (160616).
> >>
> >> The docker engine must be running. But that's all. I'm not aware of
> >> anything special in addition to that.
> >>
> >> Cheers,
> >>
> >> Thomas
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> > For additional commands, e-mail: dev-h...@mina.apache.org
> >
>
> --
> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> elecha...@apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>

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

Re: [VOTE] Release Apache MINA SSHD 2.13.2

2024-07-26 Thread Emmanuel Lécharny


Weird.

I ran the build on mac OS, worked like a charm.

But I was on my old Intel based mac, not on my new M3 Mac OS.

Could it be something like that,

On 26/07/2024 15:33, Gary Gregory wrote:

I have Docker Desktop up and running and "docker ps" returns nothing
running before or after I try to build.

What am I missing?

Gary


On Thu, Jul 25, 2024 at 5:35 PM Thomas Wolf  wrote:


On 25.07.24 20:08 , Gary Gregory wrote:

Is there something special I have to do on macOS?


Not really.


I'm getting a lot of:
IllegalState Previous attempts to find a Docker environment failed.
Will not retry. Please see logs and check configuration

I have Docker Desktop 4.33.0 (160616).


The docker engine must be running. But that's all. I'm not aware of
anything special in addition to that.

Cheers,

Thomas


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



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 11683 matches

Mail list logo