similar to: [Bug 2942] New: minor memory leak in ssh_set_newkeys()

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> The "zstd at breakpoint.cc" compression algorithm enables ZSTD based compression as defined in RFC8478. The compression is delayed until the server sends the SSH_MSG_USERAUTH_SUCCESS which is the same time as with the "zlib at openssh.com" method. Signed-off-by: Sebastian Andrzej Siewior <sebastian at

Hello, I am working on a bounds checking gcc(based on Richard Jones work) with a low enough overhead that will make it acceptable in production code. And i obtained openssh-3.2.2p1 with the view of testing the effectiveness of my code detecting the recently reported vunerability,but my code fails on with an error report of a use of memcpy with overlapping source and destination regions. I have

On Wed, 29 Mar 2023, Chris Rapier wrote: > I was wondering if there was something specific to the internal chacha20 > cipher as opposed to OpenSSL implementation. > > I can't just change the block size because it breaks compatibility. I can do > something like as a hack (though it would probably be better to do it with the > compat function): > > if

I'm hardly an expert on this, but if I remember correctly, the rekey rate for good security is mostly dependent on the cipher block size. I left my reference books at home; so, I can't come up with a reference for you, but I would take Chris' "I'm deeply unsure of what impact that would have on the security of the cipher" comment seriously and switch to a cipher with a

That's true for block ciphers, but ChaCha20+poly1305 is a stream cipher. On Wed, 29 Mar 2023, Robinson, Herbie wrote: > > I?m hardly an expert on this, but if I remember correctly, the rekey rate > for good security is mostly dependent on the cipher block size.? I left my > reference books at home; so, I can?t come up with a reference for you, but I > would take Chris?

Ah, with an internal block size [Is that what one calls it?] of 64 bytes. From: Damien Miller <djm at mindrot.org> Sent: Wednesday, March 29, 2023 3:08 PM To: Robinson, Herbie <Herbie.Robinson at stratus.com> Cc: Chris Rapier <rapier at psc.edu>; Christian Weisgerber <naddy at mips.inka.de>; openssh-unix-dev at mindrot.org Subject: RE: [EXTERNAL] Re: ChaCha20 Rekey

https://bugzilla.mindrot.org/show_bug.cgi?id=2982 Bug ID: 2982 Summary: gssapi_cleanup: supported mechs should be freed via gss_release_oid_set Product: Portable OpenSSH Version: 7.9p1 Hardware: All OS: Windows 10 Status: NEW Severity: normal Priority: P5 Component:

I was wondering if there was something specific to the internal chacha20 cipher as opposed to OpenSSL implementation. I can't just change the block size because it breaks compatibility. I can do something like as a hack (though it would probably be better to do it with the compat function): if (strstr(enc->name, "chacha")) *max_blocks = (u_int64_t)1 << (16*2);

Reordering calloc arguments silences gcc compiler warnings of latest versions. Spotted with OpenSSH-portable on a Linux system. Okay? Index: cipher.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/cipher.c,v diff -u -p -u -p -r1.121 cipher.c --- cipher.c 17 May 2024 02:39:11 -0000 1.121 +++ cipher.c 13 Aug 2024 16:46:00 -0000 @@ -249,7 +249,7

Hi, I've installed openssl-0.9.7 and now am testing current openssh-cvs. The kerberosIV installation has it's own libdes.a. I'm quite please openssh built successfully, congratulations! Unfortunately, kerberos autentication is not tried at all. As far as I remeber, Ja Iven who wrote some patch, which as he said got into 3.5p1 also removed the ifdef's that --with-privsep no longer

I found this problem when working with the Suse9.1 distribution, but have since reproduced it with a vanilla build of Openssh (openssh-3.9p1.tar.gz). Basically I cannot get a command like this: XXXX>ssh -vvv -1 -o "RhostsAuthentication yes" AAAA to work. Yes the appropriate settings are in the servers sshd_config file. Hostbased protocol 1 ssh using rhosts between computers is

I added ZSTD support to OpenSSH roughly three years ago and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

Hi, just "cvs update"'d to get the latest portable version, to start rebuilding our AIX systems to get zlib-1.1.4 and the channel-bug fix. SSH protocol 2 seems to work nicely, ssh protocol 1 doesn't work properly. Environment: AIX 4.3.3, openssl 0.9.6c, openssh as of today (Mar 12, 11:20 GMT). Client/blowfish, to openssh 3.0p1 or to 2.5.1p1: debug1: Encryption type: blowfish

http://bugzilla.mindrot.org/show_bug.cgi?id=342 Summary: RhostsRSAAuthentication does not work with 3.4p1 Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=369 ------- Additional Comments From devel at pitux.com 2002-09-10 19:19 ------- I confirm that this bug does exist. It's especially annoying since we use here a lot of scripts which check for the return values of scp to indicate success or failure. In fact it does the good thing on nonexistent files/dirs/etc, but fails in case of auth

Am I the only person to be seeing this log message from sshd: fatal: cipher_init: EVP_CipherInit: set key failed for aes128-cbc [preauth] ? (security/openssh-portable, with HPN patches and MIT Kerberos, although Kerberos is not actually configured on this server.) A work-around is to disable aes128-cbc in sshd_config, but it would be nice not to have my logs spammed with this. Currently

Hi, for some days now I am/was fighting with an annoying problem. I have to support an environment where RhostRSAAuthecntication via /etc/ssh/sshd_known_hosts is used for password-less login. This works fine with RH7.3 (and RH8) and openssh versions openssh-3.1p1-3 (and openssh-3.4p1-2). Our customer has now requested an upgrade to RH9. That comes with openssh-3.5p-11 and the password-less

http://bugzilla.mindrot.org/show_bug.cgi?id=357 Summary: SSH does not handle "Protocol" option in ~/.ssh/options properly Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo:

I'm having trouble with OpenSSH 3.1 on an OpenBSD 2.8 box. I apply the patch (the second patch, date/time March 7 12:41 GMT) and I can't connect to it from any other box using Version 1 protocols. I get this: (collector1 is an OpenBSD 3.0 box running OpenSSH 3.1) [kwhite at collector1 kwhite]$ ssh -1 -v scooby.local OpenSSH_3.1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1:

http://bugzilla.mindrot.org/show_bug.cgi?id=176 Summary: OpenSSH_3.1p1 gives X_ShmAttach error on forwarded X11 channel Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: sshd AssignedTo: