Most directives that can be set in the system-wide client configuration can be set by each user in `~/.ssh/config`. This snippit contains a collection of my most used options:
- It's common for a firewall to cause problems keeping connections open, so tweaking these settings can help. See [Broken Pipe Remedy](#broken-pipe-remedy) below.
- ssh-dss is less secure than the alternatives/defaults. Only use this if necessary.
-`KexAlgorithms`
- I use this to add `diffie-hellman-group1-sha1` to the available Key Exchange Algorithms for connecting to older hardware that doesn't accept any currently allowed kex algorithms. Diffie Hellman is quite insecure, so please use caution.
-`StrictHostKeyChecking`
- Several servers I connect to are descrete servers, but they all are accessed through a single IP Address with a randomized port number. This allows me to continue connecting to the host without stopping to delete a line from `~/.ssh/known_hosts` before connecting.
### Host-Specific Keys
User-specific ssh configs make it stupid easy to create several keys for several different uses. For instance, this allows you to have a separate key for each service that you use, and allows you less headache should one key be compromised.
For example: Github allows you to push to your remote repositories over ssh by adding a public key to your account. Ideally, you should create a keypair for this specific purpose, and name it something like 'github'. Then you can add something like this to your `~/.ssh/config`:
```
host github.com
IdentityFile ~/.ssh/github
```
Now, when your repo's origin url is set to something like `git@github.com:username/reponame.git`, ssh will automatically use your github key instead of needing to specify it in the command, or using your username and password with HTTPS every time.
### Broken Pipe Remedy
Often times a firewall or inconsistent connection can cause an ssh connection to be closed prematurely and give a "Write Failed: broken pipe" error message. Some firewalls are configured to close connections that have sent no data after a certain interval, thus causing a broken pipe error when the connection was otherwise healthy. This can usually be solved by sending data through the connection before that interval is up, thus resetting the firewall's timer.
The `ServerAliveInterval` option sends a keepalive packet if no data has been received within the interval specified. All the keepalive packet does is request a response from the server to verify the connection is still good. By default, this option is disabled.
Additionally, the `ServerAliveCountMax` option specifies the number of keepalive packets that may be sent without a response before ssh terminates the connection. By default this is set to `3`, but if your connection is unreliable, you can set this higher to give your server a better chance at responding the next time a keepalive packet is sent.
> It is important to note that messages sent by the `TTYKeepAlive` option are not sent through the encrypted channel and can be spoofed, but the "server alive" messages are sent through the encrypted channel and can*not* be spoofed. Do not use `TTYKeepAlive` messages for determining the quality or security of a connection! See `ssh-config(5)` for more info.
