This posting is about using the command-line ssh tool for relatively securely copying stuff around, and logging into devices. Many of the tips contained within are things I have had to pry out of the manual page for my own use and these notes are a way of keeping the information around without relying on my brain.
#1: It Comes With Windows
If you are running the latest version of Windows 10, you get the command-line versions of ssh and scp without dropping into the Linux shell :-
Of course you have been able to install ssh clients for Windows for years or even decades, but having it available by default is a big win. Particularly for Windows machines you don’t tweak with your favourite applications.
#2: Public/Private Key Authentication
This the first part of increasing security by only permitting key authentication so that password brute forcing attacks become impossible. With the assistance of an ssh agent (not covered here) or a passphrase-less key pair (not advisable), it is no longer necessary to enter a password.
Of course getting into this sort of thing can be very confusing especially as most instructions tend to get into far too much detail on the cryptography involved. To keep it simple, I shall avoid going on about the cryptography, and concentrate on how to get it to work.
The most important thing to remember about key authentication is that there are two keys – the private key (which should be kept as secure as possible on the client machine) and the public key (which is copied to the devices you want to connect to).
So to get started, you first need to generate a key pair, which can be done with ssh-keygen; this has lots of options, but at this point you can ignore them. After you enter the command, you can simply hit return at all the prompts to generate a key pair :-
Generating public/private rsa key pair. Enter file in which to save the key (/home/mike/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/mike/.ssh/id_rsa. Your public key has been saved in /home/mike/.ssh/id_rsa.pub. The key fingerprint is: SHA256:REMOVED mike@Michelin The key's randomart image is: +---[RSA 2048]----+ |=*+o .. .B*..=o | |o+++. . =+o. o+.| |.BE.+ + . = .| |o+=& . . . o | |. o + S . | | . | | SS | | . | | -- | +----[SHA256]-----+
Of course this is not ideal because there is no passphrase, but to get started with that’s fine. You can ignore most of this output (except for the first item in the following list) but just in case :-
- The key pair is saved in the files ~/.ssh/id_rsa (the private key) and ~/.ssh/id_rsa.pub (the public key). The permissions are usually generated properly, but just to be safe you may want to reset the permissions anyway: chmod 0400 ~/.ssh ~/.ssh/id_rsa; chmod u+x ~/.ssh
- The key fingerprint can be used to check that when you are connecting that the keys haven’t changed unexpectedly.
- Alternatively (and slightly more of a reasonable check) you can check the fingerprint using the “randoart”.
Of course on its own, it doesn’t do much good. You have to copy it into place onto the machine you wish to authenticate to :-
$ ssh username@server mkdir .ssh $ cat ~/.ssh/id_rsa.pub | ssh username@server cat ">>" .ssh/authorized_keys
Note the quotes around the “>>”; these are significant because you do not want the local machine’s shell to interpret them – they need to be interpreted by the remote machine’s shell. Normally I would simply “scp” the file into place, but appending to a supposedly non-existent file is safer – just in case it does exist and does contain public keys that are currently in use.
There are a whole bunch of options to the command, but the two most important ones are :-
- The -t option which is used to specify the key type to generate (dsa, rsa, ecdsa, and ed25519). This is mostly unnecessary, but some older and limited devices do not understand certain key types. And as time goes on, more key types will be declared “insecure”. So you may sometimes find the need to generate more secure keys. The simplest (but not very efficient) process for dealing with such situations is to generate a key for each key type and try each one in turn.
- The -f option which is used to specify the output filenames – the private key is saved under the name ‘filename’ and the public key under the name ‘filename.pub’.
#3: SSH Configuration File and Usernames
There are a ton of things that can be done with the ssh configuration file, but for this section I’ll stick with setting the username used to login to specific hosts – not because this is the most interesting thing that can be done, although it is quite useful.
The configuration file can be found (if it has been created) at ~/.ssh/config (with a system-wide version at /etc/ssh/ssh_config). Within that file, you can set global preferences, or host specific preferences :-
Username fred Host router Username admin Host dns* Username fxb Host ds-* web-* Username baileyf Host * Username fred
The first line (Username fred) instructs ssh to use the username ‘fred’ when no username is specified – ssh 192.168.77.98 effectively becomes ssh fred@192.168.77.87.
If you specify the same username within a Host section, the specified username is used for any hosts that the specification following the Host word. In the first case (“Host router”) the username “admin” will be used for any host called “router” but not “router.some.domain”.
In the case of the second clause, a wildcard is used which is very useful for specifying a range of hosts – the example can match “dns01”, “dns01.some.domain”, or even “dns02”. In fact the first Host section is an example of what you should not do – put in a single hostname without a wildcard because it will only activate if the hostname is specified exactly as given. Put a wildcard in there, and it will work whether you use a single hostname or use the fully qualified domain name.
You can also have more than one host specification – as in the “ds-* web-*” list.
And lastly you can (if you choose) use the Host declaration to specify a set of default values – in much the same way that configuration settings in the global context specify default values. Use whatever method you choose.
#4: Cryptographic Incompatibility
I have commented elsewhere on this, but basically the ssh developers have chosen to disable weak encryption by default. Personally I would prefer that ssh throw up huge warnings about weak cryptography, but what is done is done.
If you need to connect to something with weak cryptography, there are three potential ‘fixes’ to allow connections. Each of these is a keyword to add to a specific host section, followed by a specification of what ‘algorithm’ to add.
In each case, a connection attempt will give an indication of what is wrong together with an indication of what algorithm to include :-
» ssh admin@${someswitch}
Unable to negotiate with ${ip} port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
In this case, we can see that it is the KexAlgorithms we need to adjust and the algorithm we need to add is “diffie-hellman-group1-sha1” :-
Host someswitch* KexAlgorithms +diffie-hellman-group1-sha1
This can be repeated for Ciphers and (rarely) MACs.
#5: X11 and Port Forwarding
Run X11 gooey programs over an ssh connection? Of course .. why not?
This can be enabled on a host-by-host basis (it is off by default because it can be insecure) using the configuration file :-
Host pica* ForwardX11 yes
This is just a special case of port forwarding where a network port is connected (via the ssh session) to a remote network port. Port forwarding can be very useful – for example to access an internal web site temporarily that isn’t (and probably shouldn’t be) exposed with a hole through the firewall.
Of course this can be done with a VPN, but ssh may be simpler :-
Host pica* LocalForward 8000 8000
When the connection is made, a local port is opened (tcp/8000) and connected to tcp/8000 on the machine you are logging into.