opensource.com Open in urlscan Pro
2a04:4e42:200::645  Public Scan

URL: https://opensource.com/article/20/9/ssh
Submission: On July 19 via manual from US — Scanned from DE

Form analysis 2 forms found in the DOM

GET /site-search

<form action="/site-search" method="get" id="views-exposed-form-acquia-search-page" accept-charset="UTF-8">
  <div class="form--inline clearfix">
    <div class="js-form-item form-item js-form-type-textfield form-type-textfield js-form-item-search form-item-search">
      <label for="edit-search">Search</label>
      <input placeholder="Search" data-drupal-selector="edit-search" type="text" id="edit-search" name="search" value="" size="30" maxlength="128" class="form-text">
    </div>
    <div data-drupal-selector="edit-actions" class="form-actions js-form-wrapper form-wrapper" id="edit-actions"><input data-drupal-selector="edit-submit-acquia-search" type="submit" id="edit-submit-acquia-search" value="Search"
        class="button js-form-submit form-submit">
    </div>
  </div>
</form>

POST /article/20/9/ssh

<form id="mastodon-form" class="mastodon-form" data-drupal-selector="mastodon-form" action="/article/20/9/ssh" method="post" accept-charset="UTF-8">
  <div class="js-form-item form-item js-form-type-textfield form-type-textfield js-form-item-mastodon-url form-item-mastodon-url">
    <label for="edit-mastodon-url">Location of your Mastodon instance:</label>
    <input data-drupal-selector="edit-mastodon-url" type="text" id="edit-mastodon-url" name="mastodon_url" value="" size="60" maxlength="128" class="form-text">
  </div>
  <input autocomplete="off" data-drupal-selector="form-p9iwwc7kilaam4fj-0dbjxagv7fv9vyvwllgcevlmz8" type="hidden" name="form_build_id" value="form-P9iwwC7KiLAam4FJ-0dBjxAgV7FV9vyVwLLGceVlMz8">
  <input data-drupal-selector="edit-mastodon-form" type="hidden" name="form_id" value="mastodon_form">
  <div data-drupal-selector="edit-actions" class="form-actions js-form-wrapper form-wrapper" id="edit-actions"><input data-query="?url=https://red.ht/2EzUFhf&amp;text=A beginner’s guide to SSH for remote connection on Linux | OpenSource.com"
      data-drupal-selector="edit-submit" type="submit" id="edit-submit" name="op" value="Toot" class="button button--primary js-form-submit form-submit">
  </div>
</form>

Text Content

We use cookies on our websites to deliver our online services. Details about how
we use cookies and how you may disable them are set out in our Privacy
Statement. By using this website you agree to our use of cookies. ×


Skip to main content


USER ACCOUNT MENU

 * Log in
 * Sign Up
 * Facebook
 * Twitter
 * RSS




MAIN NAVIGATION

 * Articles
   * Linux
     * Command line
   * Kubernetes
   * Programming
     * Go
     * JavaScript
     * Python
   * Containers
   * Sysadmin
   * DevOps
   * Gaming
   * Hardware
     * 3D printing
     * Arduino
     * Raspberry Pi
   * Government
   * Law
   * Open Organization
     * What is an open organization?
     * What is an open decision?
 * Resources
   * What is open source?
     * The open source way
   * Projects and applications
   * Organizations
   * Cloud technology
     * Ansible
     * Big data
     * Data science
     * Docker
     * Git
     * Internet of things
     * Java
     * Kubernetes
     * Linux containers
     * Microservices
     * OpenStack
     * Python
       * Python GUI frameworks
       * Python IDEs
       * Python template libraries
       * Python web scrapers
     * Software defined networking
     * Virtualization
   * Open source alternatives
     * Alternatives to Acrobat
     * Alternatives to AutoCAD
     * Alternatives to Dreamweaver
     * Alternatives to Gmail
     * Alternatives to MATLAB
     * Alternatives to Minecraft
     * Alternatives to Google Photos
     * Alternatives to Photoshop
     * Alternatives to Skype
     * Alternatives to Slack
     * Alternatives to Trello
     * More...
   * Linux
 * Downloads
   * Cheat sheets
   * DevOps guides
   * Programming guides
   * Sysadmin guides
   * eBooks
   * Open Source Yearbook
   * Open Organization series
 * Community
   * About Opensource.com
     * Welcome to the Opensource.com community
     * Meet the team
     * Create an account
     * Rules for comments and discussions
     * Correspondent Program
     * Frequently Asked Questions
   * Contribute to Opensource.com
     * Opensource.com style guide
     * Writing topics
   * Contact Us
 * Search
   

x


SUBSCRIBE TO OUR NEWSLETTER.

Stay on top of the latest thoughts, strategies and insights from enterprising
peers.




A BEGINNER’S GUIDE TO SSH FOR REMOTE CONNECTION ON LINUX

Establish connections with remote computers using secure shell.
By
Seth Kenlon (Team, Red Hat)
September 7, 2020 | 10 Comments | %t min read
139 readers like this
139 readers like this

Image by:

CC BY 3.0 US Mapbox Uncharted ERG

One of Linux's most appealing features is the ability to skillfully use a
computer with nothing but commands entered into the keyboard—and better yet, to
be able to do that on computers anywhere in the world. Thanks to OpenSSH, POSIX
users can open a secure shell on any computer they have permission to access and
use it from a remote location. It's a daily task for many Linux users, but it
can be confusing for someone who has yet to try it. This article explains how to
configure two computers for secure shell (SSH) connections, and how to securely
connect from one to the other without a password.


TERMINOLOGY

When discussing more than one computer, it can be confusing to identify one from
the other. The IT community has well-established terms to help clarify
descriptions of the process of networking computers together.

 * Service: A service is software that runs in the background so it can be used
   by computers other than the one it's installed on. For instance, a web server
   hosts a web-sharing service. The term implies (but does not insist) that it's
   software without a graphical interface.
 * Host: A host is any computer. In IT, computers are called a host because
   technically any computer can host an application that's useful to some other
   computer. You might not think of your laptop as a "host," but you're likely
   running some service that's useful to you, your mobile, or some other
   computer.
 * Local: The local computer is the one you or some software is using. Every
   computer refers to itself as localhost, for example.
 * Remote: A remote computer is one you're not physically in front of nor
   physically using. It's a computer in a remote location.

Now that the terminology is settled, you can begin.


ACTIVATE SSH ON EACH HOST

For two computers to be connected over SSH, each host must have SSH installed.
SSH has two components: the command you use on your local machine to start a
connection, and a server to accept incoming connection requests. Some computers
come with one or both parts of SSH already installed. The commands vary,
depending on your system, to verify whether you have both the command and the
server installed, so the easiest method is to look for the relevant
configuration files:

$ file /etc/ssh/ssh_config

/etc/ssh/ssh_config: ASCII text

Should this return a No such file or directory error, then you don't have the
SSH command installed.

Do a similar check for the SSH service (note the d in the filename):

$ file /etc/ssh/sshd_config

/etc/ssh/sshd_config: ASCII text

Install one or the other, as needed:

$ sudo dnf install openssh-clients openssh-server

On the remote computer, enable the SSH service with systemd:

$ sudo systemctl enable --now sshd

Alternately, you can enable the SSH service from within System Settings on GNOME
or System Preferences on macOS. On the GNOME desktop, it's located in the
Sharing panel:



Image by:

(Seth Kenlon, CC BY-SA 4.0)




START A SECURE SHELL



More Linux resources

 * Linux commands cheat sheet
 * Advanced Linux commands cheat sheet
 * Free online course: RHEL Technical Overview
 * Linux networking cheat sheet
 * SELinux cheat sheet
 * Linux common commands cheat sheet
 * What are Linux containers?
 * Our latest Linux articles

Now that you've installed and enabled SSH on the remote computer, you can try
logging in with a password as a test. To access the remote computer, you must
have a user account and a password.

Your remote user doesn't have to be the same as your local user. You can log in
as any user on the remote machine as long as you have that user's password. For
instance, I'm sethkenlon on my work computer, but I'm seth on my personal
computer. If I'm on my personal computer (making it my current local machine)
and I want to SSH into my work computer, I can do that by identifying myself as
sethkenlon and using my work password.

To SSH into the remote computer, you must know its internet protocol (IP)
address or its resolvable hostname. To find the remote machine's IP address, use
the ip command (on the remote computer):

$ ip addr show | grep "inet "

inet 127.0.0.1/8 scope host lo

inet 10.1.1.5/27 brd 10.1.1.31 [...]

If the remote computer doesn't have the ip command, try ifconfig instead (or
even ipconfig on Windows).

The address 127.0.0.1 is a special one and is, in fact, the address of
localhost. It's a "loopback" address, which your system uses to reach itself.
That's not useful when logging into a remote machine, so in this example, the
remote computer's correct IP address is 10.1.1.5. In real life, I would know
that because my local network uses the 10.1.1.0 subnet. If the remote computer
is on a different network, then the IP address could be nearly anything (never
127.0.0.1, though), and some special routing is probably necessary to reach it
through various firewalls. Assume your remote computer is on the same network,
but if you're interested in reaching computers more remote than your own
network, read my article about opening ports in your firewall.

If you can ping the remote machine by its IP address or its hostname, and have a
login account on it, then you can SSH into it:

$ ping -c1 10.1.1.5

PING 10.1.1.5 (10.1.1.5) 56(84) bytes of data.

64 bytes from 10.1.1.5: icmp_seq=1 ttl=64 time=4.66 ms

$ ping -c1 akiton.local

PING 10.1.1.5 (10.1.1.5) 56(84) bytes of data.

That's a success. Now use SSH to log in:

$ whoami

seth

$ ssh sethkenlon@10.1.1.5

bash$ whoami

sethkenlon

The test login works, so now you're ready to activate passwordless login.


CREATE AN SSH KEY

To log in securely to another computer without a password, you must have an SSH
key. You may already have an SSH key, but it doesn't hurt to create a new one.
An SSH key begins its life on your local machine. It consists of two components:
a private key, which you never share with anyone or anything, and a public one,
which you copy onto any remote machine you want to have passwordless access to.

Some people create one SSH key and use it for everything from remote logins to
GitLab authentication. However, I use different keys for different groups of
tasks. For instance, I use one key at home to authenticate to local machines, a
different key to authenticate to web servers I maintain, a separate one for Git
hosts, another for Git repositories I host, and so on. In this example, I'll
create a unique key to use on computers within my local area network.

To create a new SSH key, use the ssh-keygen command:

$ ssh-keygen -t ed25519 -f ~/.ssh/lan

The -t option stands for type and ensures that the encryption used for the key
is higher than the default. The -f option stands for file and sets the key's
file name and location. You'll be prompted to create a password for your SSH
key. You should create a password for the key. This means you'll have to enter a
password when using the key, but that password remains local and isn't
transmitted across the network. After running this command, you're left with an
SSH private key called lan and an SSH public key called lan.pub.

To get the public key over to your remote machine, use the ssh-copy-id. For this
to work, you must verify that you have SSH access to the remote machine. If you
can't log into the remote host with a password, you can't set up passwordless
login either:

$ ssh-copy-id -i ~/.ssh/lan.pub sethkenlon@10.1.1.5

During this process, you'll be prompted for your login password on the remote
host.

Upon success, try logging in again, but this time using the -i option to point
the SSH command to the appropriate key (lan, in this example):

$ ssh -i ~/.ssh/lan sethkenlon@10.1.1.5

bash$ whoami

sethkenlon

Repeat this process for all computers on your network, and you'll be able to
wander through each host without ever thinking about passwords again. In fact,
once you have passwordless authentication set up, you can edit the
/etc/ssh/sshd_config file to disallow password authentication. This prevents
anyone from using SSH to authenticate to a computer unless they have your
private key. To do this, open /etc/ssh/sshd_config in a text editor with sudo
permissions and search for the string PasswordAuthentication. Change the default
line to this:

PasswordAuthentication no

Save it and restart the SSH server (or just reboot):

$ sudo systemctl restart sshd && echo "OK"

OK

$


USING SSH EVERY DAY

OpenSSH changes your view of computing. No longer are you bound to just the
computer in front of you. With SSH, you have access to any computer in your
house, or servers you have accounts on, and even mobile and Internet of Things
devices. Unlocking the power of SSH also unlocks the power of the Linux
terminal. If you're not using SSH every day, start now. Get comfortable with it,
collect some keys, live more securely, and expand your world.

What to read next


OPEN PORTS AND ROUTE TRAFFIC THROUGH YOUR FIREWALL

Safely and securely give outside parties access to your network.

Seth Kenlon
(Team, Red Hat)
September 2, 2020


TOOLS FOR SSH KEY MANAGEMENT

Time-saving shortcuts for a commonly used open source tool.

Ben Nuttall
(Alumni)
February 20, 2020


GETTING STARTED WITH LINUX FIREWALLS

A firewall is your computer's first line of defense against network intrusion.
Download our cheat sheet to make sure you're secure.

Seth Kenlon
(Team, Red Hat)
February 28, 2020
Tags
Linux
Seth Kenlon

Seth Kenlon is a UNIX geek, free culture advocate, independent multimedia
artist, and D&D nerd. He has worked in the film and computing industry, often at
the same time.
More about me



10 COMMENTS

These comments are closed, however you can Register or Login to post a comment
on another article.
Greg Pittman | September 7, 2020

It's also worth looking at your ssh log files once you open any computer to
remote ssh. You will see constant attempts to log into the system.

Seth Kenlon | September 8, 2020

You're not wrong! It's kinda terrifying. Definitely cause to install and use
Fail2ban.

https://opensource.com/article/19/10/linux-server-security#fail2ban

In reply to It's also worth looking at by Greg Pittman

Jason Moore | September 7, 2020

Great article, appreciate your hard work! This is good advice too, so many
systems get compromised because of a weak password.

Rafael da Silva Batista | September 7, 2020

it didn't work.I've the following environment for studing: ubuntu server which
has been accessed by my client (fedora). I was able to create the priv key and
the public one on the server side (ubuntu server) then I ran:

ssh-copy-id -i ~/.ssh/lan.pub my_user@My_Server

Does it must run on the server side or on my client machine?

Seth Kenlon | September 7, 2020

When you use ssh-copy-id, you use it from the machine you want to SSH *from*
(this is considered your "local" machine). In the scenario you describe, that
means you'll run it from your Fedora machine. It sounds like you did that (I
assume your server is My_Server), so it should work. I'd need to know more about
what error you've encountered.

The comment section isn't the greatest format for support, though. I suggest
going over to http://linuxquestions.org, signing up for an account (it's $0),
and asking for help there. Lots of people eager to help.

In reply to it didn't work.I've the by Rafael da Silv… (not verified)

jonathan | September 8, 2020

You should always protect your private key with a passphrase. We had to disable
SSH key access to our HPC system because users didn't use a passphrase with
their key.

Seth Kenlon | September 9, 2020

Great point. I've updated the article to reinforce the importance of a
passphrase on the key itself.

In reply to You do realize that by jonathan

Steven Pemberton | September 9, 2020

Here's another *really* useful hint:

ssh -Y sethkenlon@10.1.1.5

Then you can run any X-based program from the remote machine, and the windows
show up on your local machine.

So I log in to my Raspberry Pi and run

$ pcmanfm

and this runs the file browser, with the windows on my local machine!

Joost Ringoot | September 22, 2020

just some improving remark:

Instead of specifying the sshkey in the commandline, you can use ssh-agent:
First associate the key just once with the agent

eval `ssh-agent`
ssh-add

then you can use

ssh-copy-id remotelogin@remotehost

to copy all the keys registered in the ssh-agent to the remotehost.

next time ssh will try automaticly to use the key associated with the ssh-agent

Seth Kenlon | September 22, 2020

Great workflow. I like to teach the manual way first so it feels less "magical"
(plus I use -i a lot because I have unique keys for different hosts). But I like
your method, too. Maybe it's material for an add-on article!

In reply to just some improving remark: by Joost Ringoot (not verified)


RELATED CONTENT

Monitor your Linux firewall with nftwatch
How I configure a DHCP server on my personal network
Listen to music on Linux with Rhythmbox
This work is licensed under a Creative Commons Attribution-Share Alike 4.0
International License.
LinkedInTwitterFacebookWhatsAppEmailRedditMastodon
Location of your Mastodon instance:



SUBSCRIBE TO OUR WEEKLY NEWSLETTER



Privacy Statement


ABOUT THIS SITE

The opinions expressed on this website are those of each author, not of the
author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license
but may not be able to do so in all cases. You are responsible for ensuring that
you have the necessary permission to reuse any work on this site. Red Hat and
the Red Hat logo are trademarks of Red Hat, Inc., registered in the United
States and other countries.

A note on advertising: Opensource.com does not sell advertising on the site or
in any of its newsletters.


CONTACT

Follow us @opensource.com on Twitter

Like Opensource.com on Facebook

Watch us at Opensource.com

Follow us on Mastodon

RSS Feed



Copyright ©2022 Red Hat, Inc.


LEGAL

 * Privacy Policy
 * Terms of use
 * Contact