diff --git a/capsulflask/templates/about-ssh.html b/capsulflask/templates/about-ssh.html index 8d8a80d..a6d7cbe 100644 --- a/capsulflask/templates/about-ssh.html +++ b/capsulflask/templates/about-ssh.html @@ -109,7 +109,7 @@ X.509 introduced the concept of a Certificate Authority, or CA. These CAs were supposed to be bank-like public institutions of power which everyone could trust. The CA would create a key pair on an extremely secure computer, and then a CA Certificate (the public side of that key pair) - would be distributed along with every copy of Windows, Mac OS, and Linux. Then companies who wanted to run a secure web server + would be distributed along with every copy of Windows, Mac OS, and Linux. Then folks who wanted to run a secure web server could generate thier OWN key pair for thier web server, and pay the CA to sign thier web server's X.509 certificate (public key) with the highly protected CA private key. Critically, issue date, expiration date, and the domain name of the web server, like foo.example.com, would have to be included @@ -258,8 +258,7 @@ Host key verification failed. So what are technologists to do? Most cloud providers don't "provide" a secure and reliable way to get the SSH host public keys for instances that users create on thier platform. For example, see this - question posted by a frustrated user trying to secure thier connection to a digitalocean droplet - . + question posted by a frustrated user trying to secure thier connection to a digitalocean droplet. Besides using the provider's HTTPS-based console to log into the machine & directly read the public key, most of the time, providers recommend using a "userdata script", which runs when the machine boots, to upload the machine's SSH public keys to a @@ -326,7 +325,11 @@ Host key verification failed. For more information on how to get started with Namecoin, see my Namecoin guide for webmasters. +
+
+ Cheers and best wishes,
+ Forest