similar to: Legacy MACs and Ciphers: Why?

Displaying 20 results from an estimated 11000 matches similar to: "Legacy MACs and Ciphers: Why?"

2024 Jan 25
2
enable strong KexAlgorithms, Ciphers and MACs in /etc/ssh/sshd_config file on RHEL 8.x Linux OS
Hi, I am running the below servers on Red Hat Enterprise Linux release 8.7 (Ootpa). The details are as follows. # rpm -qa | grep openssh openssh-8.0p1-16.el8.x86_64 openssh-askpass-8.0p1-16.el8.x86_64 openssh-server-8.0p1-16.el8.x86_64 openssh-clients-8.0p1-16.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.7 (Ootpa) # How do I enable strong KexAlgorithms, Ciphers and
2024 Jan 25
1
enable strong KexAlgorithms, Ciphers and MACs in /etc/ssh/sshd_config file on RHEL 8.x Linux OS
Hi Kaushal, I maintain a set of SSH hardening guides for various platforms, including RHEL 8. You can find them here: https://ssh-audit.com/hardening_guides.html - Joe -- Joseph S. Testa II Founder & Principal Security Consultant Positron Security On Thu, 2024-01-25 at 18:39 +0530, Kaushal Shriyan wrote: > Hi, > > I am running the below servers on Red Hat Enterprise
2018 Nov 23
2
Debian Stretch 9.6: openssh-server and old dropbear client don't work togheter
Il giorno gio 22 nov 2018 alle ore 21:24 Stuart Henderson <stu at spacehopper.org> ha scritto: > > On 2018/11/22 19:55, owl700 at gmail.com wrote: > > Hi, I have compatibility issues with the latest version of > > openssh-server and an old dropbear client, the dopbear client stops at > > preauth > > > > ov 22 14:34:03 myhostname sshd[3905]: debug1: Client
2016 Sep 21
2
Where to look next?
Hello, I'm looking for your insight about the log below. We have an SFTP server (IBM Sterling File Gateway) and we're connecting from an OpenSSH SFTP client but something fails during KEX. Complete client-side debug output is below, but I believe the relevant part is: debug1: kex: server->client cipher: aes192-cbc MAC: hmac-sha1 compression: none debug1: kex: client->server
2025 May 13
5
[Bug 3823] New: SSH on same device ignores MAC restrictions
https://bugzilla.mindrot.org/show_bug.cgi?id=3823 Bug ID: 3823 Summary: SSH on same device ignores MAC restrictions Product: Portable OpenSSH Version: 10.0p2 Hardware: Other OS: Other Status: NEW Severity: major Priority: P5 Component: ssh Assignee: unassigned-bugs at
2015 Jan 07
4
[Bug 2333] New: forbid old Ciphers, KexAlgorithms and MACs by default
https://bugzilla.mindrot.org/show_bug.cgi?id=2333 Bug ID: 2333 Summary: forbid old Ciphers, KexAlgorithms and MACs by default Product: Portable OpenSSH Version: 6.6p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous Assignee:
2017 Nov 01
2
Winbind, Kerberos, SSH and Single Sign On
Hi, at first I'm not sure if this is the correct list to ask this question. But since I'm using winbind I hope you can help me. I try to realize a kerberized ssh from one client to another. Both clients are member of subdom2.subdom1.example.de and joined to it. The users are from example.de, where subdom1.example.de is a subdomain (bidirectional trust) of example.de and
2018 Apr 24
2
AIX make checks issue
On 23/04/2018 11:49, Michael Felt wrote: > On 21/04/2018 16:21, Michael Felt wrote: > > > Question: I have not dug into the tests yet. Will copy to a "local" > directory, and not build out of tree and see if that fixes it (as it > does for many other packages). However, just in case it does not - how > can I fast-forward the tests to the "agent" tests?
2017 Jun 13
7
[Bug 2729] New: Can connect with MAC hmac-sha1 even though it's not configured on the server
https://bugzilla.mindrot.org/show_bug.cgi?id=2729 Bug ID: 2729 Summary: Can connect with MAC hmac-sha1 even though it's not configured on the server Product: Portable OpenSSH Version: 7.5p1 Hardware: All OS: Linux Status: NEW Severity: security Priority: P5
2016 Sep 21
3
Where to look next?
Thanks for your suggestion! It seems to have gone a little further this time, but isn't accepting the key and is failing back on password-based auth. We're double-checking that the public key was correctly configured with the account, and also trying a DSA key to see if it behaves differently. Is there anything you'd suggest we look at or try at this point, and thank you very much
2016 Nov 08
4
one host only: ssh_dispatch_run_fatal
Darren Tucker <dtucker at zip.com.au> writes: > On Tue, Nov 8, 2016 at 2:43 PM, Harry Putnam <reader at newsguy.com> wrote: >> Darren Tucker <dtucker at zip.com.au> writes: >> >>> On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote: >>> [...] >>>> gv harry> ssh -vv 2x >>>> >>>>
2017 Jan 20
2
^C doesnt work on ssh session
Thanks Darren, will check on your response. I am attaching sshd, ssh logs with debug flags. Please see if it gives any hint: when I press ^C in ssh session, no log gets printed in both server/client side. Best Regards, On Wed, Jan 18, 2017 at 3:09 AM, Darren Tucker <dtucker at zip.com.au> wrote: > On Wed, Jan 18, 2017 at 5:10 AM, Sudarshan Soma <sudarshan12s at gmail.com>
2016 Aug 24
3
kex protocol error: type 7 seq xxx error message
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
2024 Jan 26
1
enable strong KexAlgorithms, Ciphers and MACs in /etc/ssh/sshd_config file on RHEL 8.x Linux OS
On 25.01.24 14:09, Kaushal Shriyan wrote: > I am running the below servers on Red Hat Enterprise Linux release 8.7 > How do I enable strong KexAlgorithms, Ciphers and MACs On RHEL 8, you need to be aware that there are "crypto policies" modifying sshd's behaviour, and it would likely be the *preferred* method to inject your intended config changes *there* (unless they
2018 May 25
5
Strange crypto choices
The defaults for HostKeyAlgorithms option are: ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com, ssh-ed25519-cert-v01 at openssh.com, ssh-rsa-cert-v01 at openssh.com, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-ed25519,ssh-rsa Why does OpenSSH prefer older and less secure
2017 May 02
2
playing around with removing algos
On Tue, May 02, 2017 at 06:17:47PM +0200, Cristian Ionescu-Idbohrn wrote: > $ ssh -vvv -oMacs=umac-64 at openssh.com localhost : 2>&1 | egrep -i 'macs|umac' > debug2: MACs ctos: umac-64 at openssh.com > debug2: MACs stoc: umac-64 at openssh.com > debug2: MACs ctos: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm
2025 Jan 20
3
[Bug 3779] New: SHA1 deprecation
https://bugzilla.mindrot.org/show_bug.cgi?id=3779 Bug ID: 3779 Summary: SHA1 deprecation Product: Portable OpenSSH Version: 8.4p1 Hardware: Other OS: Linux Status: NEW Severity: trivial Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter:
2016 Oct 18
7
SSH Weak Ciphers
Hi, In a recent security review some systems I manage were flagged due to supporting "weak" ciphers, specifically the ones listed below. So first question is are people generally modifying the list of ciphers supported by the ssh client and sshd? On CentOS 6 currently it looks like if I remove all the ciphers they are concerned about then I am left with Ciphers
2017 Jan 27
4
Notes on openssh configuration
Hello list, To my astonishment the openssh versions on both C6 and C7 will by default negotiate an MD5 HMAC. C6 client, C7 server: debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none C7 client & server: debug2: mac_setup: setup hmac-md5-etm at openssh.com debug1:
2016 Oct 19
2
SSH Weak Ciphers
Am 19.10.2016 um 00:58 schrieb Gordon Messmer <gordon.messmer at gmail.com>: > On 10/18/2016 03:28 PM, Clint Dilks wrote: >> So first >> question is are people generally modifying the list of ciphers supported by >> the ssh client and sshd? > > I suspect that "generally" people are not. I do, because I can, and so that I can offer at least some advice