Apache

SSH: How to Connect to Remote Server in Ubuntu

What Is SSH?

One essential tool to master as a system administrator is SSH.

SSH, or Secure Shell, is a protocol used to securely log onto remote systems. It is the most common way to access remote Linux and Unix-like servers.

Here, I shall discuss how to use SSH to connect to a remote system.

Basic Syntax

The tool on Linux for connecting to a remote system using SSH is called, unsurprisingly, ssh.

The most basic form of the command is:

ssh remote_host

The remote_host in the example is the IP address or domain name that you are trying to connect to.

This command assumes that your username on the remote system is the same as your username on your local system.

If your username is different on the remote system, you can specify it by using this syntax:

ssh remote_username@remote_host

Once you have connected to the server, you will probably be asked to verify your identity by providing a password.

Later, I shall cover how to generate keys to use instead of passwords.

To exit back into your local session, simply type:

exit

How Does SSH Work?

SSH works by connecting a client program to an ssh server.

In the above commands, ssh is the client program. The ssh server is already running on the remote_host that we specified.

On Ubuntu, you can start the ssh server on the Droplet by typing:

sudo service ssh start

On Ubuntu 16.04 and Debian Jessie, you can use systemctl, the systemd command for managing services:

sudo systemctl start ssh

That should start the sshd server and you can then log in remotely.

How To Configure SSH

When you change the configuration of SSH, you are changing the settings of the sshd server.

In Ubuntu, the main sshd configuration file is located at /etc/ssh/sshd_config.

Back up the current version of this file before editing:

sudo cp /etc/ssh/sshd_config{,.bak}

Open it with a text editor:

sudo nano /etc/ssh/sshd_config

You will want to leave most of the options in this file alone. However, there are a few you may want to take a look at:

/etc/ssh/sshd_config
Port 22

The port declaration specifies which port the sshd server will listen on for connections. By default, this is 22. You should probably leave this setting alone, unless you have specific reasons to do otherwise. If you do change your port, I shall show you how to connect to the new port later on.

/etc/ssh/sshd_config
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

The host keys declarations specify where to look for global host keys. We will discuss what a host key is later.

/etc/ssh/sshd_config
SyslogFacility AUTH
LogLevel INFO

These two items indicate the level of logging that should occur.

If you are having difficulties with SSH, increasing the amount of logging may be a good way to discover what the issue is.

/etc/ssh/sshd_config
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

These parameters specify some of the login information.

LoginGraceTime specifies how many seconds to keep the connection alive without successfully logging in.

It may be a good idea to set this time just a little bit higher than the amount of time it takes you to log in normally.

PermitRootLogin selects whether root is allowed to log in.

In most cases, this should be changed to “no” when you have created user account that has access to elevated privileges (through su or sudo) and can log in through ssh.

strictModes is a safety guard that will refuse a login attempt if the authentication files are readable by everyone.

This prevents login attempts when the configuration files are not secure.

/etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10

These parameters configure an ability called X11 Forwarding. This allows you to view a remote system’s graphical user interface (GUI) on the local system.

This option must be enabled on the server and given with the SSH client during connection with the -Xoption.

If you changed any settings in /etc/ssh/sshd_config, make sure you restart your sshd server to implement your modifications:

sudo service ssh restart

Or, on systemd systems such as Ubuntu 16.04 or Debian Jessie:

sudo systemctl restart ssh

You should thoroughly test your changes to ensure that they operate in the way you expect.

It may be a good idea to have a few sessions active when you are making changes. This will allow you to revert the configuration if necessary.

If you run into problems, remember that you can log in through the Console link on your Droplet page.

How To Log Into SSH with Keys

While it is helpful to be able to log in to a remote system using passwords, it’s a much better idea to set up key-based authentication.

How Does Key-based Authentication Work?

Key-based authentication works by creating a pair of keys: a private key and a public key.

The private key is located on the client machine and is secured and kept secret.

The public key can be given to anyone or placed on any server you wish to access.

When you attempt to connect using a key-pair, the server will use the public key to create a message for the client computer that can only be read with the private key.

The client computer then sends the appropriate response back to the server and the server will know that the client is legitimate.

This entire process is done in the background automatically after you set up keys.

How To Create SSH Keys

SSH keys should be generated on the computer you wish to log in from. This is usually your local computer.

Enter the following into the command line:

ssh-keygen -t rsa

Press enter to accept the defaults. Your keys will be created at ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa.

Change into the .ssh directory by typing:

cd ~/.ssh

Look at the permissions of the files:

ls -l
Output
-rw-r--r-- 1 demo demo  807 Sep  9 22:15 authorized_keys
-rw------- 1 demo demo 1679 Sep  9 23:13 id_rsa
-rw-r--r-- 1 demo demo  396 Sep  9 23:13 id_rsa.pub

As you can see, the id_rsa file is readable and writable only to the owner. This is how it should be to keep it secret.

The id_rsa.pub file, however, can be shared and has permissions appropriate for this activity.

How To Transfer Your Public Key to the Server

You can copy the public key to the remote server by issuing this command:

ssh-copy-id remote_host

This will start an SSH session, which you will need to authenticate with your password.

After you enter your password, it will copy your public key to the server’s authorized keys file, which will allow you to log in without the password next time.

Client-Side Options

There are a number of optional flags that you can select when connecting through SSH.

Some of these may be necessary to match the settings in the remote host’s sshd configuration.

For instance, you if you changed the port number in your sshd configuration, you will need to match that port on the client-side by typing:

ssh -p port_number remote_host

If you only wish to execute a single command on a remote system, you can specify it after the host like so:

ssh remote_host command_to_run

You will connect to the remote machine, authenticate, and the command will be executed.

As we said before, if X11 forwarding is enabled on both computers, you can access that functionality by typing:

ssh -X remote_host

Providing you have the appropriate tools on your computer, GUI programs that you use on the remote system will now open their window on your local system.

How to set up Virtual Hosts in Apache

Setting up Virtual Hosts in Apache on Mac OSX is straight forward after you have your local Web Development environment up and running. The process of setting up Virtual Hosts is done easily in the Terminal either using nano or vi with sudo or as a root user.

Allow the vhosts configuration from the Apache configuration file httpd.conf

Open the httpd.conf

sudo nano /etc/apache2/httpd.conf

Search for ‘vhosts‘ and uncomment the include line

# Virtual hosts
Include /private/etc/apache2/extra/httpd-vhosts.conf</pre>

Also allow another module to run by uncommenting:

LoadModule vhost_alias_module libexec/apache2/mod_vhost_alias.so

Edit the vhosts.conf file

Open this file to add in the virtual host.

sudo nano /etc/apache2/extra/httpd-vhosts.conf

An example domain in the file is given of the format required to add in additional domains, just follow this to create your new virtual host:

<VirtualHost *:80>
ServerAdmin webmaster@dummy-host2.example.com
DocumentRoot "/usr/docs/dummy-host2.example.com"
ServerName dummy-host2.example.com
ErrorLog "/private/var/log/apache2/dummy-host2.example.com-error_log"
CustomLog "/private/var/log/apache2/dummy-host2.example.com-access_log" common
</VirtualHost>

We can take this example and extend on it, if you wanted a domain named swatantra.info for example, you can copy the existing text block and edit to suit:

<VirtualHost *:80>
ServerName swatantra.info
ServerAlias www.swatantra.info
DocumentRoot "/Users/USERNAME/Sites/apple"
ErrorLog "/private/var/log/apache2/swatantra.info-error_log"
CustomLog "/private/var/log/apache2/swatantra.info-access_log" common
ServerAdmin web@swatantra.info
</VirtualHost>

So in the example above a vhost for swatantra.info is created and the document root is in the Sites folder, in the text block above I have also added in some log files, what you need to change is the document root location username and domain name to suit your needs. Finish and save the file.

Now also you need to map the IP address to be the localhost.

Map Your IP address to localhost

sudo nano /etc/hosts

Add the Domain and ‘www‘ alias to resolve to the localhost address

127.0.0.1 swatantra.info www.swatantra.info

Restart Apache

sudo apachectl restart

Check out your local vhost domain in the browser

Losing Localhost

One caveat to note about virtual hosts is that once set up you lose your older document root previously at/Library/WebServer/Documents or accessed in the browser at http://localhost what happens is that you get a 403 Forbidden Error. But the ~/username document root is still compatible.

To get around this, you need to add in a vhost for localhost and declare this vhost before any of the others, in the same file:

sudo nano /etc/apache2/extra/httpd-vhosts.conf

Add in:

<VirtualHost *:80>
ServerName localhost
DocumentRoot /Library/WebServer/Documents/
</VirtualHost>

Restart Apache

sudo apachectl restart

Changing the WebServer Default User

One of the frustrations of using the Users/username/Sites folder for vhosts is the permissions issues with things like updates and authentication.

This is because the default webserver user which runs httpd is known as _www, which will not be the user in your local account. If your machine is only in use by you and the webserver will run only under your account then you can change the user.

Find Your User and Group

In the Terminal use the id command to see your username and group

id (use this command)

You will get a bunch of user groups, you need your primary user uid and group gid names

uid=502(<mark>swatantra</mark>) gid=20(<mark>staff</mark>)

Change this back in /etc/apache2/httpd.conf

httpd.conf

Restart Apache

sudo apachectl restart

Restart Apache and now you are running httpd as your local account.