Command-line Basics: Working Remotely with SSH

joshtronic

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.

Getting started

The 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 hostname and user for your own server’s hostname and your user account.

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 @ symbol:

$ ssh user@hostname

Specifying the port can be done via the argument -p:

$ 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 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.

Fortunately, 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 ssh command.

The base 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

The Host and 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 ~/.ssh/config file!

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 ssh-copy-id command.

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 id_rsa:

# 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!

  Tweet It

🕵 Search Results

🔎 Searching...

Sponsored by #native_company# — Learn More
#native_title# #native_desc#
#native_cta#