similar to: Feature Request: new "Require Strict-KEX" c/s option

Hi there, > So there could be a Chacha20-Poly1305v2 at openssh.com which uses AD data to chain the > messages together, so it will be resistant against terrapin even without the strict-kex. > > Consequently the hmac-etmv2 at openssh.com mode could be deviced in a similar manner, to > also include the transcript hash or similar things. This would still require both, client and

Hello, in addition to my last thread about a new config option to make strict-kex mandatory, I also wonder if a new mechanism for ciphers/macs can be introduced and is reliable by simple both sides using it. So there could be a Chacha20-Poly1305v2 at openssh.com which uses AD data to chain the messages together, so it will be resistant against terrapin even without the strict-kex. Consequently

On Fri, Jan 26, 2024 at 7:24?PM Jochen Bern <Jochen.Bern at binect.de> wrote: > On 25.01.24 14:09, Kaushal Shriyan wrote: > > I am running the below servers on Red Hat Enterprise Linux release 8.7 > > How do I enable strong KexAlgorithms, Ciphers and MACs > > On RHEL 8, you need to be aware that there are "crypto policies" > modifying sshd's behaviour,

https://bugzilla.mindrot.org/show_bug.cgi?id=3663 Bug ID: 3663 Summary: KEX host signature length wrong since strict kex introduced Product: Portable OpenSSH Version: 9.6p1 Hardware: Other OS: Linux Status: NEW Severity: major Priority: P5 Component: sshd

BTW based on your output it looks like the DEFAULT policy is just fine, If you really want to turn etm HMAC and chacha20 off, you should follow the RHEL security alert https://access.redhat.com/security/cve/cve-2023-48795 cipher at SSH = -CHACHA20-POLY1305 ssh_etm = 0 by putting these lines into `/etc/crypto-policies/policies/modules/CVE-2023-48795.pmod`, applying the resulting subpolicy

https://bugzilla.mindrot.org/show_bug.cgi?id=1486 Summary: Improperly used buffer during KEX Classification: Unclassified Product: Portable OpenSSH Version: 5.0p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: unassigned-bugs at

https://bugzilla.mindrot.org/show_bug.cgi?id=2198 Bug ID: 2198 Summary: GSSAPIKeyExchange gssapi-keyex bug in kex.c choose_kex() Product: Portable OpenSSH Version: 6.4p1 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: Kerberos support

On Sat, May 16, 2015 at 04:53:33PM +0100, Etienne Dechamps wrote: > I believe there is a design flaw in the way SPTPS key regeneration > works, because upon reception of the KEX message the other nodes will > send both KEX and SIG messages at the same time. However, the node > expects SIG to arrive after KEX. Therefore, there is an implicit > assumption that messages won't

I'm in the process of updating my GSSAPI patches to the 2.9 release. However, I've run into a slight problem with managing to get user options to play nicely with the way that the kex code is now organised. With the GSS kex its possible for the user to specify whether they want to delegate their credentials to the server or not. This option is used only on the client side (and so is

https://bugzilla.mindrot.org/show_bug.cgi?id=2291 Bug ID: 2291 Summary: ssh -Q kex lists diffie-hellman-group1-sha1 twice Product: Portable OpenSSH Version: 6.7p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component: sftp-server Assignee:

Hi, I'm currently trying to troubleshoot what appears to be a very subtle bug (most likely a race condition) in SPTPS that causes state to become corrupted during SPTPS key regeneration. The tinc version currently deployed to my production nodes is git 7ac5263, which is somewhat old (2014-09-06), but I think this is still relevant because the affected code paths haven't really changed

Dear all, I am currently implementing an experimental key exchange (KEX) algorithm. Unlike current algorithms like DH, mine needs to be able to fail gracefully, and in case of failure, continue with whatever algorithm would have been negotiated if mine was not selected. My strategy for graceful failure is to remove my KEX algorithm from myproposal[KEX_DEFAULT_KEX] and to initiate a new key

I sent you a pull request that addresses the general issue, at least for the short term: https://github.com/gsliepen/tinc/pull/83 On 16 May 2015 at 19:36, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sat, May 16, 2015 at 04:53:33PM +0100, Etienne Dechamps wrote: > >> I believe there is a design flaw in the way SPTPS key regeneration >> works, because upon reception of

https://bugzilla.mindrot.org/show_bug.cgi?id=2402 Bug ID: 2402 Summary: Missing include in kex.h results in compilation error due to unknown type Product: Portable OpenSSH Version: 6.8p1 Hardware: Sparc OS: Solaris Status: NEW Severity: normal Priority: P5 Component:

Hi, I have the SSH Terrapin Prefix Truncation Weakness on Red Hat Enterprise Linux release 8.7 (Ootpa). The details are as follows. # rpm -qa | grep openssh openssh-8.0p1-16.el8.x86_64 openssh-askpass-8.0p1-16.el8.x86_64 openssh-server-8.0p1-16.el8.x86_64 openssh-clients-8.0p1-16.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.7 (Ootpa) # SSH Terrapin Prefix Truncation

You might find RedHat's CVE page on this useful: https://access.redhat.com/security/cve/cve-2023-48795 On Tue, Jan 23, 2024 at 10:04?AM Kaushal Shriyan <kaushalshriyan at gmail.com> wrote: > Hi, > > I have the SSH Terrapin Prefix Truncation Weakness on Red Hat Enterprise > Linux release 8.7 (Ootpa). The details are as follows. > > # rpm -qa | grep openssh >

OpenSSH 9.6 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 support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested

Hey guys, My second post in the last few days (boy I'm active! ;)). We've had a few issues with SSH Secure Shell version 3.2.0 (build 267) and sftp and while trying to figure it out I noticed something in the debug output that I think should be brought to OpenSSH's attention. Ssh2Transport/trcommon.c:1518: All versions of OpenSSH handle kex guesses incorrectly. Does anyone know

https://bugzilla.mindrot.org/show_bug.cgi?id=1314 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX --- Comment #1 from Damien Miller <djm at

http://bugzilla.mindrot.org/show_bug.cgi?id=1054 Summary: Nmap Causing SSH Session to Prematurely End Product: Portable OpenSSH Version: 3.8.1p1 Platform: All OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org ReportedBy: