tlwiki/new/SSH.md

# SSH

----

## User-Specific Client Config

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:

```prettyprint
SendEnv LC_*				* Send all LC env vars to the host
AddKeysToAgent yes			* If asked to unlock a password-protected private
					-  key, automatically add that key to the ssh-agent
					-  so you no longer need to reenter the password 
					-  again this session

- Example Host Definition
Host foo				* Arbitrary String. Use this definition by running `ssh foo`
	HostName foo.bar.com		* Actual DNS Hostname or IP address of the server
	Port 12345			* Port number to connect to
	User thurstylark		* Username on the server to connect as
	IdentityFile ~/.ssh/id_rsa	* Private key to use for authentication
	ServerAliveInterval 300		* Interval in seconds before a keepalive packet is sent to the server
	ServerAliveCountMax 3		* Declare the connection dead after no response to this many keepalive packets
	HostKeyAlgorithms ssh-dss	* Use ssh-dss for host-key algorithm checking (ssh-dss is insecure. Use something else)
	KexAlgorithms +kex		* Add 'kex' to the list of Key Exchange Algorithms available for use. 
	StrictHostKeyChecking no	* Turn off Strict Host Key Checking for only this host (insecure)
	UserKnownHostsFile /dev/null	* Discard this hosts host key instead of storing in ~/.ssh/known_hosts (not recommended)
	VisualHostKey yes		* Always use randomart in place of host key sums
```

### Directive Notes

- `Host`
	- Can also refer to an actual hostname. See "Host-Specific Keys" below.
- `ServerAliveInterval` and `ServerAliveCountMax`
	- It's common for a firewall to cause problems keeping connections open, so tweaking these settings can help. See "Broken Pipe Remedy" below.
- `HostKeyAlgorithms`
	- 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`:

```prettyprint
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 cannot be spoofed. Do not use `TTYKeepAlive` messages for determining the quality or security of a connection! See `ssh-config(5)` for more info.

----

## SSH Host Configuration

### Google Authenticator