Off campus computing and remote access

Astronomers living the academic nomad lifestyle (or the global pandemic quarantine lifestyle) may need to access on-campus resources (like their work computers) remotely. What follows is a survey of all the useful tools and resources for remote access to on-campus resources. You may wish to consult the potentially useful vocabulary. Ask in the Slack #code channel if something doesn't make sense!

Authorship & history:

March 12, 2020 Joseph Long — First draft
March 13, 2020 Harry Krantz — Added remote desktop instructions, power management, table of contents
August 25, 2023 Noah Franz & Brock Parker — Updated ssh instructions for connecting to steward work station through ip address (recommended by Steward IT)

Library Access

The UArizona Library offers a service called EZProxy. If you are trying to access a paywalled resource, such as a paper that isn't available on arXiv (it happens!), EZProxy will prompt for your UArizona NetID and redirect you to a proxied version of the page as it would appear from on-campus.

If you don't want to go to the linked page and paste in a URL every time you encounter a paywall, I made a JavaScript bookmarklet that will do the job for you:

javascript:window.location.hostname=window.location.hostname.replace(/%5C./g,%20'-')+'.ezproxy1.library.arizona.edu';

To use, add a new bookmark. Name it "Proxy This Page" (or whatever you like). For the URL, fill in the code from the box above (without any additional http:// or anything). Now, whenever you're on a paywalled page, you can select your "Proxy This Page" bookmark and be redirected to the Library's version (after signing in with NetID).

Example:

Visit https://www.spiedigitallibrary.org/conference-proceedings-of-spie/9148/1/Direct-imaging-of-exoplanets-in-the-habitable-zone-with-adaptive/10.1117/12.2057135.short
Click "Download PDF" and notice it prompts you to log in
Choose your new "Proxy This Page" bookmark and sign in to NetID. If you see a blank white page after signing in, you may need to wait a few seconds to be redirected. (If it still doesn't load, go back and try again. SSO can be wacky.)
Click "Download PDF"

VPN

A VPN is a "virtual private network," which is a way to fool your local computer into thinking it's on a remote network. (For our purposes, the remote network is the UArizona campus network.) UArizona uses the Cisco AnyConnect VPN system, which requires installing a separate client. See https://it.arizona.edu/service/ua-virtual-private-network-vpn for details. You will need to use NetID+ (aka Duo), which means you'll also need access to your phone to confirm your login.

Once you connect your local computer to the VPN, it should stay connected to the VPN for a few days (although you will still have to re-authenticate periodically). Now you can connect to your Steward desktop over SSH as if you were on-campus, view any paywalled journals you want, etc.

SSH

(or: the Poor Astronomer's VPN)

A review of the basics

If you already use SSH, skip ahead for the useful tricks

SSH is a system to use a remote computer from the command-line on your local computer. The command, ssh, is available on macOS and Linux systems by default. (Windows hasn't, historically, but there's new stuff in Windows 10. I'll leave that to someone else to fill in.)

SSH uses a secure, encrypted connection to transfer commands you type to the remote computer. It can also transfer network traffic, making your laptop at home appear to be on-campus (e.g. for loading journal articles or other restricted resources). It can even forward individual applications, letting you open up ds9 as normal from an SSH session and have a window pop up on your laptop at home.

SSH into your Steward Desktop

Make sure you have the UA VPN installed and activated (see the section above)
Get your IP address: Open Settings > Network > Wired Settings (Gear Button) > IPv4 Address.
Then you can then connect via command line to your Steward Workstation using

ssh [email protected]

Where 10.130.XXX.YYY is your ip address, found in step 2 above and username is your steward desktop username (probably the same as your NetID login username). 4. If your laptop is Linux or MacOS you can skip this step. Otherwise, if you use a Windows machine with WSL2 you MUST follow the steps, otherwise the ssh command will just hang: https://gist.github.com/machuu/7663aa653828d81efbc2aaad6e3b1431.

Key-based authentication

One of the most useful things you can set up is key-based authentication. Key-based authentication removes the need to remember a password, while also being more secure.

Generating a key

First, check if you already have a key pair on your local computer. Keys are typically located in ~/.ssh/ with names like id_ecdsa, id_rsa, id_dsa, and so on. The part after the _ is the "cipher", or encryption method, for which that key works. If you have no keys yet, you should probably start with an RSA key. RSA keys are the most widely accepted, but must be generated with an option to enforce a certain key length (4096 bits) to be sufficiently hard to break. If you have an id_rsa and id_rsa.pub pair of files in your ~/.ssh, go on to the next section.

To generate a new RSA key on your local computer:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

You'll be prompted for a location to save the key. Just hit enter.

Enter a file in which to save the key (/Users/you/.ssh/id_rsa): [Press enter]

You'll also be prompted to enter a key passphrase, or hit enter for an empty one. This isn't your NetID password, but a passphrase to protect the key. You can also leave it blank, and make sure not to let anyone get their hands on your computer.

Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]

This will create ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub.

Do not share the id_rsa file, only share the id_rsa.pub half!

Using `ssh-agent`

If you use a key passphrase, but get tired of typing it, ssh-agent can help. It only requires you to type your key passphrase to load the key into memory, storing it there for reference as needed by ssh. The correct use of ssh-agent depends on your OS, so I won't cover it here. GitHub offers a good guide (though the agent isn't a GitHub-specific thing, by any means). Be sure to select your OS at the top of the page.

Installing your key on a remote computer

To use your key for logging in, you must copy the public key (the text in the .pub file) into the ~/.ssh/authorized_keys file on the remote machine.

Get a terminal on the remote machine (e.g. ssh username@hostname from your local machine, and enter your password)
Open ~/.ssh/authorized_keys in a text editor and add a new line at the end (e.g. nano ~/.ssh/authorized_keys)
Paste in the contents of ~/.ssh/id_rsa.pub from your local machine into the authorized keys file
Save and close.

You should now be able to ssh to the remote machine without entering a password. (Only, if you created one, a key passphrase.)

Useful tricks

Shorthand names for remote hosts

If you get tired of typing ssh [email protected] all the time, you can use ~/.ssh/config to save time. Say your Steward-provided desktop is named stewarddesktop.as.arizona.edu and your username is mynetid but you'd rather just type ssh stewdesk. Here's a config example for that:

Host stewdesk stewarddesktop.as.arizona.edu
    HostName stewarddesktop.as.arizona.edu
    User mynetid

Now ssh stewdesk will look up the hostname and username from your config, saving you untold seconds of time. (This only works on-campus or on VPN, but see the next trick...)

Reach your Steward desktop via Lavinia (and forget about the VPN)

Graduate students can request accounts on lavinia.as.arizona.edu by emailing the helpdesk [email protected]. Once you have an account there, you can proxy connections to your Steward desktop or other on-campus resources via Lavinia (which is accessible publicly). Install your SSH key on lavinia following the instructions above, then tell SSH to proxy connections to your Steward desktop. This is easiest to configure by editing ~/.ssh/config:

Host lavinia lavinia.as.arizona.edu
    HostName lavinia.as.arizona.edu
    User usernameforlavinia
Host stewdesk stewarddesktop.as.arizona.edu
    HostName stewarddesktop.as.arizona.edu
    User mynetid
    ProxyJump lavinia

Replace stewarddesktop with the name of your Steward desktop computer.

Note this works equally well for other hosts that are available from outside. It's possible your advisor already has a publicly-accessible machine you can SSH to (and hence proxy connections through).

Leave stuff running after you disconnect with `tmux`

The tmux command creates a sort of a "window-within-a-window". Log in to your remote host, run tmux, and you'll get a normal command prompt. This new prompt, however, is inside the tmux session, meaning you can "detach" from it and "reattach" later. An example, for some notional host named remote:

Connect to remote and run tmux
```
local$ ssh remote
remote$ tmux
```
The screen will clear, and you'll have another prompt. Say you want to run a command that runs forever, like top for monitoring.
```
remote$ top
[screen is cleared, replaced by CPU usage monitor]
```
Now, you need to stop working for a while, but you don't want to quit top. Use Ctrl+b followed by d to detach. The screen clears, replaced by your last commands outside tmux (including starting tmux).
```
remote$ tmux
[detached (from session 0)]
remote$
```
You can now log out of SSH, go do something else, and come back a while later. To get your session back, run:
```
local$ ssh remote
remote$ tmux attach -d
```
and your display will be replaced by the CPU monitor you left running. (Note the -d option ensures the session is detached from other terminals, which is useful if you get disconnected unexpectedly and don't have the chance to Ctrl+b and d.)

This doesn't just restart top, it really was there running this whole time!

Forward GUI programs

You can get a terminal on your remote machine easily, but what if you wanted to check something in ds9 or another graphical program? Fortunately, you can run graphical programs over SSH. If you use macOS, you'll need XQuartz (which you might already have, being an astronomer). Start your session with ssh -XY stewdesk and then start any program you like.

You can make those options default for stewdesk by changing the config to include:

Host stewdesk stewarddesktop.as.arizona.edu
    HostName stewarddesktop.as.arizona.edu
    User mynetid
    ForwardX11 yes
    ForwardX11Trusted yes

Next time you reconnect to stewdesk, you can run ds9 and it should pop up on your local machine.

Forward Jupyter notebooks / JupyterLab

Since the Jupyter notebook / JupyterLab interfaces are web applications, you can use your browser to access them remotely.

When you run jupyter notebook in a terminal normally, you see something like this:

[I 15:44:28.157 NotebookApp] The Jupyter Notebook is running at:
[I 15:44:28.157 NotebookApp] http://localhost:8888/?token=8e0df0ad5bfd4ca1057d1295e427508b5c5a2f4126397904
[I 15:44:28.157 NotebookApp]  or http://127.0.0.1:8888/?token=8e0df0ad5bfd4ca1057d1295e427508b5c5a2f4126397904

That URL points to localhost at port number 8888. When you're running the notebook on a remote computer, localhost will not map to the computer where the notebook is running. To address this, we use SSH port forwarding. We will tell the notebook to run on port 9000, and then map port 9000 on our local machine to forward traffic to port 9000 on the remote machine.

Connect to the remote machine using the command ssh -L 9000:localhost:9000 stewdesk. The -L option sets up the port forwarding.
Start or attach to a tmux session
Start the Jupyter notebook with jupyter notebook --no-browser --port=9000
Copy the http://localhost:9000/?token=... link from your terminal and paste it in your browser

This will leave the notebook server running, even if your local machine gets disconnected. You can detach manually as with any tmux session: Ctrl+b followed by d.

To reconnect, use ssh -L 9000:localhost:9000 stewdesk again and open http://localhost:9000 in your browser. (You don't need the full URL with the token unless you've changed computers. If you have, attach with tmux attach and copy the link again.)

Note that you'll get a warning if you start more than one instance of ssh with the same port forwarded. If you want to use this trick on two different remote computers, you will need to choose different port numbers (e.g. 9000 and 9001).

Remote Desktop

If you are not as computer savvy or would just prefer a full Remote Desktop experience this section is for you. There are many methods of accessing a computer remotely and the following are not the only ways, merely my preferred methods.

Note that Remote Desktop Protocol (RDP) is a specific technology created by Microsoft and does not refer to remote desktop in general. RDP is not covered here because I am not knowledgeable of it.

Chrome Remote Desktop

Chrome Remote Desktop is a great web app available on Chrome and allows you to access computers via your Google account. A hosting app must be installed on the computer you wish to remotely connect to. Once setup you can access from any computer running Chrome with just your Google account. Additionally you can temporarily share your desktop with someone else via a 12 digit code.

Here are Google's instructions for setting up Chrome Remote Desktop.

It works on Windows and Mac. It does NOT* work on Ubuntu.

*I once had it working on Ubuntu but it has since stopped working after some update. Search results will also lead one to believe that it should work with Ubuntu but my attempts were unsuccessful. If you are successful in getting it to work please add it here.

VNC

Virtual Network Computing (VNC) is the old-school method of remote desktop connection and is built-in to many Unix-based operating systems including Ubuntu. There are many paid VNC services which offer deluxe features but this is not required for basic use.

To setup VNC on your Ubuntu* machine:

Search for "Desktop Sharing" and open the menu
Check the boxes for allowing others to view and control your desktop
Check the box to require a password and enter a password of your choice
Get your machine's IP address and write it down somewhere. You can find this under Settings->Network->Wired->IPv4 or use the appropriate terminal command.

*Instructions for 16.04, will differ slightly for other versions

To connect to your machine you will need a VNC viewer on another computer. If you're using Ubuntu or Mac there is a built-in option. For Windows you'll need to download a third-party app. For Ubuntu the built-in app is called "Remmina". On Mac the app is hidden for some reason.

To connect to your machine from off campus you will need to connect to the VPN first.

To remotely connect to your machine from a Mac:

Open a browser and type in the address as vnc://ip-address
It will prompt you to open "Screen Sharing"; alternatively you can open Screen Sharing directly via Spotlight search
Enter the password you set earlier
You should now see your Ubuntu desktop and be able to control it
(Optional) You can save the connection address as a bookmark in your browser or use the "Save As..." function inside "Screen Sharing" to save a shortcut to the desktop or elsewhere

Notes on Security

The security of a remote desktop connection depends on the software used. Assume the connection is unencrypted unless the software specifies otherwise. This means it's possible someone could snoop or hijack the connection, though as long as you're going through the University VPN you should be safe.

Additionally while you are connected to your machine with remote desktop, the physical computer is vulnerable i.e. someone could sit at your desk and use your computer since it is unlocked while you are using it. At the very least I recommend turning off your monitor so people don't see when you're connected and what you're doing. Also make sure to set your user account to auto-lock after some period of time so it doesn't remain unlocked after you close the remote connection (or just lock it manually before you disconnect).

Use your own judgement regarding what security protocols you need for your work.

Keeping Your Computer On

It should go without saying but if your computer is off you will not be able to connect to it. Power outages at Steward are uncommon but they do occur. You should enable the boot after power failure setting in your motherboard BIOS so your computer will automatically turn on after a power outage.

Instructions for ASRock motherboards:

Restart the computer and enter the BIOS by hitting the F2 key
Enter the "Advanced Menu"
You can find the relevant setting under Advanced->Chipset Configuration->Restore on AC/Power Loss->Enable
Exit and save changes

These steps should be similar for most motherboards but search on Google or check the manual if you cannot find the setting.

In addition to the above, a better solution is to get an Uninterruptible Power Supply (UPS). This a battery backup which will power your machine for a short amount of time in the event of a power outage (or a long time if you've got the cash). If properly setup the UPS will also safely shutdown your computer before the battery runs out.

HPC

Good news if you have an HPC account! The University of Arizona HPC system is accessible from "outside" with some caveats. First, you will be subject to tedious NetID+/Duo prompts when you log in over SSH. Second, you want to connect to one of the HPC systems (ocelote or elgato), but you will only be able to connect to hpc.arizona.edu (the "bastion" host, for logging in to the clusters) and filexfer.hpc.arizona.edu (which, as the name suggests, is only set up for file transfers to/from HPC storage).

To take care of the first annoyance, read the section on SSH and install your public key on hpc.arizona.edu. To do so, first SSH in with ssh [email protected]. Next, copy the contents of your local ~/.ssh/id_ecdsa.pub (or other public key file) into the clipboard. Now, open ~/.ssh/authorized_keys on the remote host in your favorite text editor (or nano, nano is fine). Paste in the text you copied on a line by itself. Save, close, and log out.

Now, when you ssh [email protected], you should be logged right in. It's still another step to get in to Ocelote or El Gato. Fortunately, we can do something about that as well!

From hpc.arizona.edu, type ocelote to log in to an Ocelote login node. On ocelote, use your favorite command-line text editor to edit ~/.ssh/authorized_keys (note this is a different file than the same location on the bastion host). Add a new line at the end, and paste the contents of your local ~/.ssh/id_ecdsa.pub (or other public key file). Don't delete any of the existing lines, as the HPC system added those automatically and they're necessary for various features to work!

Next, open your SSH configuration (~/.ssh/config) and add the following:

Host hpc hpc.arizona.edu
    HostName hpc.arizona.edu
    User mynetid
Host ocelote login.ocelote.hpc.arizona.edu
    HostName login.ocelote.hpc.arizona.edu
    User mynetid
    ProxyJump hpc
Host elgato login.elgato.hpc.arizona.edu
    HostName login.elgato.hpc.arizona.edu
    User mynetid
    ProxyJump hpc

Now you can go directly to ocelote with ssh ocelote or elgato with ssh elgato from your local computer. The configuration above will proxy all traffic through the bastion host as normal, saving you time and keystrokes.

Appendix

Potentially useful vocabulary

host - a computer
hostname, domain name, fully-qualified domain name - the names a computer is known by on a network (e.g. lavinia, lavinia.as.arizona.edu). "Fully-qualified" means going all the way out to .arizona.edu so it's unambiguous which computer you mean. (Generally a good thing when accessing stuff remotely.) Your Steward-provided desktop's name + .as.arizona.edu = its fully qualified domain name.
local host - a computer you're sitting down at and interacting with using its own monitor/keyboard/mouse
remote host - a computer that you can reach over a network
proxy - a service that relays data between two hosts, optionally allowing access to otherwise inaccessible resources (also a verb for the act of such relaying)
credentials - anything that logs you in. most commonly, a username and password. sometimes a key pair.
private key and public key - Magic strings of text representing numbers that have a very special mathematical relationship. The private key encrypts in such a way that only the public key can decrypt, and vice-versa.
key pair - a private key and a public key that go together
single sign-on (or SSO) - login system that allows using a single set of institutional credentials to gain access to multiple services
two-factor authentication (or 2FA) - login system requiring you to prove two things before granting access. generally this is "something you know" (password) and "something you have" (phone/SMS, biometrics)
NetID+ aka Duo - UArizona's 2FA login system using phone calls, SMS, push notifications to a phone, or (when all else fails) recovery codes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Off campus computing and remote access

Table of Contents

Library Access

VPN

SSH

A review of the basics

SSH into your Steward Desktop

Key-based authentication

Generating a key

Using `ssh-agent`

Installing your key on a remote computer

Useful tricks

Shorthand names for remote hosts

Reach your Steward desktop via Lavinia (and forget about the VPN)

Leave stuff running after you disconnect with `tmux`

Forward GUI programs

Forward Jupyter notebooks / JupyterLab

Remote Desktop

Chrome Remote Desktop

VNC

Notes on Security

Keeping Your Computer On

HPC

Appendix

Potentially useful vocabulary

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally

Off campus computing and remote access

Table of Contents

Library Access

VPN

SSH

A review of the basics

SSH into your Steward Desktop

Key-based authentication

Generating a key

Using ssh-agent

Installing your key on a remote computer

Useful tricks

Shorthand names for remote hosts

Reach your Steward desktop via Lavinia (and forget about the VPN)

Leave stuff running after you disconnect with tmux

Forward GUI programs

Forward Jupyter notebooks / JupyterLab

Remote Desktop

Chrome Remote Desktop

VNC

Notes on Security

Keeping Your Computer On

HPC

Appendix

Potentially useful vocabulary

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally

Using `ssh-agent`

Leave stuff running after you disconnect with `tmux`