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