HP G7 MicroServer ILO SSH Connectivity

I recently pressed a G7 MicroServer back into service, and disccovered that I couldn’t connect to it over SSH. This seemed odd given that I am quite certain I remember doing so before. A quick nmap scan showed that the ssh port was definitely open on the ILO:

Starting Nmap 6.40 ( http://nmap.org ) at 2020-06-07 23:06 BST
Nmap scan report for 192.168.0.2
Host is up (0.0086s latency).
Not shown: 992 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
427/tcp open svrloc
443/tcp open https
2068/tcp open advocentkvm
5988/tcp open wbem-http
5989/tcp open wbem-https

Increasing verbosity on ssh connection (ssh -v), yielded some interesting insight, specifically:

debug1: match: OpenSSH_5.2 pat OpenSSH_5* compat 0x0c000000

So it could in fact be that more modern ssh tries to connect with ciphers and protocol options that the now relatively ancient OpenSSH 5.2 doesn’t quite understand. So I quickly grabbed OpenSSH 5.2 portable, built it and tried with that, and – success! Doing it again with verbosity turned up showed what ciphers and MACs were used. I added the following to my ~/.ssh/config:

Host 192.168.0.2
Ciphers aes128-ctr
MACs hmac-md5

And lo and behold, ssh-ing to the ILO from recent ssh on EL8 now works!

Hopefully this will save somebody some time in the future, or prevent them from throwing away what is still a perfectly usable microserver.

Windows 10 – the horror of upgrade to 1903+ releases

I had the misfortune the other day that one of my machines updated beyond 1809 release. There are three changes that immediately infuriated me.

1. Colour scheme change and removal of availability of black colour menus

The colour scheme changes upon upgrade. Not only is it a rather bright one going back to the ’90s style and contrary to dark themes that are easier on the eyes, laptop batteries and screen burn, but there is no way to full revert back. In order to get anywhere near black it is now necessary to disable the transparency effects, and even then it is still not black but dark grey.

Visually, this is a huge downgrade that cannot be fully mitigated or undone. And a bit of googling will show that I am far from the only one infuriated by this change.

2. File explorer grouping by default instead of continuing with previous default

As soon as you open your file folders after the upgrade, the files are now grouped by default. I can understand that this might be a new default setting, but on an upgrade, old behaviour should be preserved. If somebody chose not to view their files grouped, they should not be overriden by the upgrade and made to waste their time putting things back the way they were. Worse, this seems to revert the the new annoying default randomly.

Microsoft needs to understand that the ONLY reason why anyone uses Windows instead of a different operating system is long term inertia of familiarity. Chipping away at that familiarity will just push more users away from Windows and toward other operating systems. This is user alienation by a million paper cuts.

3. Start menu auto-expand

This one is incredibly annoying for a change so minor. There is supposedly a way to disable this using the mach2 tool, but it doesn’t seem to have worked for me – no matter what I do, I couldn’t get it to turn off and stay off.

Conclusion

So what did I do? Well, this is a VM – I refuse to run Windows on bare metal since over a decade ago, because it is too prone to getting itself into a state where various things break in a way that all the googlable solutions just don’t work and the only solution is to format and reinstall (windows update getting broken is a common show stopper). Being a VM, it doesn’t run on a real disk but a virtual one. I run my VMs on ZFS zvols, which are regularly snapshotted. So I powered off the VM, performed a zfs rollback to a pre-upgrade snapshot, and as if by magic, all of the damage done by releases after 1809 have been undone and things are back in a state where at least the new annoyances are gone. Best of all, zfs rollback took a few milliseconds instead of the lengthy rollback using Windows restore that probably wouldn’t have put things back quite to exactly the same state the machine was in before.

The upgrade will no doubt be forced on me at some point, in a way that I can’t avoid it any more. The feature upgrades can only be postponed by 365 days and disabled for another 30. But at least – today is not that day.

Plea to Microsoft

Please, for the love of God, stop changing things in ways that nobody asked for, nobody wanted, and nobody likes. Make your designers and developers learn from the fiasco of the ribbon interface.

Hardware Accelerated SSL on ARM – Redux

A long time ago, I posted an article about advantages of hardware accelerated SSL encryption, and how to get it working on Fedora Linux. Since then, some things have improved, and some things have regressed.

Improvements:

Regressions:

  • RedHat have broken OpenSSH with their audit patch. This is particularly inconsistent with the fact that the distro supplied openssh package in EL6 is built with the –with-ssl-engine option, to enable support for hardware crypto acceleration, yet this is clearly completely untested, which begs the question of what the point of it is.

Thankfully, the regression mentioned above can be fixed to make sshd work properly with hardware crypto offload.

Here are links to patched OpenSSL and OpenSSH packages for EL6, current at the time of writing this article:

http://ftp.redsleeve.org/pub/el6-staging/packages/soc/SRPMS/openssl-1.0.1e-30.el6.11.cryptodev.src.rpm

http://ftp.redsleeve.org/pub/el6-staging/packages/soc/SRPMS/openssh-5.3p1-104.el6.1.cryptodev.src.rpm

While ssh with using the blowfish algorithm in software is very fast and good enough for general purpose ssh usage, for some operations, such as transferring ZFS snapshots over ssh, using hardware offloaded AES provides a very welcome performance boost, because it leaves more CPU available for other processes.