similar to: [Bug 2268] New: VisualHostKey double printing with odd alignment

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2194 Bug ID: 2194 Summary: Supress VisualHostKey message when re-keying Product: Portable OpenSSH Version: 6.4p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at

https://bugzilla.mindrot.org/show_bug.cgi?id=1493 Summary: VisualHostKey suggestions Classification: Unclassified Product: Portable OpenSSH Version: 5.1p1 Platform: Other URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=49244 7 OS/Version: Linux Status: NEW Severity: normal

https://bugzilla.mindrot.org/show_bug.cgi?id=1870 Summary: Do not show VisualHostKey unless attached to a terminal Product: Portable OpenSSH Version: 5.5p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: unassigned-bugs at

https://bugzilla.mindrot.org/show_bug.cgi?id=1659 Summary: VisualHostKey and host key fingerprint aren't displayed when host's IP address is changed Product: Portable OpenSSH Version: 5.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh

https://bugzilla.mindrot.org/show_bug.cgi?id=1870 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|2130 | --- Comment #14 from Damien Miller <djm at mindrot.org> --- Removing target until OP shows up to test the

https://bugzilla.mindrot.org/show_bug.cgi?id=1870 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |2130 --- Comment #12 from Damien Miller <djm at mindrot.org> --- Retarget to openssh-6.4 -- You are

https://bugzilla.mindrot.org/show_bug.cgi?id=1870 Simon Deziel <simon at sdeziel.info> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simon at sdeziel.info -- You are receiving this mail because: You are watching the assignee of the bug. You are

My config file contains Host * VisualHostKey yes Host app VisualHostKey no however when I ssh into app I still see the VisualHostKey. It is my understanding that the more specific host should override the global defaults. When I asked on IRC they told me to report the issue to this mailing list. I know my version of OpenSSH is old, but I checked bugzilla and did not see any bug reports about

https://bugzilla.mindrot.org/show_bug.cgi?id=2521 Bug ID: 2521 Summary: subtract buffer size from computed rekey limit to avoid exceeding it Product: Portable OpenSSH Version: 6.8p1 Hardware: amd64 OS: Linux Status: NEW Severity: minor Priority: P5 Component: sshd

Hi, I am using OpenSSH_5.2p1. It seems ssh server doesn't support key regeneration after a specified amount of time. I manually verified the OpenSSH_5.2p1 and OpenSSH-6.2 source codes and haven?t found any code support for session rekeying in both releases. SSH2 supports session rekeying using the parameter ?RekeyIntervalSeconds? with default value 3600 seconds (one hour) in both

Using OpenSSL, is there a preferred/recommended rate of rekeying an encrypted stream of data? Does OpenSSL handle this for developers behind the scenes? Does it even need to be rekeyed? Thanks in advance. -sc -- Sean Chittenden -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 202 bytes Desc: not available

https://bugzilla.mindrot.org/show_bug.cgi?id=2573 Bug ID: 2573 Summary: dead sessions cannot be closed with ~. Product: Portable OpenSSH Version: 3.7.1p2 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

Hello, I apologize that this is slightly off topic. According to the Internet Draft I found for SSH ver 1 (draft-ietf-tls-ssh-00.txt from Jun 13, 1996), the client or server can send a SSH_MSG_KEXINIT at any time to force a new key exchange. I looked through the code for OpenSSH and ssh-1.2.27 and can't find where it does this. I then searched the Secure Shell mailing list archives and saw

Dear all, while playing around with openssh-4.1p1 (trying to add AFS token forwarding in SSH-2), I noticed that agressive rekeying (as e.g. employed by regress/rekey.sh, rekeying every 16bytes) seems to disturb the various forwardings (X11, agent) set up at the beginning of the session. These do not trigger regression test errors, since the client does not ask for confirmation from the server for

https://bugzilla.mindrot.org/show_bug.cgi?id=2929 Bug ID: 2929 Summary: OpenSSH server should not send the SSH_MSG_EXT_INFO message after rekeying Product: Portable OpenSSH Version: 7.7p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

Hi, mancha and me debugged a problem with OpenSSH 7.3p1 that was reported on the #openssh freenode channel. Symptoms were that this message was popping on the console during a busy X11 session: kex protocol error: type 7 seq 1234 I managed to reproduce the problem, it is related to the SSH_EXT_INFO packet that is send by the server every time it is sending an SSH_NEWKEYS packet, hence after

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

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