I was doing some testing were I needed to test an SSH server’s support for various key exchange algorithms. I know PuTTY for Windows supports the configuration of key exchange algorithms, but I was testing in a Command Line only VM environment that already had a number of Linux clients running. It’s not obvious from the ssh man page or my searches (I found one site that said it’s not possible), it turns out to be almost as straightforward as setting your cipher or MAC algorithm. Just use the
-o KexAlgorithms=<comma_separated_list_of_algorithms> option.
<comma_separated_list_of_algorithms> can be any of the following:
- ecdh-sha2-nistp256 – (elliptic curve nist-p256), limited support.
- ecdh-sha2-nistp384 – (elliptic curve nist-p384), limited support.
- ecdh-sha2-nistp521 – (elliptic curve nist-p512), limited support.
- diffie-hellman-group-exchange-sha256 – (discrete log bits are negotiated), limited support.
- diffie-hellman-group-exchange-sha1 – (discrete log bits are negotiated), limited support.
- diffie-hellman-group14-sha1 – (discrete log 2048 bits), should be good for now, and widely supported.
- diffie-hellman-group1-sha1 – (discrete log 768 bits), might not be strong enough, but widely supported.
Note: The elliptic curve algorithms are believed to be as strong or stronger than the standard Diffie-Hellman discrete log cryptography; however, they are newer and have not been as thoroughly analyzed.
Example: ssh -o KexAlgorithms=diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384 firstname.lastname@example.org
If you didn’t already know, ssh can be used to tunnel a single TCP port from the client to the server. I wanted to use this ability to prevent my site credentials and cookies from being sent in plaintext over the internet (since I’ve been trying to avoid paying for SSL/TLS). This works on Dreamhost, but should work on pretty much any shared hosting provider that allows you to ssh into the server.
In short it takes a few hacks to get everything to play together and requires super user privileges on the machine you are connecting from, but does not require any special privileges on the remote server.
First establish a specific subdomain (or alternative domain) to ssh into (for example ssh.tidgubi.com). This will prevent DNS conflicts with the main domains (www.tidgubi.com and tidgubi.com).
Next edit your local hosts file. Create entries so your computer resolves your webserver to your local machine (127.0.0.1 www.tidgubi.com).
Login with an administrator account or console session (for a long time I didn’t realize you could just open a console and type login <admin_account>).
Create an ssh tunnel between your computer and your webserver by running command sudo ssh email@example.com -L 80:www.tidgubi.com:80
This command breaks down as follows:
- sudo – requires root permissions to listen on local port 80
- ssh – run the ssh client program
- firstname.lastname@example.org – username and ssh server
- -L – specifies local port forwarding
- 80 – local port to listen for data on
- www.tidgubi.com – remote webserver. This is resolved by the ssh server, so it does not conflict with the hosts file change
- 80 – remote port to forward traffic to. Assuming you’re forwarding traffic to a standard webserver, this should be port 80
- This does not work well if you try to use a different local port, because different servers and web-apps redirect traffic differently and may override explicitly set ports in the URL
- This commands only forwards traffic coming from the local client. You can add the -g option to the ssh command if you want to allow other computers to send data to the webserver
- Ideally you can ssh directly into your webserver, so the forwarded traffic does not get sent out on any network once it is plaintext again.
Next use .htaccess to restrict access to administrative pages.