The secure shell is a protocol that lets you open a remote terminal,
or shell session, on any UNIX-based server where,
according to the permissions available to the account you've logged into,
you can execute commands.
The primary advantage of SSH over other remote connectivity tools,
including Telnet,
is that everything you do during this session will be encrypted so
that anyone who might be watching at any point between you and your
remote host will see only unreadable text.
Using the same basic process,
you can also securely transfer files between nodes using SCP and,
when you've appropriately edited the configuration files on
both your server and client machines,
securely launch GUI applications on a remote host.
SSH is simple enough to use that, for most practical purposes,
there is no reason that you should ever open any kind of any kind
of unencrypted session over an insecure network.
I will note that SSH is now available natively on Windows 10 computers.
SSH works in one of three ways: RSA rhost authentication works if the
remote host contains a file named either hosts.
equiv or shosts.
equiv in, respectively, the etc or etc/ssh/ directories, or.
rhosts, or.
shosts in a user's home directory.
Should any of those files contain an entry identifying the
client machine and its current user,
and should the host server already have a compatible
entry for the client's host key, then login will be permitted.
If none of those files exist,
and largely because of structural weaknesses within the rhost system itself,
that will usually be the case by default,
then the SSH program running on the client will
identify to the server which local, encrypted key pair it wants to use.
But before that can happen, of course, you'll need a key pair to work with.
If you don't already have one, you can generate a key pair in the.
ssh directory within your user's home directory on a Linux
client using the ssh-keygen program.
The dot that precedes the directory name tells Linux that this is a hidden
file that can only be seen using the -a flag with ls.
Beside the.
ssh directory that can exist within any individual user directory hierarchy,
there's also an SSH directory beneath the system's etc directory that
contains key pairs and also two configuration files.
The ssh_config file determines how this computer will,
by default, behave as a client on other remote machines,
and the sshd_config file governs its behavior as a host to
sessions accessed by remote clients.
If you accept ssh-keygen's defaults values, it will create two files in the.
ssh directory called id_rsa, and id_rsa.
pub.
That first file is the private half of the pair,
and as the name suggests,
should be treated with great care and never be exposed to an insecure network,
like sending it as an email attachment.
Normally, you'll leave the private key exactly where it is now on your computer.
You'll be prompted to create a passphrase,
which your local machine will expect you to enter each time
you attempt a key-based remote login.
I'll create a passphrase, but later we'll see how it can be used even in a nasty,
dark world where we already have more passwords to
remember than is humanly possible.
I'll print my public key to the screen.
I'll then copy the contents, and nothing but the contents, to my clipboard.
Now, using a normal password one last time,
I'll login to the computer for which I'd like to setup key-based login.
I'll move to the.
ssh directory, open the authorized_keys file of a text editor,
and paste the public key we copied before on a new line.
Now, back in our client machine, I'll ssh in once again.
Of course, I'll need to enter the passphrase that my local ssh program demands,
but I'm dropped right into the remote machine
without having to enter its password.
Besides saving me from having to remember and type
my password each time I log in,
a significant advantage of this is that we can avoid the
need to transmit the password itself over a connection
that hasn't yet been secured.
How does this whole key exchange actually work?
When your client machine sends its request to open a new session,
the server's SSH program will send a random number that's been
encrypted using the client's public key.
If the client can decrypt the number using its own private key,
then the server will allow you to launch into a session.
Now, about that local passphrase.
How can I be expected to remember yet one more password?
You can simplify the process by invoking SSH without losing the
extra security a passphrase provides by having a key agent handle
your passphrases for you on your machine.
You first launch ssh-agent,
which will return a new process id confirming that the program is running,
and then run ssh-add against the key pair you'd like to serve.
Now, whenever you use ssh to open a shell session on a remote computer,
the local passphrase will be handled invisibly by ssh-agent.
But hang on a minute.
If requiring a passphrase is an important security measure,
doesn't handing it off to an automated server defeat the purpose?
Nope.
The goal here is to protect your private key.
Imagine what could happen if someone nefarious
somehow got ahold of your private key.
And don't think this doesn't happen all the time.
The thief would effectively be able to log in to any server that has your
public key without being challenged for a password.
But if you protect your key with a password,
even if you allow ssh-agent to handle it locally,
without the password, the key will still be useless on any other computer.
So let's try it out one more time.
This time we got in without entering either a local
passphrase or a remote password.
If neither of the first two authentication options work,
the server will prompt the client for a password.
In many use cases, for security reasons,
it's preferable to try to avoid relying on a password.
This much is common to both SSH protocol version 1 and its more
modern replacement SSH protocol version 2.
In addition, version 2 supports RSA, DSA, and OpenPGP public key algorithms.
The first time you log into a host server using SSH,
the SSH process running on your local client will
warn you that the host is unknown.
If you choose to connect anyway, by typing the full word yes,
rather than just the letter y as you might normally expect,
you'll be told that the host fingerprint has been
added to your known_hosts file.
From here on in,
if a client using this IP address attempts to authenticate from a
computer advertising a different fingerprint,
you'll be alerted.
This might simply be a result of your local DHCP server
innocently reassigning an old IP address,
but it might also indicate that there's a man-in-the-middle attack in process.
Next up,
we'll explore a few sources of live connection data that can be used for debugging.