After a bit of research and discussion with Brian, I believe we found the issue.... Absolute 11.39 and earlier DO support SHA2 signatures, but only for host keys, not authentication keys. The missing piece is RFC-8308 that allows a server to communicate to a client that SHA2 signatures in AUTHENTICATION keys are preferred, or even available.

Beginning around OpenSSH 8.8, SHA1 signatures are disabled by default, which created an incompatibility with Absolute that we've now fixed in version 11.41

Check the download page for the new version.

Other solutions:
1. When creating the Linux 2023 instance, use an ED25519 keypair instead. ED25519 keys do not have the SHA1 problem
2. Configure OpenSSH to allow SSH1 in authentication (not recommended) (and no, I won't tell you how to do it ) 🙂

And thanks again to Brian H for bringing this to my attention!!!

One other thing I had to do to get Absolute Telnet working with Amazon Linux 2023...

After upgrading Absolute Telnet from version 10.16 to 12.16, it still wouldn't connect. I got error "disconnected: failed to negotiate client to server encryption algorithm".

I got it to work by going into the Connection Properties, Connection tab, SSH2 tab, Encryption button, and then in the Encryption list, moving "AES 128 ctr" above the disabled line.

Then, after connecting successfully, it showed this on the screen:

Negotiated Algorithms:
  Strict KEX         : Enabled
  Key exchange       : ecdh-sha2-nistp521
  Host Key           : ssh-ed25519
  Session encryption : aes128-ctr
  MAC                : hmac-sha2-512
  Compression        : none

Thanks for the help above.
Russell

Thanks Russell. It's possible what you're experiencing is a side-effect of upgrading from older versions. Can you try again creating a NEW connection file for Linux 2023? 'AES 128 ctr' should come enabled by default.

It's possible you had manually disabled the CTR encryption sometime in the past and just forgot? If you have an old connection file with CTR disabled, Absolute will NOT change those settings on its own, even if you upgrade versions. It presumes you did that on purpose and for a reason and will at best tell you the reason for the failure so you can adjust as necessary.

AES 128 CTR is ON by default in both 10.16 and 12.16, so this is the only thing that makes sense to me. Does that ring a bell?

MY takeaway from this is that maybe Absolute can improve the error message with some additional details about where and how to change the necessary settings. Possibly even offer to make them FOR YOU and retry the connection, but never without the user's knowledge and approval.

Brian

Hi Brian,

You are indeed correct, a new connection file has all encryption ciphers and MAC algorithms enabled. Nothing is below the disabled line. I'm sure the problem I had was because I started by copying an old connection file where I had disabled some of them for reasons I no longer remember.

Your comment about improving the error message is exactly what I was thinking as well. I'm familiar with Linux, but only familiar enough with encryption to be able to create key pairs and get them in the right directory to be able to login or transfer files. When I look at a connection trace, I see all the info, but I'd love for Absolute to give me some kind of summary saying what the server supports, what the client tried, what worked, what didn't, etc. That'd be fantastic.

Thanks,
Russell

I agree. This doesn't really point you in the right direction, does it?

disconnected: failed to negotiate client to server encryption algorithm

I've been working on this. Instead of just failing, Absolute now suggests a set of additional algorithms to enable to create set that the client and server can both agree on. Algorithms may be either key exchange, host key, encryption or MAC. And it requires confirmation from the user to continue, so we're not doing things without the users knowledge. Also contemplating whether to make this OPTIONAL, allowing the user to turn it on or off. Right now it looks a bit like this.

Or this if a compatible set can't be found. Of course, in this case, one of the following must be true: 1. The server needs to be reconfigured to offer up some additional compatible algorithms, which depending on your access and permission on the server may not be possible 2. Additional algorithms need to be implemented on the client, which happens from time to time as I become aware of these incompatibilities 3. Another client must be chosen until either 1 or 2 can be done.

I like these ideas a lot. I can see how they'll be very useful in figuring out the problem as well as fixing it.

I wonder if a warning might be added for certain algorithms that are old and no longer considered safe? For example, if the server only supported very old algorithms. Or in my case, where I was clearly using the same connection profile for many years, maybe it could tell me that I'd be better off moving a particular algorithm to the top of the list, or below the disabled line? I'm not sure how algorithms get updated when using the same profile for years but upgrading the program.

Thanks for the quick changes!
Russell

Yes and yes. It's still a work in progress, but that's the idea.

Generally speaking, a well-maintained sever will have already disabled the 'unsafe' ones before the client has a chance to. As long as there is still one remaining compatible algorithm both the client and server supports, you may not even notice.

By default, Absolute starts with every algorithm enabled for maximum compatibility with older servers. With the new auto-configure, that's going to change. We'll now start out with the un-safe ones disabled and appropriate warnings displayed if we have to go back to them.

You'd be surprised how many older servers are out there. Some servers for example are embedded in hardware and can't be changed without a BIOS update, etc.....

I'll let you know when something is ready in case you're interested in testing.

Brian

Sounds good. I'm definitely interested in testing. I use the program every day, and I also maintain several SSH servers, so it'd be interesting to experiment on both sides of the connection. I have a feeling I may need to disable a few old algorithms on the server side myself.

Thanks,
Russell

Interestingly, I've found very FEW formal deprecations of SSH algorithms

RFC-8758: Formal deprecation of IDEA cipher
RFC-9142: Formal deprecation of SHA1 KEX algorithms

Several 'best practice' considerations recommend deprecating all SHA1 MAC, but that's somewhat short of formal deprecation

I've made a pass through the algorithm precedence, which are 'disabled', and which are 'deprecated'.

In short, any algorithm can still be used, but appropriate levels of guidance are applied.

For example, if auto-configure has to enable a deprecated algorithm, you'll be warned:

But if it's already enabled, but deprecated, it'll tell you but otherwise continue without stopping. There is somewhat of a balance here between being helpful/informative and being annoying.

And at this point I'm wondering if it wouldn't also be helpful to auto-configure a 'better' algorithm if a user's selection is deprecated, still enabled, but a better option exists that is compatible with the server. This might be stepping over the line though. Notification that it's deprecated should be enough, shouldn't it?