A slightly-modified version of Steve Kemp's Xen Shell is provided so that customers may perform some administrative tasks on their VPS, such as booting, shutting down and accessing its console even when it's not running or has no networking capability.
Accessing the Xen Shell
Access details are provided in /root/PASSWORDS when your VPS is provisioned. These credentials are common to all BitFolk customer interfaces (such as this wiki).
To connect to your Xen Shell, ssh to email@example.com, where username is the name of your BitFolk account. If you wish to authenticate by SSH key instead of your BitFolk password then you may manage the list of SSH keys from the BitFolk Panel.
BitFolk's sshds listen on port 22 and port 922 (see below).
Being locked out
If you fail your login more than 10 times then your IP address will be firewalled off for 10 minutes from port 22. Port 922 is not subject to these lockouts.
SSH keys and "Too many authentication failures"
If you have many SSH keys in your agent then it might be presenting too many wrong ones first, and not giving you chance to log in. If you're experiencing this then you can work around it with IdentitiesOnly and specifying an identity file, as discussed in this SuperUser answer.
Using the Xen Shell
The Xen Shell is a character-based menu driven interface. It runs under GNU Screen so you can have multiple "windows" open at once, and if you disconnect then it will still be there when you connect again. This can be helpful if you want to issue Xen Shell commands in one window while watching your VPS's console in another.
The key bindings are as default for GNU Screen, so for example Ctrl+a then c will create a new window, Ctrl+a then a returns you to the previous window you were looking at, etc.
Using the console command will drop you into your VPS's console. This is similar to a serial console on a "real" server. In order to exit the console to get back to the main Xen Shell menu you need to type Ctrl+]. Alternatively you may find it more convenient to create a new window (Ctrl+a then c) which would start at the main menu. You could then toggle between console and menu with Ctrl+a then a.
The console will also allow you to use Magic SysRq keys using Ctrl+o. For example, the combination Ctrl+o then h will display the kernel's help for SysRq commands. SysRq commands can be useful in situations where your VPS crashes or becomes unresponsive even on the console: you might still be able to Sync, Unmount, and reBoot in these situations.
Will "destroy" damage my VPS?
destroy is roughly the equivalent of yanking the power on a "real" server; it isn't polite and has the potential for causing filesystem corruption, but it's unfortunately sometimes necessary with some types of problem. For example, if your VPS is in an OOM death spiral then it will be too busy swapping to be able to even shut down, so destroy would be your only recourse.
destroy is not intended to nuke your VPS or wipe your disks or anything. Suggestions for a less scary name for this command are appreciated.
Securing your Xen Shell
Someone who can log in to your Xen Shell can completely take over your account. As well as being able to shutdown and boot your VPS, they could also boot it into Rescue mode, giving full filesystem access, or just wipe it. Clearly, then, it is important to secure your Xen Shell from access by unauthorised persons.
By default access is available by SSH to TCP ports 22 and 922 using password authentication. It's therefore essential that you choose a strong passphrase, since there are constant dictionary attacks against SSH on port 22.
BitFolk does block access on port 22 after a certain number of authentication failures, but scanning activity has become so ridiculous that BitFolk may soon have to tighten up access further. Ideally BitFolk's SSH would not listen on port 22, but so far there has been some customer demand to be able to connect from networks that ban outgoing traffic to "unusual" ports.
Two factor authentication
If you opt in to two factor authentication (2FA) on the Panel's Security page then you will be required to supply a 6 digit one time code each time you log in to the Panel or the Xen Shell. Any TOTP client should work, such as Google Authenticator or 1Password.
Once 2FA is enabled you will need to be careful not to lose your TOTP device. Depending on the client used you may be able to take a copy of the key for re-importing into another device in the event of loss.
If you lose access to your 2FA device without a key backup then you will be unable to log in to the Panel or the Xen Shell. Email password reset for the Panel will also be disabled, so you will need to contact Support to ask for 2FA to be disabled. Support will take your use of 2FA as an indication that they should try hard to verify your identity, so there may be additional delay in disabling your 2FA.
SSH public keys
Since you access the Xen Shell by SSH, you can supply one or more SSH public keys through the Security section of the Panel and these will be added to your Xen Shell account.
Just adding keys on their own will only make things more convenient for you: password authentication will still be available so a weak password can still fall to SSH dictionary attacks. To make full use of SSH public keys you should disable password authentication.
Using an SSH public key will bypass two factor authentication.