Unexpected public key authentication failure on arcfour cipher server change

[eewanco]

I am tightening up security on our server product by removing the three arcfour ciphers (arcfour, arcfour128, and arcfour256). When I did this, SecureCRT started throwing an error when I log in, saying: 'Public Key Authentication Failed: Public-key authentication with the server for user root failed. Please verify username and public/private key pair.'

Given that I am not using public key authentication (although it is enabled, listed second in preference after password authentication, which is what I am using) I am surprised to see this. It logs in OK when I "skip" the dialog. If I disable public key authentication it works. If I add my SecureCRT public key to .ssh/authorized_keys it works. What does this have to do with my arcfour change?

I tried deleting the host key to no effect. I am less interested in solving this problem than I am in understanding it, because if I get the error, a customer may potentially have issues or annoyances, and I don't want that. However solving the problem might help me assess whether to introduce this change or not.

I am using OpenSUSE 13.1 openssh-6.2p2-3.7.1 on the server side. If I use OpenSSH_7.2p2 (OpenSSL 1.0.2g) or PuTTY 0.67 on the client side, I see no issues. I am using SecureCRT 8.0.1.

My OpenSSH sshd_config configuration includes:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

(I am aware that the CBC ones are insecure.)

Thanks!

[bgagnon]

Hello eewanco,

What does this have to do with my arcfour change?

It does not, I believe it is completely coincidental.

Did you connect to this server prior to disabling those ciphers *with the exact same client configuration* without getting the public-key auth error?

It's possible the server actually supports keyboard-interactive authentication method, *not* password. So SecureCRT failed password auth, went on to the next auth method (public-key) in the list and when you *skipped* that authentication method, it went on to use keyboard-interactive (likely the third option in the list).

What the server supports as far as authentication methods will be shown in trace options output (File menu).

[eewanco]

Well, yes I did use exactly the same configuration both times, in that I am certain I did not change anything, but I have to stand down because when I restored the arcfour cipher, it still didn't work. So you're right, it's a coincidence. Also I confirmed your theory that it is using keyboard-interactive, not password, authentication, so that explains why it was attempting public-key authentication first. Why it succeeded before, I don't know as I haven't even had keys installed on the server -- in fact I had just done one of many bare-metal installs since last having keys installed. I was, by the way, using SecureCRT 8.0.0 when I first tested it, and upgraded to see if that would fix it. Maybe that explains the behavior.

The trace suggestion was helpful.

I can't explain what happened but I'm satisfied that it is independent of the cipher change. I should have thought to change the cipher back immediately and test that.

Case closed. Thanks for the quick response and the excellent help as usual.

Eric

[bgagnon]

Hi Eric,

Thanks for the update. You are quite welcome.

If you want to tailor the authentication methods to match what's supported on the server, you can reorder them via the arrow buttons provided in the Connection / SSH2 category of Session Options in the Authentication grouping.