The secure shell protocol, SSH for short, allows you to quickly and easily connect to a remote server, assuming are authorized and have the right credentials, or of course. Once connected to a system, you are presented with the same familiar command-line you have available locally and in most cases, have most of the same tools at your finger tips.
ssh command is pretty much standard issue on Unix-like systems such as Linux and macOS, so you probably already have it available.
We’ll also be using the
ssh-copy-id command which isn’t as readily available. If you don’t happen to have either of the commands in question installed, simply refer to your favorite package manager.
Also, it’s assumed that you already have a remote system available to work with. Simply substitute out
user for your own server’s hostname and your user account.
Alligator.io recommends ⤵👉 Learn Node, a video course by Wes Bos
You'll learn things like user auth, database storage, building a REST API and uploading images in Node.js by building a real world restaurant application.
Connecting to a remote server
In it’s simplest form, using SSH is as easy as typing
ssh followed by your server’s hostname or address:
$ ssh hostname
Which typically will ask you if you’re sure you want to connect to a host, on your first connection ever to the machine. Then will greet you with a password prompt. Then after proper authentication, you’ll get to another command-line prompt, on the remote server.
This will get you pretty far, until somebody decides to give you server access using a username that’s not the same as your local user. Also if the server administrator has configured SSH to run on an alternate port, for security through obfuscation’s sake.
To tell SSH to use a different username, you can prepend the
user to the
hostname using the
$ ssh user@hostname
Specifying the port can be done via the argument
$ ssh user@hostname -p 8765
I know what you’re thinking, “based on how we added the user, couldn’t we just add on
:8765 to the end of the hostname to connect via the alternate port?
If you were to try (with or without
user@), you’d get an error about not being able to resolve the hostname.
ssh can’t differentiate the hostname from the port, that is, unless you prefix the entire value with
$ ssh ssh://user@hostname:8765
It’s only a few extra keystrokes, if you’d prefer to go this route.
Configuring for simplicity
Personally speaking though, I hate extra keystrokes, so the previous example including the
ssh:// is too much typing for me.
ssh can leverage configuration files so things like usernames and port numbers can be configured for a particular hostname and omitted entirely when running the
config file lives inside of your
~/.ssh directory and for something like our example server, the configuration would look something like this:
$ cat ~/.ssh/config Host hostname User user Hostname hostname Port 8765
Hostname probably seem a bit redundant if you’re using an actual
hostname, instead of say the IP address of the machine. Some folks configure their
/etc/hosts file, but I prefer to just add the IP address to my
~/.ssh/config and alias it to whatever
hostname I want.
Here’s how my configuration tends to look for a server:
$ cat ~/.ssh/config Host alligator.io User josh Hostname 127.0.0.1 Port 8765
As mentioned, the
Host value can be anything, so it doesn’t actually have to be well formed server address:
$ cat ~/.ssh/config Host gator User josh Hostname 127.0.0.1 Port 8765
Once the file is saved, you can
ssh with just the
Host value that you specified in the configuration:
$ ssh gator
Worth noting, depending on your shell, you probably can tab complete the server name from your
If all went according to plan, you were probably presented with a password prompt and can log in as per the usual.
Ditching that password prompt
Speaking of password prompts, typing passwords takes extra typing, so as we just learned, I will try to avoid it if possible.
One of the most secure ways to avoid entering a password, is by copying your public key to the server. This allows the server to check your local (and secured) private key, against the known public keys on the server.
To copy a key or keys to a server, we’ll be using the
Depending on your local system, you may actually have more than one key available. You are able to copy a specific key over, or all of the keys. I’m going to assume your default key is still in the default place and named
# Copy your default key $ ssh-copy-id -i id_rsa hostname # Copy ALL your keys $ ssh-copy-id hostname
If there weren’t any errors, you should be advised that your key or keys were copied over, and you should be good to
ssh again. If you were to try to
ssh to the server, you should be greeted with the remote command-line, without being prompted for a password!