> 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?

Personally, I'd like that feature a lot. That's exactly what I'd like the program to do for me - figure out what I should and shouldn't be using on both the client and server sides, and just take care of it. And displaying any suggestions about what changes could be made on the server side are helpful as well, since many of us run the server as well.

As long as you show what changes are being made and why, the user should be able to override it if they want to. I suppose the nagging thing could be a problem, but I'll leave it to you to figure out if there's a way to let the user mark it as ignored, or just display it every time, or whatever. I can't think of a good reason why someone wouldn't want to accept the change most of the time though.

Thanks,
Russell

Russell, I have an update and a new version I'd like you to try!

On the beta testing page, I've posted the new version along with some information about what's in it.  Please take a look and give it a try and let me know what you think.  Sorry this took so long, but somewhere in the middle of this I also decided it was a good time to migrate the website to a new platform.  What fun!

It's mostly what we discussed above, but I'd love your feedback on the prompts, language, wording, descriptions, suggestions, etc...  There are a few related web pages that you may be pointed to throughout the process.  I'd love your opinion on those as well.

To trigger the 'autoconfigure' functionality, modify your configuration so that all encryption algorithms are disabled, then try to connect.

Try it a few times, both ACCEPTING or REJECTING the recommendations.  Check out and review the web pages when/if the links come up

Check it out here:

Beta Testing - Celestial Software

Posted by: @bpence

↑

Russell, I have an update and a new version I'd like you to try!

Thanks, Brian! (And sorry for the delay.)

I tried out the beta and did all the tests you suggested. First of all, I like the changes a lot!

I disabled all of the encryption algorithms and it then suggested "AES 128 ctr" and "SHA2-512". I accepted the changes, and I could then see that it moved those two lines above the "disabled" line.

When I disconnected instead of accepting the changes, it listed the encryption algorithms available on each side.

A couple of questions:

1. I'm guessing that the algorithms it picks are the best choices from the options available?

2. It looks like if I accept the changes, it also saves them to the connection file? I suppose that's alright, although I guess I was a bit surprised. Maybe it's right though, I'm not sure. The other option would be to make the changes in the current session but then prompt the user to save them to the file if they didn't save them before closing the connection.

3. I like the "Compatible Algorithms" and "Supported Algorithms" web pages that are linked to if I don't accept the changes. My only nitpick there would be to maybe list the supported algorithms using the same names as in the program for clarity ("3des-ctr" vs "Triple DES ctr", etc.).

Overall, I think this is a great feature. Thanks!

Russell

Thanks for taking the time to review.  No bugs or crashes I hope?

1. Pretty much, yes.  And by 'best', we mean FIRST in the list.  So the lists generally are ordered from the most preferred at the top to the least preferred at the bottom.  Algorithm selection is well defined in SSH document RFC-4253.  If you get to the point where it actually DISPLAYS the server and client list, there was NOT something they could agree on, and the connection must disconnect.  From the RFC:

      encryption_algorithms
         A name-list of acceptable symmetric encryption algorithms (also
         known as ciphers) in order of preference.  The chosen
         encryption algorithm to each direction MUST be the first
         algorithm on the client's name-list that is also on the
         server's name-list.  If there is no such algorithm, both sides
         MUST disconnect.

2. It's good you noticed.  I did struggle with that one a moment.  As you said, the alternative is to NOT save.  Then, the user would be prompted before exit unless they'd disabled those prompts.  In the end, I decided if the user 'accepted' the changes, that was good enough to imply a save...  I could be convinced otherwise.  The is no 'right' except what FEELS right and consistent between what the user is being told and what the software DOES.

3. There are *two* versions of each name.  The 'friendly' name shown in the app and the technical name used in the protocol.  Usually, they're pretty close, with the exception of the hyphens vs spaces.   "Triple DES" is probably the exception.  Where they differ the most.  I wonder if I need to have both?  Otherwise, I'm more likely to just change friendly name "Triple DES ctr" to "3DES ctr"

		addAlgorithm(SSH2_CIPHER_BLOWFISH      ,L"Blowfish cbc"    ,"blowfish-cbc"  ,false , false);
		addAlgorithm(SSH2_CIPHER_TWOFISH256_CBC,L"Twofish 256 cbc" ,"twofish256-cbc",false , false);
		addAlgorithm(SSH2_CIPHER_TWOFISH128_CBC,L"Twofish 128 cbc" ,"twofish128-cbc",false , false);
		addAlgorithm(SSH2_CIPHER_CAST128       ,L"Cast 128 cbc"    ,"cast128-cbc"   ,false , false);
		addAlgorithm(SSH2_CIPHER_3DES_CTR      ,L"Triple DES ctr"  ,"3des-ctr"      ,true  , false);
		addAlgorithm(SSH2_CIPHER_3DES          ,L"Triple DES cbc"  ,"3des-cbc"      ,true  , false);