Remote Server/Host Access and Root Login Using SSH

Learn about remote server/host access and root login using SSH in this guest post by Tajinder Kalsi, an information security and Linux expert.

Secure Shell (SSH) is a protocol that is used to log onto remote systems securely and is the most commonly used method for accessing remote Linux systems.

Getting ready

To see how to use SSH, you need two Ubuntu systems. One will be used as the server and the other as the client.

How to do it…

To use SSH, you can use freely available software called OpenSSH. Once the software is installed, it can be used by the ssh command. Take a look at how to use this tool in detail:

  1. If OpenSSH server is not already installed, it can be installed using the following command:

sudo apt-get install openssh-server


  1. Next, you need to install the client version of the software:

sudo apt-get install openssh-client


  1. For the latest versions, the SSH service starts running as soon as the software is installed. If it is not running by default, you can start the service by using the command:

sudo service ssh start


  1. Now, to log in to the server from any other system using SSH, you can use the following command:

ssh remote_ip_address

Here, remote_ip_address refers to the IP address of the server system. Also, this command assumes that the username on the client machine is the same as on the server machine:


If we want to log in for a different user, the command will be as follows:

ssh username@remote_ip_address


  1. Next, you need to configure SSH to use it as per your requirements. The main configuration file for sshd in Ubuntu is located at /etc/ssh/sshd_config. Before making any changes to the original version of this file, create a backup using the following command:

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

The configuration file defines the default settings for SSH on the server system.

  1. Opening the file in a text editor, you can see that the default port declaration on which the sshd server listens for the incoming connections is 22. You can change this to any non-standard port to secure the server from random port scans, thus making it more secure. Suppose you change the port to 888, then the next time the client wants to connect to the SSH server, the command will be as follows:

ssh -p port_numberremote_ip_address


As you can see, when you run the command without specifying the port number, the connection is refused. When you mention the correct port number, the connection is established.

How it works…

SSH is used to connect a client program to an SSH server. On one system, you install the openssh-server package to make it the SSH server, and on the other system, you install the openssh-client package to use it as the client.

Now, keeping the SSH service running on the server system, you try to connect to it through the client.

You can use the configuration file of SSH to change the settings such as the default port for connecting.

Enabling and disabling root login over SSH

Linux systems have a root account that is enabled by default. Unauthorized users gaining root access to the system can be really dangerous.

You can disable or enable the root login for SSH as per your requirements to prevent the chances of an attacker getting access to the system.

Getting ready

You need two Linux systems to be used as server and client. On the server system, install the openssh-server package, as shown in the previous recipe.

How to do it…

First, take a look at how to disable SSH root login and then you’ll also see how to enable it again:

  1. First, open the main configuration file of SSH, /etc/ssh/sshd_config, in any editor:

sudo nano /etc/ssh/sshd_config

  1. Now look for the line that reads as follows:

PermitRootLogin yes

  1. Change the value yes to no. Then save and close the file:

PermitRootLogin no


  1. Once done, restart the SSH daemon service using the following command:


  1. Now try to log in as root. You should get an error:

Permission Denied

This is because the root login has been disabled:


  1. Now whenever you want to log in as root, you’ll first have to log in as a normal user. After this, you can use the su command and switch to the root user. So, the user accounts that are not listed in the /etc/sudoers file will not be able to switch to root user and the system will be more secure:


  1. Now, if you want to enable SSH root login again, you just need to edit the /etc/ssh/sshd_config file again and change the no option to yes:

PermitRootLogin yes


  1. Then restart the service again by using the following command:


  1. Now if you try to log in as root again, it will work:


How it works…

When you try to connect to a remote system using SSH, the remote system checks its configuration file at /etc/ssh/sshd_config. According to the details mentioned in this file, it decides whether the connection should be allowed or refused.

There’s more…

Suppose you have many user accounts on the systems. You need to edit the /etc/ssh/sshd_config file in such a way that remote access is allowed only to few mentioned users:

sudo nano /etc/ssh/sshd_config

Add the following line:

AllowUsers tajinder user1

Now restart the SSH service:

sudo service ssh restart

Now when you’ll try to log in with  user1, the login is successful. However, when you try to log in with user2, which has not been added in the /etc/ssh/sshd_config file, the login fails and you get  Permission denied error, as shown here:


That’s it! If this article piqued your interest in learning more about security with Linux, you can explore Practical Linux Security Cookbook – Second Edition. Packed with numerous hands-on recipes to secure a Linux environment from modern-day attacks, Practical Linux Security Cookbook – Second Edition is a must-read for all Linux users.

KDE Bugsquad – Konsole Bug Day on October 30th, 2018

We will be holding a Bug Day on October 30th, 2018, focusing on Konsole. Join at any time, the event will be occurring all day long!

This is a great opportunity for anyone, especially non-developers to get involved!

  1. Mascot_konqi-support-bughunt.pngCheck out our Bug Triaging guide for a primer on how to go about confirming and triaging bugs.
  2. Log into KDE Phabricator and join the Bugsquad!
  3. Join the #kde-bugs IRC channel on Freenode to chat with us in real-time as we go through the list.
  4. Open the shared Etherpad for this event (use your KDE Identity login) to select your block of bugs and cross them off.

If you need any help, contact me!

KDE Bugsquad – Konsole Bug Day on October 20th, 2018

We will be holding a Bug Day on October 20th, 2018, focusing on Konsole. Join at any time, the event will be occurring all day long!

This is a great opportunity for anyone, especially non-developers to get involved!

  1. Mascot_konqi-support-bughunt.pngCheck out our Bug Triaging guide for a primer on how to go about confirming and triaging bugs.
  2. Log into KDE Phabricator and join the Bugsquad!
  3. Join the #kde-bugs IRC channel on Freenode to chat with us in real-time as we go through the list.
  4. Open the shared Etherpad for this event (use your KDE Identity login) to select your block of bugs and cross them off.

If you need any help, contact me!

Cleaning up the Cruft in KDE’s Bugzilla

There are 42,000 open bugs in KDE’s Bugzilla.

We know this is a problem, and some steps have been taken recently to attempt to reduce this. Not long ago, Nate Graham proposed a cleanup of our plasma4 product, which closed 4,000+ bugs. Most of the bugs there were very old and no longer relevant, due to the introduction of Plasma 5 four years ago. While that was a good step in the right direction, we have many, many more products.

In fact, there are 741 “products” in the KDE Bugzilla.

bring-out-your-deadMany of those products are long dead. Projects that were brought under the KDE wing years ago, but have been abandoned and unmaintained for many years. Or, products that have been purposefully obsoleted in favor of a newer product name. Unfortunately, those Bugzilla products have been left open, allowing bug reports to be submitted, left to linger and clutter the database.

So we fixed that.

Nate and I worked together, building off of a list produced by Julian Schraner, of unmaintained, dead products. After a few days of verification, we were able to close 259 products and close 2,500+ bugs that were left lingering in those products. Now, when you create a new bug, those 259 are hidden, and only available in the “Browse” page.

So that is helpful, and we’ve seen a visible drop on the Bugzilla charts from these closures.

But what about the daily intake?

KDE receives 30+ new bugs per day.

The KDE developers do an excellent job, many of them triaging themselves, and resolving bugs quickly, attempting to hold back the onslaught. But it’s just too much, and we often have more new bugs opened than closed.

This causes terrifying charts such as this:

open bugs

The bugs pile up.

See those 27,000 UNCONFIRMED bugs? This is the reason I resurrected the KDE Bugsquad. The signal-to-noise ratio is much too low!

A good example of what the above chart should look like, is the one for Krita:


The signal-to-noise ratio here is much higher. Most bugs are CONFIRMED or NEEDSINFO from the reporter. Developers know which are real issues, and the bug reports have information from the reporters and the triagers in the comments.

We need to get the rest of the KDE products to look like this.

Let’s clean up the old cruft. I’m proposing the following actions to take:

  1. Close any additional unmaintained products that were missed. I have a list of a few that are questionable, and will require some additional investigation or emails. This step could close 2,000 bugs.
  2. Close NEEDSINFO bugs that have not had a response for 30 days. This would become a KDE Bugzilla policy. It cannot be expected to leave a bug open indefinitely, if the reporter will not provide the additional requested information. This is already a policy at many other projects such as The Document Foundation, Chromium, and Fedora. After a discussion regarding this on the kde-community mailing list, there appeared to be a consensus, so work has already begun. This step alone, will close almost 6,000 bugs.
  3. Request follow-up and potential closure of old crash reports. This would clean up old crash reports provided mostly by Dr. Konqi, that have sat untouched for several years. There is a good possibility the crash is no longer relevant in newer releases. This step would close over 3,800 bugs.
  4. Close old bugs that are beyond 10 years old in their last activity. This would get rid of the oldest abandoned bugs, some of which date back to 2002 or earlier! This step would close over 3,300 bugs.

Getting involved in the KDE Bugsquad is a great way to easily get involved. You only need a few minutes and the latest version of an app. Check out our Bug triaging guide to understand the process. It’s really easy!

You could help triage bugs with me!

Visit KDE’s Get Involved page for more information, or contact me!

Making Plasma Superb in HiDPI

notebook-xps-13-polaris-pdp-design-1.jpgNot long ago I purchased a Dell XPS 13 with the HiDPI touchscreen. It was one of the Project Sputnik “Developer Edition” laptops loaded with Ubuntu from the factory; nice and clean. This was my first foray into using a HiDPI screen in Linux. From my research before purchasing, it sounded like a mixed bag of functionality. I fired up a bunch of apps, tested them out and dutifully submitted a bunch of bug reports regarding scaling issues to a number of projects. From there, once ushered into the development side of KDE, I decided to start helping out with fixing some of the issues I saw with KDE/Qt apps.

It appears there are still very few users and even fewer developers with a HiDPI screen who run 2x scaling, so I notice things others don’t. Most of it revolves around window sizes upon loading, interface button and label sizes, and icon pixelation. Minor stuff, but annoying.

The latter of which, is actually really easy to fix in Qt apps.

It’s one line:


Enter that into main.cpp of the program and you’re set! Even myself, a rather entry-level programmer can perform that task and submit a patch. So that’s what I did for several applications.

Look carefully at the before/after pixelation of the icons here in KTorrent:

Some more examples and links to Phabricator, please ignore any change of icon colors, that is a different issue that has been recently resolved:

I have a few more in my list, such as the AppMenu button you can add to KWin. Anyone want to tackle that?

But anyway, lots of progress is being made! These sorts of fixes, along with ones like display of scaled icons from intended folder, 2x icons in Breeze, enhanced scaling abilities in Wayland, and implementation of HiDpiScaling in some older apps are being committed constantly.

Running the latest Plasma release, there are very few HiDPI issues left, and a good portion of them can be blamed on X.

You could help do easy tasks like this too!

Visit KDE’s Get Involved page for more information, or contact me!