dns_ssh.md

DNS

• Domain Name System
• Basically just a bunch of tables maintained by Internet Service Providers around the world, mapping domains (e.g. google.com) with IP addresses
• The core type of DNS record is an A record. This maps a domain name to an IP address:

A example.com 93.184.216.34

• Another type of DNS record is a CNAME record, meaning Common Name (or CN). This links a name to another name, e.g.:

CNAME mysite.com mysite.herokudns.com

The purpose of CNAME records is usually to make an alias for a cloud service. For example, I could have a website at mysite.heroku.com, but that doesn't look very professional, so I create a CNAME like the example above.

CNAMEs are also useful when IP addresses change frequently, but the "service domain", i.e. mysite.heroku.com, is fixed.

The target of a CNAME may be another CNAME, but they ultimately must lead to an IP address. An IP address is always required, it's fundamental to the way the internet works.

E.G. mysite.com => mysite.herokudns.com => mysite.heroku.internal.cloud => ... => 123.456.789

• When you go to a domain in your browser, the first thing that has to happen is the domain name needs to be turned into an IP address (it's the only way for routers to know where data is supposed to go).

• So your browser will ask your router for the IP address of the domain, e.g. example.com.

  • If your router doesn't know, it will ask your ISP (e.g. BT Internet).
  • If they don't know, they will find where the site was registered, and ask them (e.g. Network Solutions).
  • Network Solutions will either have the answer, or will point to the Name Servers that are set for the domain (e.g. Cloudflare).
  • The Name Servers are the final step in the chain, as they hold the "official" DNS records for the domain.

• Name Servers and ISPs are always sharing the DNS records they have, so normally DNS requests don't have to go through the whole chain. 99% of the time, your ISP will already know the IP address of any given domain.

SSH hurdles

• Here is a list of things to check when SSH is not working:

1. Is the destination correct? This normally looks like user@domain:port, e.g. [email protected]:12345

• The user and domain are always required, and the port is generally required (it defaults to 22).
• If you see an ssh command that works that looks like ssh mysite - user and port missing - these values are probably in a config file somewhere.

2. How is authorization working? SSH either works with username/password or, more commonly, public/private keys. The source (e.g. your computer, or the Github action) holds the private key, and the destination holds the public key.

• When writing automation that uses SSH, username/password is not an option. This is because the only way to provide the password is through user input, and automation by definition has no user input. So you must set up public/private key authentication.

3. Private keys

• When you run an ssh command, it will search your user's .ssh directory for private keys. It will then automatically try to use these private keys to connect to the server. The .ssh directory on Mac is /Users/[username]/.ssh, and on Linux is /home/[username]/.ssh. (More generally, it is at ~/.ssh, as the tilde character ~ points to the user's home directory on any linux-like system.)
• You can see the keys that ssh is trying to use by adding -v to the ssh command, which means verbose. E.G. ssh -v [email protected]:12345. Here, you can check that ssh is trying to use the right key.

4. Public keys

• When an ssh request is received by a server, it compares the private key of the request to a list of authorized public keys. These authorized public keys are found in ~/.ssh/authorized_keys. On Linux machines, this will be /home/[username]/.ssh/authorized_keys.
• If your ssh command is failing, you can check that your public key is in this file. If it's not there, you must add it.

5. Host keys - "Host key verifcation failed"

• Servers that accept SSH connections will have a host key that identifies them. This is for security reasons: you're supposed to check these keys manually (but nobody does).
• ssh commands will check the "host key" of a server against a list of known host keys. Initially, this list will be empty. If the host is not found, ssh will ask you if you want to trust it (this is the question that everyone answers yes to).
• When writing automation code, it's not possible to answer yes to this question, as that requires user input. For this reason, we have to add the host key to the list of trusted hosts before we can connect.
• The list of trusted hosts is found in ~/.ssh/known_hosts. On Mac this will be /Users/[username]/.ssh/known_hosts and on Linux /home/[username]/.ssh/known_hosts. (I'd recommend getting used to the tilde character as you do more of this stuff!)
• There is a ssh command to get the host key, but what I normally do is connect over ssh from my machine, reply yes to the question, and then copy the host key out of ~/.ssh/known_hosts and paste it wherever I need it.

4. Summary of how we fixed the Github action

• Our ultimate aim was to connect over ssh and run the git pull command.
• The first question is always: how would I do this locally?
• So we looked at the local ssh command and copied that into the Github action.
• We also used ssh -v ... to find out that public/private keys were being used.
• For Github to connect, it needed its own public/private key pair, so we created that.
• We put the private key in a secret on Github, and the public key in the ~/.ssh/authorized_keys file on the server.
• Finally, we had the "Host key verification failed" error. To fix this, we took the host key out of our local file - ~/.ssh/known_hosts - and added that to the Github secrets.

Misc

• Open a directory on mac from the terminal:

cd the/directory/i/want
open .

• Alternatively use Cmd-Shift-G in Finder

• You can go to your home directory easily with:

cd

• That is, cd with no arguments. All these commands are the same:

cd /Users/joaquim
cd ~
cd