On 21.05.22 01:41, Nico Kadel-Garcia wrote:
I'm dealing with Azure DevOps git services with which recent, security hardened SSH clients on a RHEL 8 variant cannot stablish public-key based SSH links to the Azure Devops. Other RHEL 8 based systems work well. Conversely, Azure Bastion cannot use Azure key vault stored private SSH keys to access the same RHEL 8 based servers, though they can reach other hosts with the same private key and the same public key. I've also used the private SSH key, locally, to connect to the various servers.
In my experience, if you can run a plain "ssh -v" as the client, the output *does* include details about the problem *somewhere*. To wit:
$ ssh -v root@SomeOldBox
[...]
Unable to negotiate with SomeOldBox port 22: no matching key exchange > method found. Their offer: diffie-hellman-group-exchange-sha1,>
diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
$ ssh -v -o "KexAlgorithms +diffie-hellman-group14-sha1" root@SomeOldBox
[...]
Unable to negotiate with SomeOldBox port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss
$ ssh -v -o "KexAlgorithms +diffie-hellman-group14-sha1" -o "HostKeyAlgorithms +ssh-rsa" root@SomeOldBox
[...]
etc. etc.. If I had to *guess*, I'd say that the dissent is about the key vault somehow offering (only) ssh-rsa while the hardened RHEL now insists on rsa-sha2-* for a key algorithm ...Unable to negotiate with SomeOldBox port 22: no matching MAC found. Their offer: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160@xxxxxxxxxxx,hmac-sha1-96,hmac-md5-96
Regards, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev