This document describes server resources and how to connect for development.
| Projects | hardware specs | OS | |
|---|---|---|---|
| granger1.cs.virginia.edu | p1-p4 | Dual Xeon 2630v4 Broadwell (10c20t), 20 cores | Ubuntu 20.04 LTS |
| granger2.cs.virginia.edu | p1-p4 | Dual Xeon 2630v4 Broadwell (10c20t), 20 cores | Ubuntu 20.04 LTS |
| All but p2 | Single Xeon Silver 4410 CPU (8c16t), 8 cores | Ubuntu 20.04 LTS |
These servers are behind the campus firewall. You need to first SSH to portal.cs.virginia.edu, and from there SSH over to the course servers, e.g. labsrv06. This is described here.
WARNING: portal is managed by the UVA IT. You use your existing computing ID & password. The course server is managed by cs4414 staff. Use the credentials that we share with you.
Figure above: your local machine, the portal, and the server. Texts on the bottom: key files and their purpose.
$ ssh [email protected]
(type in password...)
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Sun Jan 24 16:48:29 2021 from c-71-62-166-85.hsd1.va.comcast.net
********************************** **********************
Type "module avail" to see software available.
See: www.cs.virginia.edu/computing for more information.
$ ssh [email protected]
(type in password...)
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-45-generic x86_64)
Connecting to the course servers can be automated.
The picture shows the final results: From a local terminal (e.g. my minibox), connecting to a course server by simply typing ssh granger1. Read on for how to configure.
Applicable local environment: Linux, MacOS, & Windows (WSL)
The pub key on your local machine is at ~/.ssh/id_rsa.pub. Check out the file & its content. If it does not exist, generate a pub key by running ssh-keygen.
# on the local console (Linux or WSL)
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/xzl/.ssh/id_rsa):
Now, append your public key to both portal and granger1 (~/.ssh/authorized_keys).
Don't do this manually. Instead, do so by the command ssh-copy-id. For instance:
# copy the pubkey from your local machine to portal
$ ssh-copy-id [email protected]
(... type in password ...)
# connect to "portal", it should no longer ask for password
$ ssh [email protected]
# now we are on "portal". generate a new pair of public/private keys, which will be used between portal and granger1
$ ssh-keygen
# copy the new public key from portal to granger1
$ ssh-copy-id [email protected]
(... type in password ...)
# it should no longer ask for password
$ ssh [email protected]
An alternative procedure (02/07/21) Credits Peiyi Yang, TA 2021.
Started from scratch. First edited the ssh config file on the local computer saying to jump through portal when going to granger1. Then ran ssh-copy-id id@portal and entered the password to install the local's pubkey on portal. Then from local, ran ssh-copy-id id@granger1 and entered the password to install the local's pubkey on granger1.
So there is only one key pair. The pubkey is copied to portal and then to granger1.
Let's use granger1 as an example.
- On granger1, check the content of ~/.ssh/authorized_keys. You should see your public key saved there. For instance, mine is:
$ cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCkkCZ2PO7GdX5CBL26zcIFz4XgMiHSQjaU32evuidvMXsC
ZExT9QHl3Ou00QfuagmfebugxB0aruGAsKmBxEBmlj0r1uAVCekYaIn8IPA5jynQnDRDdIABaZBWlsPx9jKo
KQqLlKgdG4JziQOAr0HaUgr+oIXgRUq7V/W1OhV9SQVF+vcIy8vVwNdLBNdbw/GtU0oKb76yxfXOC/VZM7eZ
xhovb/J450U5Op8tL/+Lg5x2sJKqR2juCFAicGbVNuXXazEDrXHgDQp+WQS8rYK4Zs95KqAsMfxvsFSbs8lf
h0pIs+sozBNUt+1noJkcyLfxhzu0yGEsxMULHE/KdAst xl6yq@portal03
"xl6yq@portal03" is the textual tag of the pubkey, indicating it is a pubkey generated on portal.cs
- On granger1, check the permission of ~/.ssh. It should be:
$ ls -la ~ | grep .ssh
drwx------
Check the permission of ~/.ssh/authorized_keys. It should be:
$ ls -l ~/.ssh/authorized_keys
-rw-------
If none of the above works, you can put ssh in the verbose mode to see what's going on. From portal, type
ssh -vv granger1.cs.virginia.edu
Explanation: -vv tells ssh to dump its interactions with granger1 on negotiating keys. As a reference, my output is here. At the end of the output, you can see granger1 accepts my key offered from portal.
Can do password-less authentication between local/portal and between portal/granger[12], but are still required to enter password between local/granger? From your local machine, type
ssh -vv granger1.cs.virginia.edu
And compare line-by-line with the output to the reference output here.
Note to Windows Users: if you try to invoke ssh-copy-id that comes with Windows (the one you can invoke in PowerShell, not the one in WSL), there may be some caveats. See here. I would say just invoke ssh-copy-id in WSL.
Append the following to your ssh client configuration (~/.ssh/config). Replace USERNAME with your actual username:
Host granger1
User USERNAME
HostName granger1.cs.virginia.edu
ProxyJump [email protected]:22
With the configuration, your local ssh client knows that when connecting to host granger1, use portal as the jump proxy. So you can directly connect to granger1 from your local machine:
$ ssh granger1
$ ssh -l USERNAME granger1.cs.virginia.edu -J portal.cs.virginia.edu
The -J option is available with your local ssh client OpenSSH >= 7.3p1. See here for more details. For instance, my version:
$ ssh -V
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
Many students may prefer VSCode. Here is how to make it work for our kernel hacking.
End results: being able to develop, compile, and do version control from VSCode. See an example screenshot below.
So we will use VSCode's official Remote.SSH extension. I do not recommend 3rd party extensions, e.g. sftp.
An official tutorial is here.
tl;dr: VSCode will connect to the course server (Linux) using SSH under the hood. To do so you install the "Remote development" package which will install the "Remote.SSH" extension for VSCode.
Screenshot from Peiyi Yang (py5yy@). Her VSCode color scheme is different from mine.
The extension (Remote.SSH) will invoke Window's ssh client (c:\Windows\System32\OpenSSH\ssh.exe).The Window's ssh client expects its config file at C:\Users\%USERNAME%\.ssh\config. This is NOT the ssh client you run from WSL.
If you haven't generated your SSH keys so far, you can do so by launching a PowerShell console and run ssh-keygen there.
 |
 |
 |
|---|---|---|
| Launch PowerShell | ssh-keygen in PowerShell | Access WSL root |
Or, you can you copy existing ssh keys and config (e.g. from WSL ~/.ssh/) to the location mentioned above. Btw, the way to access WSL's root filesystem is to type \\wsl$ in the explorer address bar. See the figure above.
The current VSCode has a bug that breaks ssh with jumphost. You have to manually fix it by following this. In a nutshell, manual download a newer win32 ssh to overwrite the one shipping with Win 10 (it's a good idea to save a back up). Window's security mechanism is in your way. Work around it.
Note: 1. Make sure to download the OpenSSH-Win64 version (not Win32). 2. Double check the SSH version. See the screenshot below.
 |
 |
|---|---|
| Turning off protection on ssh.exe (see link above) | The newer ssh client manually installed |
Now, you should be good to go with VSCode.
Make sure you have the Remote.SSH extension installed. Click "Remote Explorer" on the left bar. The extension will pick up your ssh config file (again that's C:/Users/%USERNAME%/.ssh/config) and present a list of hosts recognized. Click one to connect to it. The extension will copy a bunch of stuffs to the host and launch some daemon on the host. Then you are connected.
Password-less login used to work fine, but suddenly breaks? A common cause is that VSCode updates automatically, overwriting the ssh client you manually installed. Solution: check your ssh version and use the one we suggested.
After connection, click "remote" on the left bar to bring up a remote terminal, in which you can execute commands to build projects, etc. Make sure to click the "+" sign to create a new shell terminal.
Then you will specify a remote folder on the server to "open":
To browse & edit files on the server, click "explorer" on the left bar
Click "source control" on the left bar for a handy git interface.
Windows auto update may break VSCode's ssh configuration that worked previously. In this case, deleting (or moving to other places) the .vscode-server folder on granger and portal may solved the problem.
If things break, report:
- the error message of VSCode
- the PowerShell output when you try to connect to granger1 from the PowerShell command line
- the PowerShell output when you try to connect to cs portal from the PowerShell command line
- any recent Windows/VSCode updates