search for: belyavskiy

@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 Dmitry Belyavskiy <dbelyavs at redhat.com> wrote: >> >> Dear colleagues, >> >> ssh-keygen uses SHA1 algorithm (...

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

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 openssl-1.1.x and neither supports the > > &gt...

...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, 2023 at 2:04?PM Peter Stuge <peter at stuge.se> wrote: > > 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 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot....

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 Type: text/x-patch Size: 1217 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20230120/ffe3d6e1/attachment.bin>

...eally spent time is more than this upper limit, to avoid extra sleep? Will it be still necessary to protect from the attack? Vice versa, when the auth failure happens fast enough, the doubling will not significantly slow down the enumerations... Any comments will be highly appreciated! -- Dmitry Belyavskiy

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: > > https://github.com/openssh/openssh-portable/commit/e9d910b0289c820852f7afa67f584cef1c05fe95#diff-a25e40214ca9c9f78abce22f23bf2abdb2a24384c6610d60bbb314aed534eb48R216 > > T...

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

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

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

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 (ne...

...9; make: *** [Makefile:724: t-exec] Error 2 ========== The test (especially built from upstream) shouldn't be affected by Fedora cryptography limitations. Unfortunately I also can't get any clues from regress/failed_ssh.log Any help will be appreciated. Many thanks in advance! -- Dmitry Belyavskiy

...t; OSSL_PARAM_BLD API (neither does BoringSSL, though our support for that > I'd describe as "best effort"). > > If this changes we can look again. Yes, we understand and respect your choice. Would it be acceptable in any form being wrapped in necessary #ifdefs ? -- Dmitry Belyavskiy

...ng the server refuse to allow smaller moduli to > be used than exist in ModuliFile, or another explicit configuration > setting is added, it doesn't matter I strongly support this requirement. We have a similar one for RSA and having an explicit setting for DH would be great. -- Dmitry Belyavskiy

...eport.html > Security bugs should be reported directly to openssh at openssh.com > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Dmitry Belyavskiy

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

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=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 Fri, 10 Mar 2023, Joel GUITTET wrote: > Hi, > We currently work on a project that require SSH server with FIPS and using OpenSSL v3. > Patching OpenSSH for this looks to be a massive job. Is it something that is considered on your side? Patching OpenSSH for what exactly? OpenSSH builds just fine using OpenSSL 3.x and indeed it is tested constantly via our github test infrasructure