similar to: Defend against user enumeration timing attacks - overkill

Dear colleagues, May I ask you to explain whether I am wrong in my conclusions? On Wed, Apr 12, 2023 at 11:55?AM Dmitry Belyavskiy <dbelyavs at redhat.com> wrote: > > Dear colleagues, > > I have a question about this commit: > >

Dear Peter, I'm trying to balance the original problem statement (protection from users enumeration) and avoid doubling time here if the process has already taken a long time to provide faster auth method iteration. I believe that a better solution is to set some arbitrary (probably configurable) timeout and, in case when we spend more time than that value, avoid doubling it. On Wed, Jun 28,

Dmitry Belyavskiy wrote: > May I ask you to explain whether I am wrong in my conclusions? I guess it's not clear what problem you are trying to solve. //Peter

@Dmitry, you may get more traction by reporting this issue (with patch) at https://www.openssh.com/report.html . It can also help other folks who may be encountering the same issue. -- jmk > On Mar 3, 2023, at 02:10, Dmitry Belyavskiy <dbelyavs at redhat.com> wrote: > > ?Dear colleagues, > > Could you please take a look? > >> On Fri, Jan 20, 2023 at 12:55?PM

Dear colleagues, Could you please take a look? On Fri, Jan 20, 2023 at 12:55?PM Dmitry Belyavskiy <dbelyavs at redhat.com> wrote: > > Dear colleagues, > > ssh-keygen uses SHA1 algorithm (default) when verifying that the key is usable. It causes problems on recent systems where SHA1 is disabled for use with signatures (at least, RHEL 9+). > > The proposed patch enforces

Dear Damien, On Wed, Apr 19, 2023 at 9:55?AM Damien Miller <djm at mindrot.org> wrote: > > On Wed, 19 Apr 2023, Dmitry Belyavskiy wrote: > > > > While I'm sure this is good for RHEL/rawhide users who care about FIPS, > > > Portable OpenSSH won't be able to merge this. We explictly aim to support > > > LibreSSL's libcrypto as well as

On Thu, Jul 20, 2023 at 3:53?AM Damien Miller <djm at mindrot.org> wrote: > > > > On Wed, 19 Jul 2023, Dmitry Belyavskiy wrote: > > > Dear Damien, > > > > Could you please clarify which versions are vulnerable? > > OpenSSH 5.5 through 9.3p1 inclusive Many thanks for the clarification! -- Dmitry Belyavskiy

Dear colleagues, ssh-keygen uses SHA1 algorithm (default) when verifying that the key is usable. It causes problems on recent systems where SHA1 is disabled for use with signatures (at least, RHEL 9+). The proposed patch enforces using a sha2 algorithm for key verification. -- Dmitry Belyavskiy -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-keygen.patch

Dear colleagues, I came across an upstream test suite failure on Fedora 36. The test in question is forwarding, the output is ========== adding modulifile='/home/dbelyavs/work/upstream/openssh-portable/moduli' to sshd_config using cached key type ssh-ed25519 using cached key type sk-ssh-ed25519 at openssh.com using cached key type ecdsa-sha2-nistp256 using cached key type

https://bugzilla.mindrot.org/show_bug.cgi?id=3289 Bug ID: 3289 Summary: Patch fixing the issues found by coverity scan Product: Portable OpenSSH Version: 8.5p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: Miscellaneous Assignee:

https://bugzilla.mindrot.org/show_bug.cgi?id=3665 Bug ID: 3665 Summary: publickey RSA signature unverified: error in libcrypto to RHEL9 sshd (with LEGACY crypto policy enabled) Product: Portable OpenSSH Version: 8.7p1 Hardware: ix86 OS: Linux Status: NEW Severity: major

On Fri, Jul 21, 2023 at 4:37?AM Dmitry Belyavskiy <dbelyavs at redhat.com> wrote: > > On Thu, Jul 20, 2023 at 3:53?AM Damien Miller <djm at mindrot.org> wrote: > > > > > > > > On Wed, 19 Jul 2023, Dmitry Belyavskiy wrote: > > > > > Dear Damien, > > > > > > Could you please clarify which versions are vulnerable? > >

https://bugzilla.mindrot.org/show_bug.cgi?id=3558 Bug ID: 3558 Summary: Spelling "yes" as "Yes" in sshd_config has a fatal result Product: Portable OpenSSH Version: 7.2p2 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component:

https://bugzilla.mindrot.org/show_bug.cgi?id=3603 Bug ID: 3603 Summary: ssh clients can't communicate with server with default cipher when fips is enabled at server end Product: Portable OpenSSH Version: 9.4p1 Hardware: All OS: Linux Status: NEW Severity: critical

On Wed, 25 Jan 2023 at 19:29, Darren Tucker <dtucker at dtucker.net> wrote: [...] > I have a part-done patch that logs the output from all ssh and sshd > instances to separate datestamped files. I'll see if I can tidy that > up for you to try You can grab it from here: https://github.com/daztucker/openssh-portable/commit/b54b39349e1a64cbbb9b56b0f8b91a35589fb528 It's not

On Wed, 19 Apr 2023, Dmitry Belyavskiy wrote: > > While I'm sure this is good for RHEL/rawhide users who care about FIPS, > > Portable OpenSSH won't be able to merge this. We explictly aim to support > > LibreSSL's libcrypto as well as openssl-1.1.x and neither supports the > > OSSL_PARAM_BLD API (neither does BoringSSL, though our support for that > >

Dear Damien, On Wed, Apr 19, 2023 at 7:13?AM Damien Miller <djm at mindrot.org> wrote: > > On Tue, 18 Apr 2023, Norbert Pocs wrote: > > > Hi OpenSSH mailing list, > > > > I would like to announce the newly introduced patch in Fedora rawhide [0] > > for > > > > FIPS compliance efforts. The change will be introduced in an upcoming RHEL 9 > >

Dear Damien, Could you please clarify which versions are vulnerable? On Wed, Jul 19, 2023 at 7:38?PM Damien Miller <djm at cvs.openbsd.org> wrote: > > OpenSSH 9.3p2 has just been released. It will be available from the > mirrors listed at https://www.openssh.com/ shortly. > > OpenSSH is a 100% complete SSH protocol 2.0 implementation and > includes sftp client and server

I'm trying to send data to a server with openssh 7.9p1, but it's hanging somewhere. the client stop at the line : Jul 7 11:52:16 TOTO sshd[19553]: debug3: channel 0: will not send data after close and after 5 minutes the client closes the connection, why ? This is the trace of the server openssh : ( DEBUG3 level) Jul 7 11:52:15 TOTO sshd[31175]: debug3: fd 6 is not O_NONBLOCK Jul

On 30/06/2023 09:56, Damien Miller wrote: > It's very hard to figure out what is happening here without a debug log. > > You can get one by stopping the listening sshd and running it manually > in debug mode, e.g. "/usr/sbin/sshd -ddd" Or starting one in debug mode on a different port, e.g. "-p99 -ddd"