SSH Tips

Some practical tips on using ssh.

SSH without passwords

Why would you want to do this?

  • All the systems at Nevis will block your IP address after a given number of failed login attempts. If you have trouble remembering your password, setting up password-less ssh may be a good idea.

  • Every time you type your password, there's a certain security risk. Someone could observe what you're typing, or a hacker might have installed a key-logger on your system.

  • Since you don't have to type in your password every time you login, it encourages you to come up with a complex password (with apg or dicewords, for example) and storing it in a password manager just in case.

The chief disadvantage is that anyone who's obtained access to the client system (e.g., your unlocked laptop) can ssh into the host system.

The steps are:

  • Generate an ssh key using ssh-keygen if you don't already have one:
    ssh-keygen -t ed25519
    You will prompted for a passphrase. You can just hit RETURN for now; see the discussion of passphrases below.

  • Copy your ssh public key to the host system with ssh-copy-id. For example, if you want password-less ssh to olga.nevis.columbia.edu:
    ssh-copy-id account@olga.nevis.columbia.edu

From that point forward you'll be able to login to olga.nevis.columbia.edu without typing a password.

Password-less ssh and Nevis automount

ssh-copy-id works by modifying files in the ~/.ssh/ directory on the host system. At Nevis, everyone's home directory on all the systems on the Nevis Linux cluster are linked via automount.

The practical consequence is that if you set up password-less ssh on olga.nevis.columbia.edu, and both olga and sofia are systems on the Linux cluster, then you'll have password-less ssh for both olga and sofia.

If you then repeat the above steps while logged into olga, and use ssh-keygen and ssh-copy-id on olga itself:

# on olga
ssh-keygen -t ed25519
ssh-copy-id olga
then you can ssh between olga, sofia, tatiana, etc., without typing a password.

(This step has you creating a brand-new private key on olga, as opposed to duplicating the key stored on your laptop. I recommend this, to make sure your laptop's private key isn't stored on a Nevis system. It's not likely it would become an issue (pretty much the only person who can see a private key stored on the Nevis Linux cluster is me) but it doesn't hurt to be safe.)

Automatic double-hopping

Many of the Nevis systems, especially those involved in electronics testing, are protected by our firewall. This means that you have to "double-hop" to get access to these systems from outside Nevis: First you login to a "bastion host" that's visible to the outside world, then to the system within the firewall.

At Nevis, a "bastion host" or "login host" would be one of houston, kolya, milne, shang, tehanu, or xenia, depending on your research group.

For these examples, assume the name of your bastion host is bastion.nevis.columbia.edu and you're trying to access the internal system falkor.nevis.columbia.edu. For the sake of generality, assume the name of your account on bastion is account1 and the name of your account on falkor is account2.

You could do this explicitly in two steps:

ssh account1@bastion.nevis.columbia.edu
ssh account2@falkor.nevis.columbia.edu

You can also do this in one line:

ssh -J account1@bastion.nevis.columbia.edu account2@falkor.nevis.columbia.edu

This works, and you can deal with the long command line by using an alias.

There's another way to do it: Use a ~/.ssh/config file to specify automatic options to be supplied to the ssh command.

In this example, assume you put the following lines into your ~/.ssh/config file:

Host bastion.nevis.columbia.edu
   user account1

Host falkor.nevis.columbia.edu
   user account2
   ProxyJump account1@bastion.nevis.columbia.edu

Then you could type this on the command line to "double-hop" directly into falkor:

ssh falkor.nevis.columbia.edu

Automatic X11 forwarding

You can use ~/.ssh/config to automatically specify any option that you could otherwise put on the ssh command line.

One of the most frequent options that I use is X11 forwarding; e.g.,

ssh -XY account@bastion.nevis.columbia.edu

If you keep forgetting to type -XY, you could put the following in ~/.ssh/config:

Host *.nevis.columbia.edu
    ForwardX11 yes
    ForwardX11Trusted yes

Or if you want to forward an X11 connection to all the systems you login to, not just the ones at Nevis:

Host *
    ForwardX11 yes
    ForwardX11Trusted yes

Passphrase

When you run ssh-keygen, you're prompted for a passphrase.

A passphrase is not a password. With a password, some (hopefully) encrypted version of your password is sent over the network. A passphrase does not go over the network. It's used for a separate encryption of the ssh key on your system.

If you created a passphrase when you created your ssh key using ssh-keygen, you'd type in your passphrase every time your ssh key was accessed. While this is more secure, for the kind of work we do it can quickly become tedious.

The ssh-agent and ssh-add programs are a way around this. When you use them, you only have to type your passphrase once, when you invoke ssh-add after logging into your laptop. Then ssh-agent sits in the background, supplying the passphrase(s) whenever you make an ssh connection that requires one.

The way to use the programs:

eval `ssh-agent`
ssh-add

At that point you'll be prompted for the passphrase(s) associated with any ssh keys you've created.

For the kind of work we do, using a passphrase is probably unnecessary. The chief reason to use one is if you're concerned about protecting of your ssh key on your local system (e.g., your laptop). If someone takes your laptop, they could get access to any keys stored in ~/.ssh in your home directory. A passphrase would protect those keys.

If you created a private key with ssh-keygen without a passphrase, and you want to add (or change) the passphrase for the key, the command is:

ssh-keygen -p

If you open multiple Terminal windows and separately use ssh in each of them (I do this constantly), then you'd have to set up ssh-agent in each window separately. ssh-agent and ssh-add only apply to your current login session, not to your entire system. Again, for the kind of work we do, this an argument against passphrases and agents.

None of this is perfect

There are security issues associated with all of the above tips. For example, if you tend to walk away from your laptop leaving it unlocked, then ssh-agent can't protect you; if a hacker gains access to bastion then they can inspect sockets and monitor your network traffic.

You have to assess your own tolerance for risk.

Typing "nevis.columbia.edu" all the time

This has nothing directly to do with ssh, but it's something to consider to make life easier.

You have have noticed that in all of the above examples, the domain nevis.columbia.edu is always given explicitly.

However, if you've used your laptop at Nevis, you don't have to do this. You can type:

ssh bastion

...and you'll be connected to bastion.nevis.columbia.edu.

The reason is that WilliamSeligman has set the default search domain for the Nevis DHCP server to be nevis.columbia.edu. When you type a host's name like bastion, the name resolver will automatically try that name with nevis.columbia.edu appended to it.

That's fine when you're at Nevis. What about when you're not?

You can specify additional search domains on your laptop. The procedure varies between OSes, so it's probably simplest for you to do a web search on "add search domain" for your operating system. For example, here are the instructions for MacOS.

You can put in more than one search domain. For example, you can include nevis.columbia.edu, columbia.edu, bnl.gov, cern.ch, in2p3.fr, slac.stanford.edu as additional search domain. Then when you type ssh bastion, the system will look up bastion.nevis.columbia.edu, bastion.columbia.edu, bastion.bnl.gov, bastion.cern.ch, etc. It will attempt these names in the order of your search domains; if there's both a bastion.nevis.columbia.edu and a bastion.cern.ch, given the example search order it will find the Nevis one first.

-- William Seligman - 2025-11-01

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2025-11-01 - WilliamSeligman
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback