Did you know that you can navigate the posts by swiping left and right?

Better management of ssh config files

05 May 2015 . ssh . Comments #ssh #configuration

My ~./.ssh/config file was getting rather large and becoming a management nightmare. I have personal servers, work specific servers, domain wildcards global wildcards etc etc. I’d estimate I had close to 30 hosts in a single file.

I decided It would be better to split my master config out into smaller logical chunks and concatinate them all together everytime I call the ‘ssh’ command. This means I can easily find and logically order my Hosts in A way which works for me.

How does it work


Since ssh-client doesnt support an include style parameter in its .ssh/config file, i decided to create my own implimentation.

I split my configuration file into 4 logical chunks (there are more, but they’re business sensitive - but 4 will give you an idea):


cat ~/.ssh/conf.d/
 000-header
 100-personal
 200-work-related
 400-global


As you can see, ive used numbering to create an order in assending order. Applying the header first and finally the global config which holds the Host * config which get applied to everything, unless its been specified further up. Anything can go in the middle, or example I have chunk for only my personal servers and another one for work, effectively splitting them up.

You could use any logical arrangement here, location, IP address, server names etc. Allowing you to get granular if you wanted.

My ssh alias command calls cat \* across my ~/.ssh/conf.d/ folder; removes some vim comments to enable syntax highlighting; throws the generated file into ~/.ssh/config and Finally calls the ‘ssh’ command.

Heres what my zsh command alias looks like:


alias ssh="cat ~/.ssh/conf.d/\* |
sed '/vim: set/d' > ~/.ssh/config &&
chmod 0600 ~/.ssh/config && ssh"

Note: I added newlines to the code snippet so it was readable.

####What my Host blocks look like:


#####Heres my header file:


##################################################################
# SSH CONFIG FILE

# THIS FILE IS AUTOMATICALLY GENERATED - YOUR CHANGES WILL BE LOST.
# IF YOU NEED TO CHANGE IT, CHANGE CONFIGS IN ~/.ssh/conf.d/

# See ~/.ssh/conf.d/README.md for instructions


#####Global host configuration:


##################################################################
# Global SSH Config - applied to all ssh commands
Host *
    ## SSH keepalive and timeout Options ##
    ServerAliveInterval 60
    ServerAliveCountMax 5
    VisualHostKey yes

    ## Channel Control Multiplexer Options ##
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h:%p
    ControlPersist 4h

    ## Specify secure ciphers and MAC algorythms
    KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
    HostKeyAlgorithms [email protected],[email protected],[email protected],ssh-ed25519,ssh-rsa
    Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
    MACs [email protected],[email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,[email protected]

    ## Dont hash knownhosts, so zsh autocompletion can read them ##
    HashKnownHosts no

##################################################################


A quick note on my global config above, i do use control multiplexers, they’re not for everyone and if you don’t fully understand how they work, they can be quite painful to deal with. Instead of talking about ssh multiplexing, have a read of this blog post. I also specify a subset of secure Key Exchange and Host Key algorithms as by default there are some very insure ciphers enabled by default. Have a read of this blog post which explains secure vs insecure ciphers and how to enable them serverside/clientside. - Note not all sshd servers and versions support the above ciphers and some, github will need to specify some insecure ciphers in its host block.

I hope this post has been useful to someone and thought I’d share my setup.

In Summary


Yes theres most likely a better implimentation and yes you might see it as rough, but its a good start and good foundation to work from to make it better.

I’m still perfecting my ssh config setup and yet to run into any limitations or issues (one issue im sure i’ll encounter is rsync and scp as they wont update the config if they are called. I guess as long as I call ssh after an update, all will be good. - Im not planning on updating my config “that” often.

I’ll update here as I make better changes.