similar to: Weak DH primes and openssh

Hi, You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be that 1024-bit DH primes might well be too weak. I'm wondering what (if anything!) you propose to do about this issue, and what Debian might do for our users? openssh already prefers ECDH, which must reduce the impact somewhat, although the main Windows client (PuTTY) doesn't support ECDH yet. But

> Can this be addressed in ssh_config/sshd_config with the KexAlgorithms setting? weakdh.org/sysadmin.html recommends adding: KexAlgorithms curve25519-sha256 at libssh.org But this thread makes it sound as if it's not necessary. Can anyone confirm? Personally I'm on openssh-6.7. - Grant > You will be aware of https://weakdh.org/ by now, I presume; the take-home seems to be

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 --- Comment #13 from Darren Tucker <dtucker at zip.com.au> --- (In reply to Christoph Anton Mitterer from comment #10) [...] > Even though an attacker cannot (AFAIU??) for a connection to > downgrade to the weaker groups, The server's DH-GEX exchange hash includes the DH group sizes it received from the client. If these are

Also, how are default moduli shipped with OpenSSH for use in diffie-hellman-group-exchange-sha1/sha256 chosen? Are they chosen randomly by developers or are they chosen for security properties? If they are random, why not use moduli from RFC 7919 instead, like Mozilla recommends? On Fri, Feb 15, 2019 at 3:48 AM Mark D. Baushke <mdb at juniper.net> wrote: > > Yegor Ievlev <koops1997

I ask because the removal of diffie-hellman-group-exchange-sha1 happened accidently in 7.8 due to a mistake in a change to readconf.c. I noticed this and filed a bug about it along with a patch to fix readconf.c to use KEX_CLIENT_* like it used to: https://github.com/openssh/openssh-portable/commit/1b9dd4aa https://bugzilla.mindrot.org/show_bug.cgi?id=2967 Its clear the removal was unintentional

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 Bug ID: 2302 Summary: ssh (and sshd) should not fall back to deselected KEX algos Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: security Priority: P5 Component: ssh

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 Bug ID: 2302 Summary: ssh (and sshd) should not fall back to deselected KEX algos Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: security Priority: P5 Component: ssh

Hi, I'm interested in requiring a minimum of 3072-bit DH moduli when using the "diffie-hellman-group-exchange-sha256" kex, so I edited my /etc/ssh/moduli file such that only 3071+ moduli are left. However, when clients ask for a max of 2048-bit moduli, they actually get one (!). I poked around and found that a fallback mechanism exists (dh.c:185), which returns back the

Anyone trying openssl 3 against openssh? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Put more trust in nobility of character than in an oath. -Solon

https://bugzilla.mindrot.org/show_bug.cgi?id=2209 Bug ID: 2209 Summary: Problem logging into Cisco devices under 6.5p1 (kexgexc.c) Product: Portable OpenSSH Version: 6.5p1 Hardware: amd64 OS: FreeBSD Status: NEW Severity: normal Priority: P5 Component: ssh

I completely support this request. ?My organization is interested in supporting these public key algorithms to comply with NIST SP 800-131A too. Jeff, it is my understanding that through RFC4419, OpenSSH can be support the Key Agreement Using Diffie-Hellman and MQV guidelines in SP 800-131A using the "diffie-hellman-group-exchange-sha256" method. ?Is that correct? Thanks.

Hello, I'd like to inform you that the next release of WinSCP SFTP client (version 5.7.5) will support Diffie-Hellman group exchange as specified by RFC 4419. http://winscp.net/tracker/show_bug.cgi?id=1345 So I'd like to ask you to kindly update the check in compat_datafellows() to WinSCP_release_4* WinSCP_release_5.0* WinSCP_release_5.1* WinSCP_release_5.2* WinSCP_release_5.5*

On 09/22/2017 06:55 PM, Tim Broberg wrote: > Do I understand correctly, that you find the security of group 14 unacceptable and yet you left it enabled? In the end, I'm trying to ensure a minimum equivalent of 128-bits of security. Group14 is 2048-bits, which roughly translates to 112-bits. [1] To this end, I disabled the "diffie-hellman-group14-sha1" and

On 09/24/2017 12:21 AM, Mark D. Baushke wrote: > I suggest you upgrade to a more recent edition of the OpenSSH software. > The most recent release is OpenSSH 7.5 and OpenSSH 7.6 will be released > very soon. This problem is in v7.5 and v7.6. See dh.c:436. > OpenSSH 6.6 was first released on October 6, 2014. I brought up v6.6 to give an example that older clients wouldn't be

Can we disable diffie-hellman-group14-sha1 too? On Thu, Feb 14, 2019 at 10:23 PM Mark D. Baushke <mdb at juniper.net> wrote: > > Hi John, > > The short answer is YES. > > Jon DeVree <nuxi at vault24.org> writes: > > > I ask because the removal of diffie-hellman-group-exchange-sha1 happened > > accidently in 7.8 due to a mistake in a change to

On 09/22/2017 03:22 PM, Daniel Kahn Gillmor wrote: > On Thu 2017-09-21 18:12:44 -0400, Joseph S Testa II wrote: >> I gotta say... having a fallback mechanism here seems pretty >> strange. The entire point of the group exchange is to use a dynamic >> group and not a static one. > > fwiw, i think dynamic groups for DHE key exchange is intrinsically > problematic

Using ssh2 via agent to connect through proxy to sshd host. Each connection (client to proxy, proxy to host) takes an average of 22 seconds, totaling approximately 44 seconds for a complete connection. Debug logging with vmstat directed to the same file indicates two points where a majority of time is spent (have looked at the similar postings): debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP (*6

In message <Pine.LNX.4.30.0104031615270.8678-100000 at holly.crl.go.jp>, Tom Holro yd writes: >SRP has different requirements from Diffie-Hellman. In particular, >for SRP the generator must be primitive. It turns out that the "primes" >file contains only safe primes with primitive generators, and is thus >ideal for SRP, but so far in OpenSSH it has only been used for

I do not often use X11 - but when I do I prefer to enable X11forwarding, and when finished - turn it off. This is preferable, imho, to having "clear" X11 processing when local - and otherwise impossible when working remote. Working with openssh-7.5p2 I cannot figure out what (extra) I need to do with sshd_config to get it working. I know that there is a security-fix starting with

I'm not nearly knowledgeable enough in crypto to fully understand your answer, but I will try. I wonder why moduli are not automatically generated the first time sshd is started though. That would make much more sense than shipping a default moduli file but also asking everyone to replace it with their own. On Fri, Feb 15, 2019 at 5:50 AM Mark D. Baushke <mdb at juniper.net> wrote: >