similar to: [Bug 1390] New: RekeyLimit max value is too restrictive

http://bugzilla.mindrot.org/show_bug.cgi?id=1056 ------- Comment #2 from djm at mindrot.org 2005-10-30 10:59 ------- hm, I haven't been able to reproduce the hang you have experienced when setting rekeylimit low. Even setting RekeyLimit=16 produces a working session for me. This isn't to say that we shouldn't set a minimum. ------- You are receiving this mail because:

https://bugzilla.mindrot.org/show_bug.cgi?id=2264 Bug ID: 2264 Summary: RekeyLimit option does not allow '4G' value when UINT_MAX is 0xffffffff Product: Portable OpenSSH Version: 6.6p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5

https://bugzilla.mindrot.org/show_bug.cgi?id=1380 Summary: incorrect check for strlen(fwd->connect_host) in parse_forward() Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: ssh

Hello list, I'm not sure whether this is bug worthy or just my own insanity. I'm using 6.4p1 packages from Debian jessie and wheezy-backports. I like VisualHostKey, although it may not add any protection (other than not trusting ones own known_hosts file?), I've become accustomed to it as it seems that extra neurons fire when I log into a host and get a visual cue of what looks like

http://bugzilla.mindrot.org/show_bug.cgi?id=1056 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #9 from Damien Miller <djm at

https://bugzilla.mindrot.org/show_bug.cgi?id=2252 Bug ID: 2252 Summary: RekeyLimit breaks ClientAlive Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=1379 Summary: memory leak in process_cmdline() Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: ssh AssignedTo: bitbucket at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=1432 Summary: MaxAuthTries is not used correctly Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: Solaris Status: NEW Severity: normal Priority: P3 Component: sshd AssignedTo: bitbucket at mindrot.org

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);

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?

Hi, So I screwed up when writing the support for the curve25519 KEX method that doesn't depend on OpenSSL's BIGNUM type - a bug in my code left leading zero bytes where they should have been skipped. The impact of this is that OpenSSH 6.5 and 6.6 will fail during key exchange with a peer that implements curve25519-sha256 at libssh.org properly about 0.2% of the time (one in every 512ish

Hello, I need to allow for some people to execute ssh with one shared private key for remote executing command on various machines. However, it is not possible to set group permissions for private keys and it is possible to have just one private key file for one user. Please, is it possible to add patches into openssh development tree like these, so that standard behavior of ssh is not changed,

Hi, OpenSSH 6.3 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains some substantial new features and a number of bugfixes. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is

hi, the man page for sshd(1) says about /etc/nologin: "The file should be world-readable". However, nologin has no effect if it's not readable by the connecting user: if (pw->pw_uid) f = fopen(_PATH_NOLOGIN, "r"); if (f) { /* /etc/nologin exists. Print its contents and exit. */ ... ... return(254) if root has a

hi all, we had quite a few requests recently so that SunSSH allowed to hush a banner on client side when in command-mode only. The argument usually is that the banner is mandatory due to legal reasons so first time login users should see it but that it causes problems when ssh is used from scripts after that. '-q' often seems not an option. RFC 4252 permits hushing banner in section

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

I'm wondering why the ChaCha20 cipher rekeys so frequently. At speed I'm seeing rekeys every second or two. So I'm spending a large amount of time in the rekey process. From what I've read about ChaCha20 it shouldn't need to be rekeyed quite so frequently. Am I missing something obvious? Just curious more than anything else. Chris

On Tue, 3 May 2016, Rogan Dawes wrote: > Hi Damien, > Thanks for the response! > > I tried moving the StreamLocalBindUnlink directive outside of the Match > rule, and it worked. But that doesn't explain why the Match was not > correctly setting the directive: > > This is running on an alternate port with -ddd: > > debug3: checking match for 'User