VanDyke Software Forums

VanDyke Software Forums (
-   Secure Shell (
-   -   Unexpected public key authentication failure on arcfour cipher server change (

eewanco 05-05-2016 02:33 PM

Unexpected public key authentication failure on arcfour cipher server change
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-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

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


bgagnon 05-05-2016 03:02 PM

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 05-05-2016 03:22 PM

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.


bgagnon 05-05-2016 03:28 PM

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.

All times are GMT -6. The time now is 06:00 AM.