Wandering Thoughts archives

More on the Solaris ssh stuff (part 2)

As an update on the Solaris ssh stuff:

Sun has just today released version 08 of patch 114356, which fixes the 'xmalloc: zero size' problem (charmingly described in the patch README as 'New ssh in Sol. 9 exits if the key fingerprint cannot be found in the known_host files'), but not the problems with mech_krb5.so and the GSS stuff.

This is a good step forward, and it fixes the most important issue, since the xmalloc problem actually makes ssh unusable while the GSS stuff just spews noxious messages. But I remain not very happy with how long it's taken Sun to fix this ssh bug; 114356-07 was released on March 21st, which means it took just over three months. (I can't imagine a Linux distribution letting a trivially reproducible fatal ssh bug sit for three weeks, much less three months.)

Maybe Sun considers ssh an unimportant utility. If so, someone please disabuse them of this notion.

More on the Solaris ssh stuff

I discovered today that the unpatched Solaris ssh program doesn't understand the 'GSSAPIKeyExchange' and 'GSSAPIAuthentication' configuration options that are necessary to fix the problem on the patched ssh. (I had them in a $HOME/.ssh/config file that was shared between a patched system and an unpatched system.)

So what appears to have happened is that Sun developed a new version of ssh that implements the GSS stuff, and as a result requires it and the Kerberos stuff to be installed and configured and so on. This is the 'new' ssh included in patch 114356-07 (but not in the -06 version of the same patch) that requires 112908-24 ('SunOS 5.9: krb5, gss Patch').

Later, Sun saw some problems and yanked all mention of current versions of patch 112908 from the patchdiag.xref file, thereby making 114356-07 uninstallable without special magic. However, they did not actually withdraw either 114356-07 or 112908-24 (and in fact 114356-07 remains marked as a recommended patch).

(Some investigation also shows that installing patch 117177 (mentioned in the README for 114356-07) does not help the problem any.)

Impending changes to access to Solaris patches

Through the pca news page I found out some impending changes to access to Solaris patches. There are two changes:

• InfoDoc #83061 says that from mid-July, we'll need to register for a free Sun Online Account in order to get patches.
• InfoDoc #82023 says that Sun will be turning off anonymous ftp access to patches in late August.

I'm honestly not sure how these two interact, since it's hard to enforce having accounts with anonymous ftp.

However, pca currently retrieves patches (and the patchdiag.xref index file) via http, not anonymous ftp, so it will be affected sooner. (I'm not sure if it'll require a pca update, or if you'll just be able to plug in a Sun Online Account ID and password as if it was a SunSolve one.)

Moral: I should get registered soon and start experimentation, no matter how annoying it's sure to be.

It's somewhat ironic that I just finished writing up what I've worked out about the patchdiag.xref format so I can start using it for nefarious purposes.

Fixing the bad Solaris ssh patch

It turns out that there are actually three ssh problems introduced by the bad Solaris ssh patch. Since it's been well over a month with no sign or prospect of a fix from Sun, I gave in and applied workarounds. Fortunately, it turns out that all of problems can be made to go away with changes to /etc/ssh/ssh_config.

Ssh problem one is:

$ ssh host
dlopen(/usr/lib/gss/gl/mech_krb5.so): ld.so.1: ssh: fatal: /usr/lib/gss/gl/mech_krb5.so: open failed: No such file or directory

The minimal workaround for this in ssh_config is:

Host *
  GSSAPIKeyExchange no

Ssh problem two is closely related; it is:

$ ssh host
unable to initialize mechanism library [/usr/lib/gss/gl/mech_krb5.so]

This only appears if you have the SUNWkrbu package installed; problem one appears only if you don't. The ssh_config workaround this time is:

Host *
  GSSAPIKeyExchange no
  GSSAPIAuthentication no

Using both options is harmless for the first problem, so you might as well standardize on using both. As far as I know, these don't have any observable side effects if you're not using Kerberos (and if you are, you probably don't have either of these problems).

Ssh problem three is:

$ ssh host
xmalloc: zero size

This turns out to be caused by a bug in handling the 'ask' choice for the StrictHostKeyChecking option (which is the default setting). This means there are two solutions; you can either arrange to have known host keys for all the machines you'll want to talk to, or you can put the minimal workaround in ssh_config:

Host *
  StrictHostKeyChecking no

However, this workaround has a potential drawback: with this option set, new hosts have their host keys automatically added to your $HOME/known_hosts host key list, instead of you being prompted about it. (I'm not convinced that this is a big issue; in practice I always say 'yes' to this question anyways, and I'm already using this setting in some personal configurations.)

So the omnibus set of workarounds in /etc/ssh/ssh_config is:

Host *
  GSSAPIKeyExchange no
  GSSAPIAuthentication no
  StrictHostKeyChecking no

This also works in $HOME/.ssh/config, if you're on a system with this problem where you can't change the system ssh_config for some reason. Remember to add a cheery comment about why these options are set, so that in later months (or years) you can remember why they're there.