Common SSH Tips and Info

If you deleted the "@internal1" key from your profile

As long as you have at least one public key configured in your profile, use your SSH client to connect to gw.orbit-lab.org and run the following commands there. You do not need to make a reservation in the scheduler for this.

rm ~/.ssh/id_rsa
rm ~/.ssh/id_rsa.pub
ssh-keygen -t rsa -C "@internal1"

Press 'Enter' at every prompt so that the default filename (id_rsa) and no password is used.

Then type the following command:

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

The internal key should now be restored.

Prevent unknown host key error when connecting to node

Configure you ssh client not to use strict host key checking

For openssh, this is -o StrictHostKeyChecking=no or the same in the .config file

Using a .config file for SSH (Linux, Mac, and WSL ONLY)

We'd like to do a few things for convenience:

1. log into nodes as root by default
2. allow forwarding of X11 applications
3. Suppress annoying host key warnings

First, log into any console, or gw.orbit-lab.org

After logging in, create or modify the file at ~/.ssh/config

Add the following to the file

Host sdr?-md* sdr?-s?-lg* srv?-co* srv?-lg* node?-* node??-*
  User root
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  ForwardX11 yes

• Host: The Host line matches common naming conventions for nodes within the testbed
• User: root is set to match the common default for baseline
• UserKnownHostsFile: is set to /dev/null to prevent saving new host keys for nodes
• StrictHostKeyChecking: disables the warning message. SSH complains when host keys for a dns name change. This is a useful security feature, but is inconvenient within the testbed, where the operating system on a trusted machine changes frequently. Do not set it as a wildcard default for public endpoints, or you will be vulnerable to spoofing or man in the middle attacks.
• ForwardX11: allows the forwarding of graphical applications running the X11 protocol from a node back to your machine

Tips for working on a remote system

Handling sessions and disconnections

To avoid losing your place if disconnected, use something like ​Tmux. This will allow you to have multiple tabs, or windows, with a single ssh connection. In addition, you'll be able to reconnect to this set-up if your connection drops.

Warning: On the consoles, when your reservation ends, all of your processes will be killed, including tmux sessions.

File management

To move files between your machine and the consoles, the simplest method is something like SCP. For a graphical client, one example is FileZilla, over scp or sftp.

To move files to a node, this is normally a two step process. Local → Console, Console → node.

By using a ProxyJump directive in your local machine's ~/.ssh/config file, you can do this in "1" step, but this is an advanced method. When accessing the node, your ssh client with automatically proxy the connection via the console.

An example file is:

Host node1.cosmos-lab.org
User root
ProxyJump console.cosmos-lab.org

For development on nodes, we recommend using git, and having both your local machine and the console or node pull from the repo.