Some web hosting providers, even if their servers use Linux, are Windows-centric in their customer support. This was a difficulty for me when I had to access the server using ssh to do some security maintenance. In case you are having the same difficulties, I will share what I have learned in case it is helpful to you.
ssh or secure shell access is a method of transmitting a password over an encrypted connection. The encryption uses the private/public key pair. In this use case of connecting to a remote computer, the public key will stay on the remote computer and the private key will be on the local computer. The local computer will use an ssh client and the remote computer will have an ssh daemon to monitor connection requests.
This guide will describe the simplest process required to enable and use ssh access to the web server, which involves using the hosting company's implementation of cPanel for some of the steps. There are methods to do all of this completely on the local computer on the command line, but it is not as simple. I have provided a link to instructions for this process below.
Generate, Authorize, and Download Keys
The first step will be to generate and authorize the keys on the server using cPanel. There may be different encryption algorithms available, with a choice of different length keys. My hosting provider had RSA and DSA encryption algorithms available with key lengths of 1024, 2048, and 4096. The default settings for my provider are 1024 bit DSA, and a default key name of id_dsa. All of this can be changed, so I chose RSA encryption for faster log in and 4096 bit key length for stronger encryption. I also changed the key name to id_rsa_ssh_4096, which will require some more specific settings when using the ssh client.
- Log into the cPanel of interface of your account.
- In the security section of the main cPanel page, click "SSH/Shell Access".
- The page that opens will have a button "Manage SSH Keys" as well as other links to tutorials, and a java based ssh client (depending on the cPanel implementation of the provider). Click the "Manage SSH Keys" button.
- On the next page click "Generate a new Key".
- Enter a password in the "Key Password". This is used when logging into the server. Somewhere on my hosting providers forums, it was suggested to not use the Password Generator on this page, so I didn't use it. Verify the password in the "Password (Again)" field.
- Select the encryption type in the "Key Type" drop down. Select the key size in the "Key Size" drop-down.
- Then click the "Generate Key" button. When the "Key Generation Complete!" message appears. Click the "Go Back" button.
- The page displayed now is the same one as after clicking "Manage SSH Keys." This time the generated keys will be shown. The public key in the "Public Keys:" section and the private keys in the "Private Keys:" section. Under "Actions" in the "Public Keys:" section click the "Manage Authorization" link.
- In the page that opens click the "Authorize" button. After the confirmation that indicates the "key_name.pub" has been authorized (the .pub indicates that this is the public key of the private/public pair), click the "Go Back" button.
- The "Manage SSH Keys" page will now show "authorized" under "Authorization Status".
- Then click "View/Download" under the "Private Keys:" section to save it on your computer. After I downloaded my private key, I deleted the it from the server by clicking the "Delete" button in the "Private Keys:" section. This is the key that must be safeguarded.
Change the key name in the field "Key Name", if you like. You will have to remember this for later. If you want to keep it simple but want to use RSA instead of DSA, I would use id_rsa.
The rest of the steps will be on the local computer and will require installing openssh and configuring it.
If openssh is not installed by default in your distribution, you will need to install it. On all of the distributions currently installed on my multi-boot system, all except Arch and Manjaro had ssh by default. The levels of pre-configuration does, however, differ on the other distributions (NixOS, openSUSE, Rosa, Sabayon, Tanglu, and Ubuntu/Voyager).
Arch or Manjaro
There are many packages offering ssh on Arch or Manjaro when including AUR.
I chose to install the basicopensshpackage from the official repositories.
.sshDirectory and ssh Client Configuration File
The~/.sshdirectory contains the per-user ssh configuration file. This will override the system-wide configuration file located in/etc/ssh.~/.sshwill also contain the private key for connecting to a remote computer, so move the private key downloaded from cPanel to this folder.
As mentioned before, the level of preconfiguration varies on the various distributions. One variation is whether the necessary directory~/.sshis created as part of the installation. If not create this directory. Of the above mentioned distributions which had ssh installed already, only Sabayon and Tanglu had the~/.sshcreated, although they were empty. Once the~/.sshthe per-user configuration file for using ssh to connect to remote computers namedconfigis created in the directory. Note that there could be other configuration files in here, for example a per-user configuration to connect to the computer from a remote location; the system-wide version of this configuration file is/etc/ssh/sshd_config. The per-user version of this file is not necessary for the purpose of connecting to a remote computer.
So the process will be:
- Create the ~/.ssh directory if it does not exist.
- Create the per-user configuration file for connecting to remote computers by using the system-wide configuration file as a starting point by copying it to~/.sshwith
cp /etc/ssh/ssh_config ~/.ssh/config
- Edit~/.ssh/configas appropriate for the key settings created in cPanel. The configuration I use is presented below.
The/etc/ssh/ssh_configfile I copied to~/.ssh/configis just a skeleton in the two distributions where I set up the ssh to my shared web server -- Arch and Manjaro. It has the most common options, but all of the options are commented out. Compare this to the Tanglu version in the second code block below which has some options pre-configured system-wide. The edited version of~/.ssh/configI used in both Arch and Manjaro in presented below.
# This is the per-user ssh client configuration for this user. # # The contents of this file below this comment is copied from # /etc/ssh_config and edited as appropriate. # # $OpenBSD: ssh_config,v 1.28 2013/09/16 11:35:43 sthen Exp $ # This is the ssh client system-wide configuration file. See # ssh_config(5) for more information. This file provides defaults for # users, and the values can be changed in per-user configuration files # or on the command line. # Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file # Any configuration value is only changed the first time it is set. # Thus, host-specific definitions should be at the beginning of the # configuration file, and defaults at the end. # Site-wide defaults for some commonly used options. For a comprehensive # list of available options, their meanings and defaults, please see the # ssh_config(5) man page. # Host * # ForwardAgent no # ForwardX11 no RhostsRSAAuthentication yes RSAAuthentication yes # PasswordAuthentication yes # HostbasedAuthentication no # GSSAPIAuthentication no # GSSAPIDelegateCredentials no # BatchMode no # CheckHostIP yes # AddressFamily any # ConnectTimeout 0 # StrictHostKeyChecking ask # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_dsa IdentityFile ~/.ssh/id_rsa_ssh_4096 # IdentityFile ~/.ssh/id_dsa # Port 22 # Protocol 2,1 # Cipher 3des # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc # MACs hmac-md5,hmac-sha1,email@example.com,hmac-ripemd160 # EscapeChar ~ # Tunnel no # TunnelDevice any:any # PermitLocalCommand no # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com # RekeyLimit 1G 1h
The changes I made to the file are as follows:
- Uncommented# RhostsRSAAuthentication noand changed thenoto yes.
- Uncommented# RSAAuthentication yes.
- AddedIdentityFile ~/.ssh/id_rsa_ssh_4096. Note that this corresponds to the name of the key file that I chose when generating the key in cPanel. The original file has identity files for the default RSA and DSA key file names already, but commented out. Had I not changed the name of the key file, I would have only had to comment out the appropriate line corresponding to the default key file.
As mentioned above, even if most of the distributions install openssh by default, the configuration is different. Compare the above configuration file from Arch/Manjaro, modified from the system-wide configuration as indicated with the one from Tanglu displayed in the following code block.
# This is the ssh client system-wide configuration file. See # ssh_config(5) for more information. This file provides defaults for # users, and the values can be changed in per-user configuration files # or on the command line. # Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file # Any configuration value is only changed the first time it is set. # Thus, host-specific definitions should be at the beginning of the # configuration file, and defaults at the end. # Site-wide defaults for some commonly used options. For a comprehensive # list of available options, their meanings and defaults, please see the # ssh_config(5) man page. Host * # ForwardAgent no # ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes # PasswordAuthentication yes # HostbasedAuthentication no # GSSAPIAuthentication no # GSSAPIDelegateCredentials no # GSSAPIKeyExchange no # GSSAPITrustDNS no # BatchMode no # CheckHostIP yes # AddressFamily any # ConnectTimeout 0 # StrictHostKeyChecking ask # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa # Port 22 # Protocol 2,1 # Cipher 3des # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc # MACs hmac-md5,hmac-sha1,firstname.lastname@example.org,hmac-ripemd160 # EscapeChar ~ # Tunnel no # TunnelDevice any:any # PermitLocalCommand no # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com # RekeyLimit 1G 1h SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication yes GSSAPIDelegateCredentials no
Notably, the Tanglu default system-wide configuration doesn't comment out theGSSAPIAuthentication yesand enables it by default. A version of openssh with a similar configuration is available from the AUR for Arch/Manjaro. Other differences among the distributions are evident in the following table.
Connecting to the Web Server
In this case the remote computer is a shared web server, so the fact that it is shared has to be taken into consideration. The actual name of the server and not the domain name has to be known, which is available in the left sidebar of the main cPanel page. The port that the web host makes available for ssh connections to a shared server also needs to be known; in this case it is the default port 2222.
The connection is made using
ssh -p 2222 username@server_name
When logging in to the server for the first time, or logging in for the first time on an additional shell, there will be a warning that the host key for the '[ip_address]:port' will be added to the list of known hosts. A file namedknown_hostsis created in~/.ssh/during the first login. This message doesn't appear during subsequent logins. You will then be prompted for the passphrase created in cPanel corresponding to the key name also created in cPanel when generating the keys. The following screenshot shows the ssh command entered at the prompt, the server's response asking for a password, and the message when the connection is established successfully, in the terminal window. The screenshot also shows all of the modified versions of openssh available in the AUR.
One other thing that might help if you have a similar setup to mine where I created a partition for storage that is mounted by fstab in all Linux installations on this computer instead of actually using the home partitons of these installations. I created a directory called ssh in this commonly accessible partiton and created a symlink in~/.sshin each of the installations to this folder. This may not be a good idea in the long run because of conflicts between different installations with different versions of ssh accessing the same file, but I'll see.
The process described here, I think is the simplest way to accomplish this task. As I mentioned above there are other methods of setting up an ssh connection to a remote server. I didn't try this because this method was enough for a first try for me and also the cPanel portion of the set up is supported by the hosting company. For those that want more command line power, this describes a way to do everything from the local computer and even set up a passphrase-less login.