wiki:UserGuide/RemoteAccess/SshTips

Version 2 (modified by msherman, 5 years ago) ( diff )

—

Site Navigation

  1. COSMOS Testbed Overview
    1. Concepts
    1. Testbed Workflow
    1. Availability and Resource Status
    1. Events and Conferences
  6. Getting Started
    1. Make an Account
    2. Create and Configure SSH Keys
    3. Make a Reservation
    4. Log in to your Reservation
    5. Control Resources with OMF
    6. Run a Hello World Experiment
    7. Get Help and Support
  7. User Guide
    1. Policies
    1. Account Creation
    1. Scheduling and Reservations
    1. Disk Images
    1. Frequently Asked Questions
    1. Resource Control with OMF
    1. Remote Access
    1. Chrome Remote Desktop Setup Page
    1. Measurement & Result Collection
    1. Storage
    1. Support
    1. Contributing to the Wiki
  20. Tutorials
    1. SDR and Wireless
    2. Optical Networking
    3. Wired Networking
    4. Edge Computing
    5. 4G/5G Systems
    6. Orchestration Platforms
  21. Architecture
    1. Data Flow
    1. Deployment Map
    1. Domains
    1. Naming Convention
    1. Networks
    1. Optical
  28. Resources, Services and APIs
    1. RF Control
    2. SDR Control
    3. Compute Control
    4. Network Control
    5. Optical Control
  29. Datasets
  30. Hardware Info
    1. Cameras
    1. Compute
    1. Network
    1. Nodes
    1. Optical
    1. RF Subsystems
    1. Antennas
    1. Full-Duplex Radio
    1. RF Front End
    1. Software Defined Radios (SDR)
  41. RF Policies & Compliance
    1. Outdoor Radio Frequency Allocation
    2. Program Experiment License
    3. Spectrum Monitoring
    4. Emergency Stop Procedures
    5. Network and Platform Security

SSH Tunneling

A common need is to connect to some resource on the testbed as if it were local. SSH provides this functionality. Go to the Configuring SSH Tunnels tutorial to learn how to configure these.

Common SSH issues

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.

Common ssh options for nodes

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
Note: See TracWiki for help on using the wiki.