Category: Geek Bits

Posted on

SecureCRT and a failed order of applied preferences

Update: The amazing folks at VanDyke have fixed SecureCRT so that if the session has a defined key, it is tried first; and if that key fails then agent keys are tried next.


The server has disconnected with an error. Server message reads:
A protocol error occurred. Too many authentication failures for ec2-user

Recently I was setting up EC2 instances for a client, and as such things go I wound up creating ssh keys for each of the EC2 regions in which I was working.  With each instance I created in each new region, I configured the specific connection profile in SecureCRT with the appropriate ssh key.  All was well, for a while.  And then I hit a brick wall.  I could spin up new instances, add them to SecureCRT, but I couldn’t connect to them.

Long story short, as I added each new ssh key, it was added to the “Agent Keys” that were automagically presented to each host.  What I didn’t expect, and what I consider to be a bit of a bug, is that the Agent Keys are presented first; even if the session profile specifies a key.  So, despite having configured a specific key for the session, my connections were failing because the X number of Agent Keys presented first exceeded MaxAuthTries in the sshd_config.

Many other ssh clients support Key Agent along with specified keys.  OpenSSH and PuTTY are two that come to mind.  OpenSSH will present Key Agent keys for auth, but if you specify “-i PATHtoKEYfile” that key will be presented first.

I reached out to support at VanDyke, the creators of SecureCRT.  I explained the problem, and asked if there was a configuration option for controlling the Key Agent/Session Key order; and if not I requested that this be filed as a bug.  I was told this “behavior is by design”.  Odd, since they constructed a video explaining how Session settings override Default settings; so it is obvious they understand that most specific takes precedent over less specific settings.  The same precedence should logically apply to auth keys, and it does with OpenSSH.  According to section 7.4.2.1 “Using Identities” in SSH, The Secure Shell: The Definitive Guide the described behavior is host specific identities, and then agent identities.

The quickie solution I used was to got to “Tools”/”Manage Agent Keys” in SecureCRT and clear out all the extraneous keys that had accumulated.  I hated doing this, as I was stripping out some of the ‘automatic smarts’ that I love about SecureCRT.  Still, it isn’t as bad as the kludge that Todd at VanDyke support suggested.  His suggestion was that I disable “Try All Agent Keys” in the SSH2.ini file.  Todd’s suggestion makes me wonder why I pay money for SecureCRT and all of its advanced features if their only way to deal with a problem is to have me disable those features.

Despite several days of emailing back and forth, and providing documentation showing that at least two of the major ssh clients process host keys before agent keys, the folks at VanDyke stand by their odd choice of ordering.  Todd has submitted a ‘feature request’ for me, and they refuse to treat this as a bug.  Next time my license is up for renewal I just might have to write a SecureCRT->JellyfiSSH config conversion tool…

Posted on

My first pass at using SecureCRT for OS X

Yes, SecureCRT for OS X is here. I have already found a few things I would fix, and here is my letter to VanDyke:

Suggestions for an OS X world…

One thing that Mac users expect, more so than Windows users, is interoperation between applications and existing OS X services. A prime example of this would be the Keychain, and for some applications the existing ssh client and config files.

I know that SecureCRT for Win32 has had to maintain its own known_hosts and key files, but that was because Windows did not have these built in to begin with. While it would be logically consistent to keep certain features as similar as possible between the Win32 and OS X versions, I would like to make a case for why you should leverage the native OS X functionality to improve the product on the OS X platform.

Right after installing, the first thing I noticed was that when I connected to a system I regularly use, I was prompted to confirm and save the host key. This tells me that SecureCRT is ignoring my existing ~/.ssh/known_hosts file, even though it exists and already contains the keys for all of the hosts I regularly connect to. I would strongly recommend that SecureCRT use the standard known_hosts file on OS X, rather than re-inventing the wheel. If you decide to make use of the known_hosts file, please do not just import it into your own db format; that will not solve the long term goals of application interoperability.

The second thing I noticed was that I was prompted for my password. This tells me that SecureCRT is ignoring my ~/.ssh/id_dsa file. Really? If the user already has existing ssh keys, why not make use of them? Again, I would suggest NOT just importing existing keys when detected. That won’t be useful later on down the road if the user updates their keys.

In fact, I tried to manually select my existing ~/.ssh/id_dsa file for a session, but the file browser options used by SecureCRT don’t allow me to see, let alone select, the .ssh directory. Sure, I could jump through hoops and create a non-dot-named symlink, but I shouldn’t have to.

I have no evidence whether you are already doing this, but I suggest integration with Keychain. Let me give you an example of Keychain integration. My ssh key has a password. I never have to type it in. As long as I am logged in as myself, the native ssh application polls Keychain for the key password, and it all happens behind the scenes. If someone were to copy my key file off my laptop, and try to use it, they would be prompted for my password. Again, this is functionality that didn’t exist in Windows and that if you utilize it in your OS X version you will make a better product.

Here is an example demonstrating why it is useful for SecureCRT to utilize existing ssh files, and OS X services like Keychain:

I use a file transfer program called Transmit. It supports ftp, sftp, webdav, and a huge list of other protocols. If I connect to a server that I already connect to via ssh using my ssh key, I need only enter the host name and my user name. It automatically checks known_hosts, and then uses my existing ssh key. It also either polls ssh, or the Keychain, I don’t know which, for my ssh key; so I don’t need to type it in as long as I am logged in as myself to my OS X box.

Multiple OS X programs all rely on the existing, industry standard, ~/.ssh/ configuration files. For SecureCRT to completely ignore these files and re-invent the wheel is counter-productive to developing on the platform.

This reminds me a lot of when SecureCRT first adde the feature to upload a user’s pubkey to the server. This feature required that the admin install VanDyke’s ssh server on the host system. I wrote to support and asked why, since they already had a shell open to the host, they didn’t just utilize the connection to issue a couple of shell commands so that they could send the pubkey over the connection and have the shell commands pick it up from STDIN and append it to the authorized_keys file. The response I got was “why would we do that?” The answer is two-fold: Increased compatibility and reduced development effort.

These are little things that OS X power-users take for granted, and since SecureCRT is geared towards power-users I wanted to recommend them. I know you guys are largely a Windows development house, so I hope my input as a sysadmin who heavily uses ssh based services on OS X can help make SecureCRT for OS X a better product.

-Chris

If you agree with me that my suggestions would lead to a better OS X offering, please write them as well at support@vandyke.com

[ad#adsense-horizontal]

I use Amazon affiliate links in some of my posts. I think it is fair to say my writing is not influenced by the $0.40 I earned in 2022.