Verifying BitFolk's SSH fingerprints
At some point or another you'll have a need to connect to a BitFolk host via SSH. For example, the Xen Shell is accessed via SSH. This article discusses how to verify the SSH fingerprints of BitFolk hosts.
SSH uses public key cryptography to, amongst other things, verify that the host you're connecting to is really the host you intended to connect to. As is always the case with public key cryptography though, the initial key exchange has to be done by some other secure method. SSH displays fingerprints so that you can easily verify that you're connecting to the correct place. If you've ever seen something like this:
$ ssh strugglers.net The authenticity of host 'strugglers.net (184.108.40.206)' can't be established. RSA key fingerprint is 3d:34:13:36:9e:10:ac:20:5c:a6:38:fa:e8:3e:a0:2a. Are you sure you want to continue connecting (yes/no)?
then you've seen an SSH fingerprint - it's the 3d:34:13:36:9e:10:ac:20:5c:a6:38:fa:e8:3e:a0:2a part.
In order to securely connect to the above host for the first time, you need to have been given the fingerprint in advance by some secure means so that you can compare it to the fingerprint that the server shows you. If you haven't then you are trusting DNS that this host is really the one that you intended to connect to. Most people just type yes and trust DNS.
SSH fingerprints of BitFolk hosts
Here's an OpenPGP-signed text file listing the SSH fingerprints of BitFolk hosts you might care about:
Console host vs. real host
Note that normally when connecting to your Xen Shell you would connect to the host username.console.bitfolk.com where username is the name of your BitFolk account. This is done as a DNS CNAME (an alias) to the real server that your VPS is on so that you only have to remember one hostname even if your VPS is moved to another server. SSH fingerprints aren't published for all of these aliases because there would need to be one for each customer account and they'd be changing all the time.
SSH doesn't follow the chain of CNAMEs and will always try to verify the hostname that you entered against its list of known host keys. You can work out which host your VPS is actually on and always connect to that, e.g. for the VPS account ruminant:
$ host ruminant.console.bitfolk.com ruminant.console.bitfolk.com is an alias for console.urquell.bitfolk.com. console.urquell.bitfolk.com is an alias for urquell.bitfolk.com. urquell.bitfolk.com has address 220.127.116.11 urquell.bitfolk.com has IPv6 address 2001:ba8:0:1f1::4 $ ssh email@example.com
The SSH fingerprint for urquell.bitfolk.com has been published, so you can verify this.
Alternatively you can use the HostKeyAlias directive in your $HOME/.ssh/config file to tell SSH to verify a different name:
Host ruminant.console.bitfolk.com HostKeyAlias urquell.bitfolk.com
Just bear in mind that if your VPS is ever moved to another server then you'll need to connect to (or alias) a different host.
BitFolk's SSH keys have also been published in Monkeysphere. This enables people to automatically verify SSH host keys as long as they're signed by someone inside their OpenPGP web of trust. It therefore requires you to be an OpenPGP user and have a web of trust that is developed enough. The typical implementation of OpenPGP in use on Linux is the GNU Privacy Guard (gnupg).
Here's an example of first connecting to ruminant.console.bitfolk.com with a Monkeysphere-enabled ssh. Unfortunately Monkeysphere doesn't yet support HostKeyAlias for its first verification (bug report for that), but once the host key is added this will be picked up by SSH's future verifications.
$ ssh firstname.lastname@example.org ms: processing: urquell.bitfolk.com ms: checking keyserver pool.sks-servers.net... ms: primary key found: 03D4BA140261D955 ms: * acceptable primary key. ms: * new key for urquell.bitfolk.com added to known_hosts file. This computer system is the property of BitFolk Ltd. Disconnect NOW if you have not been expressly authorised to use this system. Unauthorised use is a criminal offence under the Computer Misuse Act 1990. Communications on or through BitFolk's computer systems may be monitored or recorded to secure effective system operation and for other lawful purposes. Password:
The above has the log level for Monkeysphere cranked up to verbose; normally you'd only see the line "ms: * new key for urquell.bitfolk.com added to known_hosts file." which indicates that Monkeysphere was satisfied that the key for urquell.bitfolk.com both had a matching fingerprint and was also signed by someone that we trust. The host key gets added to the known_hosts file and will be subsequently verified regardless of Monkeysphere.
$ ssh -q email@example.com ms: processing: ruminant.console.bitfolk.com ms: checking keyserver pool.sks-servers.net... ms: no primary keys found. Password:
Being able to verify SSH host keys in Monkeysphere still relies on there being a trust relationship to one of the signatures on the keys. To begin with, keys are only signed by firstname.lastname@example.org (BF15490B) so if you don't have an OpenPGP trust relationship with this key then Monkeysphere probably does you no good.
Attempting to SSH to a host which has a matching but untrusted key would look like this:
$ ssh email@example.com ms: processing: zimmermann.mayfirst.org ms: checking keyserver pool.sks-servers.net... ms: primary key found: D52E4D49860E8F9C -------------------- Monkeysphere warning ------------------- Monkeysphere found OpenPGP keys for this hostname, but none had full validity. An OpenPGP key matching the ssh key offered by the host was found: pub 2048R/860E8F9C 2008-10-29 [expires: 2011-09-10] uid [ unknown] ssh://zimmermann.mayfirst.org sig! 1CF2D62A 2008-11-16 Micah Anderson <firstname.lastname@example.org> sig!3 860E8F9C 2009-03-07 ssh://zimmermann.mayfirst.org sig!3 860E8F9C 2010-03-09 ssh://zimmermann.mayfirst.org sig!3 860E8F9C 2010-09-10 ssh://zimmermann.mayfirst.org sig!3 860E8F9C 2008-10-29 ssh://zimmermann.mayfirst.org sig! D21739E9 2008-10-29 Daniel Kahn Gillmor <email@example.com> sig! 2861A790 2010-03-09 Micah Anderson <firstname.lastname@example.org> RSA key fingerprint is 81:96:13:3e:24:c9:3c:5b:3c:6d:55:ba:58:85:e9:9e. Other user IDs on this key: uid [ unknown] ssh://zimmerman.mayfirst.org -------------------- ssh continues below -------------------- The authenticity of host 'zimmermann.mayfirst.org (<no hostip for proxy command>)' can't be established. RSA key fingerprint is 81:96:13:3e:24:c9:3c:5b:3c:6d:55:ba:58:85:e9:9e. Are you sure you want to continue connecting (yes/no)?
Sign BitFolk's Monkeysphere keys
Assuming that you have logged in to a BitFolk host that has a published SSH host key and you've verified that it really is the host that you intended to log into, it would help if you would also sign the key and upload it to the key servers. That way, anyone who trusts your signature will also be able to verify the key.
You sign and upload these OpenPGP SSH host keys the same way that you sign and upload any other OpenPGP key, so we're not going to go into the details here. You need to read and understand the documentation for your particular implementation of OpenPGP.
Publishing your own keys
Anyone can publish any OpenPGP key. The only way to tell if a given key is really what it says it is would be to trust the signatures on it. BitFolk will not be publishing keys for every username.console.bitfolk.com mapping, but you can publish them if you wish. You'll need to revoke it and publish it again any time that it changes. Given that it will only be useful for the very first time that you connect to it, this seems like a lot of work, but there's nothing stopping you.
Obviously, if you should find some key out there for your username.console.bitfolk.com and you didn't create/sign it, you should be extremely cautious about using it for anything!
SSH fingerprints can also be stored in DNS. There is some support in various SSH clients for automatically requesting and verifying this.
This is not yet implemented at BitFolk because DNSSEC isn't yet implemented at BitFolk. Without DNSSEC you can't tell if the DNS answers you're receiving are correct. Once DNSSEC is implemented, SSH fingerprints will also be available in DNS.
Fingerprints of the SSH host keys for your VPS
BitFolk cannot publish the fingerprints of the SSH host keys of your VPS because BitFolk doesn't know what host name you will be using to connect to it.
BitFolk could conceivably publish a host key for the IP address literal that you use to connect to your VPS for the first time, but this would change even more often than the console host mappings, so it would be a significant administrative burden.
For VPSes installed on your behalf, BitFolk does of course have access to the SSH host key and could communicate the fingerprint to you in your setup email, which is also OpenPGP-signed. That isn't yet implemented.
The very first time you want to connect to your new VPS, you can still work around this by instead first connecting to the Xen Shell, since this is a host whose key you can verify.
- If you don't have the password for your BitFolk account you can do a BitFolk password reset to have a new one generated and emailed to you.
- Work out what your real console host is.
- SSH to it and verify its host key by any of the methods above.
- Use the console command to connect to the console of your VPS
- Log in to your VPS and display its host key fingerprint
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub 1024 62:4a:83:f4:3c:b4:ed:e1:ea:00:7d:be:96:b1:e5:7d /etc/ssh/ssh_host_rsa_key.pub (RSA)