Let’s use a key pair to access a server at DreamHost with SSH from Windows.
As another quick note about our recent experience with moving some web hosting to DreamHost, I want to provide an anecdote about SSH and remote access to servers. My hope is mostly that what I learned can inform others who find themselves with a similar mystery at DH or elsewhere.
SSH is a wonderful tool. It leverages the infrastructure of secure socket connections provided by SSL/TLS to provide a secure connection to a (probably) remotely located machine. If you’ve dealt with any sort of *nix running a server, then odds are you’ve been able to use SSH to remotely log in.
These days, root access is typically restricted (if it is permitted at all) to SSH channels, or the physical console terminal.
DreamHost is not unusual in provided shell access on their server that can only be used with SSH.
Used in the simplest way possible, SSH only encrypts the channel, but you still have to log in to remote side with a username and password. That requires securely remembering the password, which can be inconvenient for scripts that manage multiple remote systems to automate repetitive tasks such as gathering log files or tweaking similar configurations.
So SSH provides an alternative to password authentication: a public/private key pair. You create a key pair, store the public key on the SSH server, and keep the private key, well, private. But stored locally in a way that your SSH client can find it when needed. Logging in is then a fully automated protocol where the server uses the public key to demand and get proof that the (local) client has the private key. If that is achieved, then the server can log you in.
DreamHost is one of many, many players in the space of shared web hosting. Their services extend upward to overlap with cloud computing providers and in many ways with rack space and colocation services as well. Even their entry level shared hosting accounts come with FTP and SSH access to a server running linux on a 64 bit platform.
As is typical, using SSH is dead easy, assuming you can create a key pair and upload the public key. You could actually create the key pair on the server and download the private key, but that is a bad habit to develop as it requires you to move the secret part off of the remote site and down to your private local site. While that might be safe enough if you can use SFTP or SCP to do the move securely, if you don’t have to take the risk, why take it.
If your local device runs linux, then your job is easy.
ssh-keygen will create a suitable key pair.
On Windows, no SSH client comes native to the platform. A traditional option is PuTTY, which provides all the related tools in addition to a terminal emulator. In particular, PuTTYgen is the utility that generates key pairs.
You will want to generate a 2048 bit RSA key pair for the SSH2 protocol. SSH2 allows a choice of RSA and DSA, but current wisdom is that DSA has some pitfalls so use RSA. Also, while the default of key length of 1024 seems strong enough, the US National Institute of Standards and Technology (NIST) effectively requires an RSA key be 2048 bits since 2013. There’s no real cost to creating a larger key here since it is only used once at each login. So longer is better.
The private key will be stored in a file name
id_rsa, and the public key in
id_rsa.pub. The names don’t matter all that much as long as you keep the private key private, and store it where you can find it to use with PuTTY, Tera Term, or any other SSH utility you have. (Those names reflect their default names on a linux client system, where they would be stored in the folder
id_rsa.pub file should be copied to the DreamHost server where you want to log in, and added to the file
~/.ssh/authorized_keys where the SSH Daemon will look for it.
Taking the usual care and using Tera Term combined with PuTTY’s Pageant, I had no problems creating a key pair and setting up the public key on DreamHost. After that, setting up a shortcut to launch Tera Term that would connect and log in automatically was easy.
What Went Wrong?
The one day it stopped working. Tera Term would connect, start to do the authentication, then simply fail and disconnect with a nearly useless error message, something akin to “authentication failed”.
After reviewing all the configuration steps, and comparing to other linux servers where similar setups continue to work just fine, I finally saw my issue mentioned in passing.
For security reasons, the SSH Daemon requires that only a single account can access the file
~/.ssh/authorized_keys (or the
.ssh folder itself, too). If you can log in to the account, then the command
chmod 700 ~/.ssh; chmod 600 ~/.ssh/* will set the permissions correctly.
But since there is always some friction with getting things set up, some versions of the SSH Daemon have been patched to allow less restricted permissions if your account is actually the only account that can access the files. Apparently DreamHost is running such a patched daemon.
My problem occurred after adding a second user to my hosting account so that the demo server described in an earlier post would not be sharing anything with any other servers I’m hosting there.
Due to the (otherwise completely reasonable) way that DreamHost manages multiple accounts, the new account belongs to the same Unix Group as the existing account. The default
umask is set to 0002 so
.ssh and its contents were both readable and writable to all accounts in the group. That made the number of accounts on the server that could potentially access my SSH keys be greater than one, and caused the daemon to no longer allow public key authentication.
The fix was easy. Log in to the account over SSH with a username and a password, then use
chmod to remove group access to the folder.
Note: this is a good reason to have a (strong) password on your account, even if you normally use public key authentication. Without a password, getting in to fix a problem like this might be much more difficult.
I am a happy new user of DreamHost. This article describes what I did to figure out what went wrong when SSH stopped working.
Watch for more posts about parking fossil on DreamHost as I find new tricks to talk about.
If you have a project involving embedded systems, micro-controllers, electronics design, audio, video, or more we can help. Check out our main site and call or email us with your needs. No project is too small!
+1 626 303-1602
Cheshire Engineering Corp.
710 S Myrtle Ave, #315
Monrovia, CA 91016
(Written with StackEdit.)