System Administration

Connecting to legacy servers with OpenSSH

Phasing out legacy cryptographic algorithms can always be an interesting endeavor as terminating to early breaks stuff and to late it can lead to a compromise. OpenSSH disabled DSA with version 7.0 in March 2015 as 5 years earlier it was discovered that DSA was compromised and labelled as insecure. Normally this shouldn’t be a problem with a normal software life cycle, but sometimes you will encounter a legacy box that will not be upgraded as it will break things. Now it will stop new connections being setup from upgraded to machines as with SSH.

$ ssh Unable to negotiate with port 22: no matching host key type found. Their offer: ssh-dss

For an incidental connection from the command line the algorithm can be enabled again to connect with a legacy machine.

$ ssh -o HostKeyAlgorithms=+ssh-dss

For automated processed or when scripts can’t be modified a setting for OpenSSH can also be set in $HOME/.ssh/config for the account depending on this option to be set.


Re-enabling broken algorithms like DSA should only be done for a limited time and scope. In a lot of commercial environments these algorithms aren’t allowed to be enabled again. Also in most cases the code to run these obsolete algorithms can be removed in a later version as already is the case with SSL 3.0 and earlier for example.

System Administration

Using explicit SSH authentication methods

For many SSH is a magic sauce to get access to a server and to transfer files between servers. But when things go wrong this magic sauce becomes a problem. Let start with one example when things go wrong and how to debug it. First, we start to add to option -v to our command to connect to another server to get some basic debug information about the SSH handshake and getting to the point the user has to authenticate.

$ ssh -v
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: password's password:

Just before the SSH-client prompts for the user’s password two interesting debug lines are shown. The first line is about the authentication methods we can use and the next line shows our client selected method password as we don’t have any methods configured in our SSH-client like publickey. So we manually disable publickey authentication and set the preferred authentication methods to keyboard-interactive.

$ ssh -v -o PreferredAuthentications=keyboard-interactive -o PubkeyAuthentication=no
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

We now get permission denied as our client doesn’t have a matching set of authentication methods. Over a decade ago some commercial SSH-servers would require keyboard-interactive as authentication method as the client must then ask the user to type in the password instead of getting it from a password file as was allowed with the password authentication method. Allot of SSH-clients start to ignore this convention, but some enterprise environments still depend on this convention. If we add a password to the list of preferred authentication methods we see the password prompt is offered again.

$ ssh -o PreferredAuthentications=keyboard-interactive,password -o PubkeyAuthentication=no's password:

This method can also be used to temporarily disable public-key authentication without changing any SSH configuration to test of the account is still working correctly or the password of the target account is still working.

Internet, Unix en security

Port Forwarding met SSH

Uit veiligheid wil je soms niet elk protocol zomaar over Internet transporteren of verkeer door firewalls te krijgen. Zo ook met MySQL bijvoorbeeld, want packetfilters en SSL-verbindingen zijn ook niet echt ideaal om protocollen te beperken of te beveiligen. Gelukkig levert SSH een mooie tijdelijke oplossing in de vorm van portforwarding. Met het volgende commando wordt al het verkeer naar de lokale poort 3306 aan de andere kant van de tunnel verzonden naar localhost op port 3306.

$ ssh -L 3306:localhost:3306 remote.server

Als dit vaker moet plaats vinden dan is het onderstaande op te nemen in ~/.ssh/config, waarna de tunnel wordt opgezet op het moment dat je verbinding maakt met de remote.server.

Host remote.server
LocalForward 3306 localhost:3306

Het is belangrijk om te beseffen dat die tunnel niet exclusief voor jouw is. Als er andere gebruikers zijn op het systeem van waar je verbinding maakt dan kan dit een security probleem zijn.