search for: ssh_set_newkeys

https://bugzilla.mindrot.org/show_bug.cgi?id=2942 Bug ID: 2942 Summary: minor memory leak in ssh_set_newkeys() Product: Portable OpenSSH Version: 7.9p1 Hardware: All OS: Mac OS X Status: NEW Severity: trivial Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: markus at b...

...#39;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? > > That looks to be accidental. > > The default rekey limit is set in ssh_set_newkeys(): > /* > * The 2^(blocksize*2) limit is too expensive for 3DES, > * so enforce a 1GB limit for small blocksizes. > * See RFC4344 section 3.2. > */ > if (enc->block_size >= 16) > *max_blocks = (u_i...

...struct sshcipher *); diff --git a/packet.c b/packet.c index a71820f..377f608 100644 --- a/packet.c +++ b/packet.c @@ -55,6 +55,7 @@ #include <poll.h> #include <signal.h> #include <time.h> +#include <util.h> #ifdef WITH_ZLIB #include <zlib.h> @@ -850,6 +851,7 @@ ssh_set_newkeys(struct ssh *ssh, int mode) const char *wmsg; int r, crypt_type; const char *dir = mode == MODE_OUT ? "out" : "in"; + char blocks_s[FMT_SCALED_STRSIZE], bytes_s[FMT_SCALED_STRSIZE]; debug2_f("mode %d", mode); @@ -917,20 +919,18 @@ ssh_set_newkeys(struct ssh...

...(const struct sshcipher *); diff --git a/packet.c b/packet.c index a71820f..377f608 100644 --- a/packet.c +++ b/packet.c @@ -55,6 +55,7 @@ #include <poll.h> #include <signal.h> #include <time.h> +#include <util.h> #ifdef WITH_ZLIB #include <zlib.h> @@ -850,6 +851,7 @@ ssh_set_newkeys(struct ssh *ssh, int mode) const char *wmsg; int r, crypt_type; const char *dir = mode == MODE_OUT ? "out" : "in"; + char blocks_s[FMT_SCALED_STRSIZE], bytes_s[FMT_SCALED_STRSIZE]; debug2_f("mode %d", mode); @@ -917,20 +919,18 @@ ssh_set_newkeys(struct ssh *ssh, int...

...> index a71820f..377f608 100644 > --- a/packet.c > +++ b/packet.c > @@ -55,6 +55,7 @@ > #include <poll.h> > #include <signal.h> > #include <time.h> > +#include <util.h> > > #ifdef WITH_ZLIB > #include <zlib.h> > @@ -850,6 +851,7 @@ ssh_set_newkeys(struct ssh *ssh, int mode) > const char *wmsg; > int r, crypt_type; > const char *dir = mode == MODE_OUT ? "out" : "in"; > + char blocks_s[FMT_SCALED_STRSIZE], bytes_s[FMT_SCALED_STRSIZE]; > > debug2_f("mode %d", mode); > > @@ -917,20 +919,18...

...c > index a71820f..377f608 100644 > --- a/packet.c > +++ b/packet.c > @@ -55,6 +55,7 @@ > #include <poll.h> > #include <signal.h> > #include <time.h> > +#include <util.h> > > #ifdef WITH_ZLIB > #include <zlib.h> > @@ -850,6 +851,7 @@ ssh_set_newkeys(struct ssh *ssh, int mode) > const char *wmsg; > int r, crypt_type; > const char *dir = mode == MODE_OUT ? "out" : "in"; > + char blocks_s[FMT_SCALED_STRSIZE], bytes_s[FMT_SCALED_STRSIZE]; > > debug2_f("mode %d", mode); > > @@ -917,20 +919,18 @@...

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

...uch file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory debug1: Host 'localhost' is known and matches the ED25519 host key. debug1: Found key in /home/bsradmin/.ssh/known_hosts:4 debug1: ssh_packet_send2_wrapped: resetting send seqnr 3 debug2: ssh_set_newkeys: mode 1 debug1: rekey out after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: Sending SSH2_MSG_EXT_INFO debug1: expecting SSH2_MSG_NEWKEYS debug1: ssh_packet_read_poll2: resetting read seqnr 3 debug1: SSH2_MSG_NEWKEYS received debug2: ssh_set_newkeys: mode 0 debug1: rekey in after 4294967...

...debug3: mm_answer_sign: entering debug3: mm_answer_sign: ecdsa-sha2-nistp256 KEX signature len=101 debug3: mm_request_send: entering, type 7 debug2: monitor_read: 6 used once, disabling now debug3: send packet: type 31 [preauth] debug3: send packet: type 21 [preauth] debug2: ssh_set_newkeys: mode 1 [preauth] debug1: rekey out after 134217728 blocks [preauth] ssh_sandbox_violation: unexpected system call (arch:0x40000028,syscall:403 @ 0x76ccaa66) [preauth] debug1: monitor_read_log: child log fd closed debug3: mm_request_receive: entering debug1: do_cleanup debug...

...struct sshbuf *out) +{ + return SSH_ERR_INTERNAL_ERROR; +} + +static int +uncompress_buffer_zstd(struct ssh *ssh, struct sshbuf *in, struct sshbuf *out) +{ + return SSH_ERR_INTERNAL_ERROR; +} +#endif /* HAVE_LIBZSTD */ + void ssh_clear_newkeys(struct ssh *ssh, int mode) { @@ -924,18 +1092,29 @@ ssh_set_newkeys(struct ssh *ssh, int mode) explicit_bzero(enc->key, enc->key_len); explicit_bzero(mac->key, mac->key_len); */ if ((comp->type == COMP_ZLIB || - (comp->type == COMP_DELAYED && + ((comp->type == COMP_DELAYED || comp->type == COMP_ZSTD) &&...

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

I hacked zstd support into OpenSSH a while ago and just started to clean it up in the recent days. The cleanup includes configuration support among other things that I did not have. During testing I noticed the following differences compared to zlib: - highly interactive shell output (as in refreshed at a _very_ high rate) may result in higher bandwidth compared to zlib. Since zstd is quicker

I added ZSTD support to OpenSSH roughly over a year 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