SecureCRT – The Wacky World of Chris Knight

2017/02/01

Has SecureCRT 8.1.0 got you down?

tl;dr – If you upgraded to SecureCRT 8.1.0 and your sessions are slow, globally change your font in all your sessions.

SecureCRT is hands-down my favorite secure terminal application on OS X, Windows & iOS. I’ve been using it since early 1998, and I have never found a better tool. That said…

This past weekend I got around to renewing my license so I could upgrade to SecureCRT 8.1.0. I even ponied up for a three year license / upgrade plan.

Withing a few minutes of upgrading, I knew something was wrong. Slow screen scrolling, slow pasting into sessions, absolutely intolerably slow trying to scroll back through my terminal buffer.

It was downright painful. So painful that I pulled version 8.0.2 out of my trash and ran it side by side. Tests using slo-mo video mode on my iPhone revealed that the new version was scrolling text at 1/5 of the speed of the old version. That’s a big steaming pile of no joy.

While I had no crash dumps, or forensic evidence of the issue, I shot off an email to support to let them know about the issue. I got a prompt reply, as I always do from VanDyke Software. Support was wonderfully patient with me. (If you have heard that doctors make the worst patients, then ya gotta figure that DevOps Security types make the worst customers of tech.) They hadn’t encountered the issue, and weren’t able to reproduce; but the back and forth willingness to keep working at the issue is one of the things that makes VanDyke Software an awesome company.

While trying to document a couple of different permutations of the issue, I stumbled onto the cause. In doing so, I also realize why the ubergeeks at VanDyke Software were not able to reproduce the issue. I’ve been running SecureCRT on OS X since version 6.6, and some of my existing session configs were originally created in that version, back in 2010. Who knows how many bits of my configs are functional, but not optimal. One of those non-optimal settings was apparently my font. When I globally changed my font, all my sessions sped up. But wait, there’s more… When I then globally changed my font back to the original setting, my sessions were still gloriously fast. How’s that? I diffed one of my old session configs against a newly ‘fixed’ config. Despite them both having the same font selected in the GUI they had slightly different font settings in the config. Something had changed in my font catalog, and while using the original data technically worked there was a noticeable increase in overhead to make it work. Functional, but not optimal.

If this helped you out, please let me know.

2013/06/172014/10/13

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…

2008/10/282008/11/06

SecureCRT on OS X!!!!!!

I have been using SecureCRT on Win32 systems for around a decade. It is by far the best SSH/Terminal application I have ever used. Sadly, there is nothing on OS X quite like it.

Sure, Leopard gave us tabbed browsing under OS X; but the ability to manage groups of tabs is, to say the least, crippled. JellyfiSSH gives us a nice menu for managing connections, but it in itself is limited. It won’t open new connections as a tab on an existing window.

I wrote an article a while back about getting SecureCRT working on CrossOver Mac, but that has its limitations as well. The majority of what I regularly need to do works, but there is a fair chunk of activities that just crash out.

Apparently I missed something in the last VanDyke News You Can Use newsletter. I missed a survey for OS X users. I missed the chance to raise my voice and say “I will buy it!”

Never fear though, for it appears that VanDyke is indeed embarking on this noble project!

——————————————
2. Survey Results – SecureCRT for Mac OS X
——————————————

Last month we surveyed you to learn more about how you use the Mac,
and what features you would like to see in SecureCRT for the Mac
platform.

Those of you who responded were not just home and educational
users: a significant number of corporate IT users were among the
participants, with a sizable portion in larger organizations. Job
titles tended to be technical, from IT managers to developers, with
some executives for good measure.

Not surprisingly, well over half of those who responded were
current Mac users. The same proportion say they will not be
running Windows on a desktop a year from now. As for their needs,
over half wanted to see the same session management and tabbed
interface that the Windows version offers.

The most surprising result was that over half of those who
responded said there was a trend in their organization to move
away from Windows within 12 months.

The survey is now closed, but we want to get your input during
initial development. Send your requirements and comments
directly to Maureen Jett, the SecureCRT product director, at
Maureen.Jett@vandyke.com.

This is FANTASTIC news! I can’t wait.

-Chris

ps. Now, if only the folks at Visual SlickEdit would get off their arses and write a Carbon/Cocoa native port of SlickEdit for OS X. Yeah, yeah, yeah… there is an X11 based port for OS X. Sadly, it falls into the same trap that SecureCRT under CrossOver Mac does: Some of it works the way you expect, and some doesn’t; and that is just too annoying to deal with at times.

[ad#adsense-horizontal]