+ In order to use our service, you will have to use the Secure Shell protocol (SSH) to connect to your capsul. +
++ SSH is a very old tool, created back when the internet was a different place, with different use cases and concerns. + In many ways, the protocol has failed to evolve to meet the needs of our 21st century global internet. + Instead, the users of SSH (tech heads, sysadmins, etc) have had to evolve our processes to work around SSH's limitations. +
++ These days, we use SSH + public-key cryptography to establish secure connections to our servers. + If you are not familiar with the concept of public key cryptography, cryptographic signatures, + or diffie-hellman key exchange, you may wish to see + the wikipedia article for a refresher. +
+ ++ Computers can generate "key pairs" which consist of a public key and a private key. Given a public key pair A: +
+ When computers A and B are trying to establish a secure connection for the first time, + we assume that the way they communicate right now is NOT secure. That means that someone between A and B can read & modify + all messages they send to each-other! You might be able to see where this is heading... +
++ When computer A sends its public key to computer B, + someone in the middle (lets call it computer E, or Eve) could record that message, save it, + and then replace it with a forged message to computer B containing public key E + (from a key pair that computer E generated). + + If this happens, when computer B sends an encrypted message to computer A, + B thinks that A's public key is actually public key E, so it will use public key E to encrypt. + And again, computer E in the middle can intercept the message, and they can decrypt it as well + because they have private key E. + Finally, they can relay the same message to computer A, this time encrypted with computer A's public key. + This is called a Man In The Middle (MITM) attack. +
++ Without some additional verification method, + Computer A AND Computer B can both be duped and the connection is NOT really secure. +
+ ++ Now that we have seen how key exhange works, + and we understand that in order to prevent MITM attacks, all participants have to have a way of knowing + whether a given public key is authentic or not, I can explain what I meant when I said +
++ > [SSH] has failed to evolve to meet the needs of our 21st century global internet +
++ In order to explain this, let's first look at how a different, more modern protocol, + Transport Layer Security (or TLS) solved this problem. + TLS, (still sometimes called by its olde name "Secure Sockets Layer", or SSL) was created to enable HTTPS, and allow + internet users to log into web sites securely and purchase things online by entering their credit card number. + Of course, this required security that actually works; if someone could MITM attack the connection, they could easily + steal tons of credit card numbers and passwords. +
++ In order to enable this, a new sub-protocol called X.509 was created. + X.509 is a standard related to the data format of certificates and keys (public keys and private keys), but it also defines + a simple and easy way to determine whether a given certificate (public key) is authentic. + 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 + 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 + in the x.509 certiciate along with the public key. + This way, when the user types https://foo.example.com into thier web browser: + +
+ This system enabled the internet to grow and flourish: + purchasing from a CA was the only way to get a valid X.509 certificate for a website, + and guaranteeing authenticity was in the CA's business interest. + The CAs kept their private keys behind razor wire and armed guards, and followed strict rules to ensure that only the right + people got thier certificates signed. + Only the CA's themselves or anyone who had enough power to force them to create a fraudulent certificate + would be able to execute MITM attacks. +
++ The TLS+X.509 Certificate Authority works well for HTTP and other application protocols, because +
+ However, this would never fly with SSH. You have to understand, SSH does not come from Microsoft, it does not come from Apple, + in fact, it does not even come from Linux or GNU. SSH comes from BSD. + Berkeley Software Distribution. Most people don't even know + what BSD is. It's Deep Nerdcore material. The people who maintain SSH are not playing around, they would never + allow themselves to be subjugated by so-called "Certificate Authorities". + So, what are they doing instead? Where is SSH at? Well, back when it was created, computer security was easy — + a very minimal defense was enough to deter attackers. + In order to help prevent these MITM attacks, instead of something like X.509, SSH uses a policy called + Trust On First Use (TOFU). +
+ ++ The SSH client application keeps a record of every server it has ever connected to + in a file ~/.ssh/known_hosts. +
+ ++ (the tilde ~ here represents the user's home directory, + /home/username on linux, + C:\Users\username on Windows, and + /Users/username on MacOS). +
+ ++ If the user asks the SSH client to connect to a server it has never seen before, + it will print a prompt like this to the terminal: +
+ +The authenticity of host 'fooserver.com (69.4.20.69)' can't be established. + ECDSA key fingerprint is SHA256:EXAMPLE1xY4JUVhYirOVlfuDFtgTbaiw3x29xYizEeU. + Are you sure you want to continue connecting (yes/no/[fingerprint])?+ +
+ Here, the SSH client is displaying the fingerprint (SHA256 hash) + of the public key provided by the server at fooserver.com. + Back in the day, when SSH was created, servers lived for months to years, not minutes, and they were installed by hand. + So it would have been perfectly reasonable to call the person installing the server + and ask them to log into it & read off the host key fingerprint over the phone. + After verifing that the fingerprints match in the phone call, the user would type yes + to continue. +
+ ++ After the SSH client connects to a server for the first time, it will record the server's IP address and public key in the + ~/.ssh/known_hosts file. All subsequent connections will simply check the public key + the server presents against the public key it has recorded in the ~/.ssh/known_hosts file. + If the two public keys match, the connection will continue without prompting the user, however, if they don't match, + the SSH client will display a scary warning message: +
++@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ +@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ +The ECDSA host key for fooserver.com has changed, +and the key for the corresponding IP address 69.4.20.42 +is unknown. This could either mean that +DNS SPOOFING is happening or the IP address for the host +and its host key have changed at the same time. +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ +@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ +IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! +Someone could be eavesdropping on you right now (man-in-the-middle attack)! +It is also possible that a host key has just been changed. +The fingerprint for the ECDSA key sent by the remote host is +SHA256:EXAMPLEpDDefcNcIROtFpuTiHC1j3iNU74aaKFO03+0. +Please contact your system administrator. +Add correct host key in /root/.ssh/known_hosts to get rid of this message. +Offending ECDSA key in /root/.ssh/known_hosts:1 + remove with: + ssh-keygen -f "/root/.ssh/known_hosts" -R "fooserver.com" +ECDSA host key for fooserver.com has changed and you have requested strict checking. +Host key verification failed. ++ +
+ This is why it's called Trust On First Use: + + SSH protocol assumes that when you type yes in response to the prompt during your first connection, + you really did verify that the server's public key fingerprint matches. + + If you type yes here without checking the server's host key somehow, you could add an attackers public key to the trusted + list in your ~/.ssh/known_hosts file; if you type yes blindly, you are + completely disabling all security of the SSH connection. + It can be fully man-in-the-middle attacked & you are vulnerable to spying, command injection, result-falsification, + the whole nine yards. +
+ +
+ 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
+ .
+
+ 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
+ trusted location, like Backblaze B2 or
+ Amazon S3[1] storage for later retrieval by users.
+ As an example, I wrote a
+
+ userdata script which does this
+ for my own cloud compute management tool called
+ rootsystem.
+ Later in the process, rootsystem will
+
+ download the public keys from the Object Storage provider
+ and add them to the ~/.ssh/known_hosts file
+ before finally
+
+ invoking the ssh client against the cloud host.
+
+ Personally, I think it's disgusting and irresponsible to require users to go through that much work + just to be able to connect to their instance securely. However, this practice appears to be an industry standard. + It's gross, but it's where we're at right now. +
+ ++ So for capsul, we obviously wanted to do better. + We wanted to make this kind of thing as easy as possible for the user, + so I'm proud to announce as of today, capsul SSH host key fingerprints will be displayed on the capsul detail page, + as well as the host's SSH public keys themselves in ~/.ssh/known_hosts format. + Users can simply copy and paste these keys into thier ~/.ssh/known_hosts file and connect + with confidence that they are not being MITM attacked. +
+ ++ Glad you asked 😜. +
++ TLS is great, except it has one problem: the X.509 CA system centralizes power and structurally invites abuse. + Power corrupts, and absolute power corrupts absolutely. But there is hope for the future: with the invention of Bitcoin + in 2009, we now have a new tool to use for authority-free secure consensus. Some bright folks have forked Bitcoin to produce + Namecoin, a DNS-like public blockchain which is + merge-mined with Bitcoin, and which allows users to + + register and trade names, including domain names + . In fact, Namecoin features a + + specification for associating public keys with domain names + + and easy-to-use client software packages capable of resolving these + names + & + + public + + + keys, + capable of replacing both the DNS system and X.509 Certificate Authority system. +
+ ++ For more information on how to get started with Namecoin, see my + + Namecoin guide for webmasters. + +
+ ++ [1] fuck amazon +
+ +{% for key in vm['ssh_host_keys'] %}
SHA256:{{ key.sha256 }} ({{ key.key_type }}){% endfor %}
-
+