Development Environment and Course Setup¶

Overview¶

This first hands-on lab session establishes the development environment used for the entire CS 315 Computer Architecture course. The goal is to get every student able to reach the CS Department's remote RISC-V hardware (the BeagleV-Ahead boards), called the Beagle machines, from their own laptop, using passwordless SSH key authentication. We walk step by step from generating an SSH key pair, to copying the public key to the Stargate gateway server, to configuring an ~/.ssh/config so that a single short command connects you all the way through to a Beagle board. Along the way we cover the command line, the micro console editor, GitHub SSH access, and an optional local RISC-V virtual machine. This page is tied to the Lab 01 deliverables and the Dev Setup guide.

Learning Objectives¶

Explain why CS 315 uses both remote RISC-V hardware (BeagleV) and an optional local emulated RISC-V VM
Describe how SSH public-key cryptography enables secure, passwordless login
Generate an Ed25519 SSH key pair and protect the private key with a passphrase
Copy a public key to a remote machine and append it to authorized_keys
Write an ~/.ssh/config that connects to Stargate and proxies through to a Beagle machine with one command
Set correct file permissions on key files and diagnose "permission too open" and "still asking for password" failures
Navigate the shell and edit files remotely with the micro editor
Configure SSH access to GitHub so repositories can be cloned from the Beagle machines

Prerequisites¶

A laptop running macOS, Linux, or Windows with the Ubuntu Windows Subsystem for Linux (WSL)
A terminal program (Terminal/iTerm on macOS, the Terminal app on Linux, Ubuntu WSL on Windows)
A USF/CS username and your 8-digit USF ID (CWID), which is your default Stargate password
A GitHub account
The USF VPN installed if you are working from off campus (myusf.usfca.edu/vpn)

1. The CS 315 Development Topology¶

CS 315 teaches computer architecture using the RISC-V instruction set architecture (ISA), an open, royalty-free, modern ISA. You will write C and assembly that runs on real 64-bit RISC-V Linux. There are two ways to get a RISC-V environment:

Remote BeagleV-Ahead boards (required). The CS Department runs five real RISC-V boards: beagle1 through beagle5. You reach them over the network. This is the environment your labs and projects are graded on, so everyone must be able to use it.
Local RISC-V VM with QEMU (optional, encouraged). You can emulate RISC-V on your own laptop. This is convenient when you are offline, but it is not a substitute for being able to work on the Beagle machines.

The catch with the remote boards is that they live inside the CS network and are not directly reachable from the open internet. You first connect to a public gateway machine, Stargate (stargate.cs.usfca.edu), and from there reach a Beagle board. This three-tier topology is exactly what the handwritten lab diagram shows.

flowchart LR
    subgraph You["Your Laptop"]
        L["Terminal<br/>(holds PRIVATE key)"]
    end
    subgraph CSnet["CS Department Network"]
        S["Stargate gateway<br/>stargate.cs.usfca.edu<br/>(holds your PUBLIC key)"]
        B1["beagle1"]
        B2["beagle2"]
        B3["beagle3"]
        B4["beagle4"]
        B5["beagle5"]
    end
    L -->|ssh| S
    S --> B1
    S --> B2
    S --> B3
    S --> B4
    S --> B5

The handwritten board diagram drew the laptop on the left with private key + public key, Stargate in the middle holding the public key in its .ssh directory, and a stack of five Beagle boxes on the right. The black arrows showed the first hop (ssh laptop → Stargate) and the red arrows showed the second hop (Stargate → Beagle). The important takeaways from that picture:

The private key never leaves your laptop.
Your public key is copied to Stargate, where it is appended to ~/.ssh/authorized_keys.
Because Stargate and all five Beagle machines share the same home directory over the network, configuring keys once on Stargate makes them work on every Beagle board automatically.

Tip from lab: bump up your terminal font size before you start. Almost every "it doesn't work" turns out to be a typo in a path, a username, or a hostname that is easy to miss at small font.

2. Command Line Refresher¶

You will live in the shell this semester, so a quick refresher. The shell prompt ends in $ (bash/sh) or % (zsh, the macOS default). The text before it usually tells you which machine and directory you are on:

benson@m2a ~ %            # zsh on my laptop, home directory
[benson@stargate ~]$      # bash on Stargate, home directory
benson@beagle2:~$         # bash on a Beagle board, home directory

Reading the prompt is not optional. The single most common lab mistake is running a command on the wrong machine (e.g., generating keys while logged into Stargate instead of on your laptop). Always glance at the prompt first.

pwd                 # print working directory ("where am I?")
cd                  # go to my home directory (no argument)
cd /opt/riscv/bin   # go to an absolute path
cd project01        # go to a relative path (under the current dir)
cd ..               # go up one level
ls                  # list the current directory
ls -al              # long listing, including dotfiles like .ssh (shows permissions!)
mkdir cs315         # make a directory
cp src dst          # copy a file
mv old new          # move/rename a file
cat file            # dump a file to the screen
less file           # page through a large file (space = forward, b = back, q = quit)

Two shell facts that matter for this lab:

The ~ character expands to your home directory, so ~/.ssh/config means the config file inside the .ssh directory in your home.
Dotfiles (names starting with .) are hidden by a plain ls. The .ssh directory is hidden, so use ls -al to see it and inspect file permissions.

The PATH environment variable lists, in order, the directories the shell searches for commands:

[benson@stargate ~]$ echo $PATH
/home/benson/.local/bin:/usr/local/bin:/usr/bin:/opt/riscv/bin

You extend PATH in your ~/.bash_profile (bash) or ~/.zprofile (zsh). We use this later to put the autograder on the PATH. See the Shell Usage guide for more.

3. SSH and Public-Key Cryptography¶

SSH (Secure Shell) is the encrypted protocol you use to log into remote machines and run a shell there. SSH can authenticate you with a password, but we will use public-key authentication, which is both more secure and more convenient (no password typed on every connection).

Public-key cryptography uses a key pair:

Half of the pair	Where it lives	Shared?	Role
Private key (`id_ed25519_cs315_key`)	Your laptop only, in `~/.ssh`	NEVER share	Proves your identity; stays secret
Public key (`id_ed25519_cs315_key.pub`)	Copied to servers (`authorized_keys`)	Safe to share	Lets a server verify your private key

The intuition: the public key is like a padlock you can hand out freely; only the matching private key (which you keep) can open it. A server that has your public key in authorized_keys can challenge your laptop, and only your laptop, holding the private key, can answer correctly. No secret ever crosses the network.

sequenceDiagram
    participant L as Laptop (private key)
    participant S as Stargate (authorized_keys has public key)
    L->>S: I want to log in as benson
    S->>L: Challenge: prove you have the private key
    L->>L: Sign the challenge with private key
    L->>S: Here is my signature
    S->>S: Verify signature with stored public key
    S->>L: Verified - session granted (no password)

The private key on your laptop is itself protected by a passphrase. This matters: if your laptop is stolen, the thief still needs the passphrase to use the key. A long sentence of ordinary English words ("correct horse battery staple") is both stronger and easier to remember than a short string of symbols. The SSH agent remembers the passphrase after you type it once per session, which is why the second login of the day does not prompt you.

Important course note: Stargate has been configured to require SSH keys. Password-only logins may fail. Setting up keys is not optional polish, it is how you get in.

4. Step-by-Step: SSH Keys for Stargate¶

This is the heart of the lab. Do these steps on your laptop unless a step explicitly says ON STARGATE. Read your prompt before every command.

Off campus, connect to the USF VPN first. Then:

ssh <your_username>@stargate.cs.usfca.edu

Your default password is your 8-digit USF ID (CWID). If you changed it and forgot it, email support@cs.usfca.edu to request a reset (always confirm the current support contact on the course site). Once in, you will see an ASCII-art banner and a prompt like [benson@stargate ~]$. Then leave:

exit

Step 1: Generate the key pair (ON YOUR LAPTOP)¶

Make sure the prompt shows your laptop, not Stargate. Go to ~/.ssh and generate an Ed25519 key:

cd
cd .ssh
ssh-keygen -t ed25519 -C "<your_username>@dons.usfca.edu" -f id_ed25519_cs315_key

What the flags mean:

Flag	Meaning
`-t ed25519`	Key type: Ed25519, a modern, fast, secure elliptic-curve algorithm
`-C "..."`	A comment (your email) stored at the end of the public key, just a label
`-f id_ed25519_cs315_key`	The output filename (you choose this)

ssh-keygen asks for a passphrase twice. Enter a memorable sentence. The result is two files:

id_ed25519_cs315_key       <- PRIVATE key  (keep secret, never copy off the laptop)
id_ed25519_cs315_key.pub   <- PUBLIC key   (this is the one you distribute)

If ~/.ssh does not exist yet, create it first with mkdir -p ~/.ssh and chmod 700 ~/.ssh.

Step 2: Create the SSH config (ON YOUR LAPTOP)¶

Open ~/.ssh/config in an editor (micro config, nano config, or vim config) and add:

IgnoreUnknown UseKeychain
UseKeychain yes

Host stargate
  HostName stargate.cs.usfca.edu
  AddKeysToAgent yes
  ForwardAgent yes
  IdentityFile ~/.ssh/id_ed25519_cs315_key
  User <your_username>

Replace <your_username> with your USF/CS username. This config lets you type just ssh stargate instead of the full command. ForwardAgent yes is what later lets your GitHub key work after you hop onto a Beagle board.

The first two lines (IgnoreUnknown UseKeychain / UseKeychain yes) are macOS-specific niceties for the Keychain. On Linux/WSL they are harmless because IgnoreUnknown tells SSH to ignore options it does not recognize.

Step 3: Fix permissions (ON YOUR LAPTOP)¶

SSH refuses to use keys that other users could read. Lock down everything in ~/.ssh:

cd ~/.ssh
chmod 600 *

Step 4: Copy the public key to Stargate (ON YOUR LAPTOP)¶

scp id_ed25519_cs315_key.pub <your_username>@stargate.cs.usfca.edu:.ssh

scp is "secure copy" — same idea as cp, but the destination is user@host:path. Here :.ssh means the .ssh directory in your Stargate home. This still prompts for your password because key auth is not active yet.

Gotcha: if ~/.ssh does not yet exist on Stargate, the scp fails. Log in once (ssh stargate), run mkdir -p ~/.ssh && chmod 700 ~/.ssh, exit, and retry.

Step 5: Authorize the key (ON STARGATE)¶

ssh stargate                              # still prompts for password this time
cd .ssh
cat id_ed25519_cs315_key.pub >> authorized_keys
chmod 600 *
exit

The >> appends the public key to authorized_keys, creating the file if needed and preserving any existing keys. (Using > instead of >> would overwrite the file and wipe other keys — a classic mistake.) Any laptop holding the matching private key can now log in without a password.

Step 6: Test it (ON YOUR LAPTOP)¶

ssh stargate    # FIRST login: prompts for your KEY PASSPHRASE (not your account password)
exit
ssh stargate    # SECOND login: no prompt at all

The first connection asks for your passphrase and the agent caches it; the second is silent. That silent second login is your success signal.

flowchart TD
    A["ssh-keygen on laptop"] --> B["edit ~/.ssh/config"]
    B --> C["chmod 600 ~/.ssh/*"]
    C --> D["scp .pub to Stargate"]
    D --> E["ssh stargate (password)"]
    E --> F["cat .pub >> authorized_keys"]
    F --> G["chmod 600 *, exit"]
    G --> H["ssh stargate: passphrase once"]
    H --> I["ssh stargate again: silent = success"]

5. Reaching the Beagle Machines¶

There are two ways to get from your laptop to a Beagle board.

Method A: Two hops (works immediately)¶

From Stargate, just type:

ssh stargate
ssh beagle

ssh beagle lands you on one of beagle1...beagle5. Because your home directory is shared across Stargate and all the Beagle boards (network filesystem), your ~/.ssh setup — including authorized_keys — is already in place. No extra key copying is needed.

To make your GitHub key reach the Beagle board through Stargate, add this to ~/.ssh/config on Stargate:

Host *
    ForwardAgent yes

Method B: One hop with ProxyCommand (recommended)¶

It is tedious to type ssh stargate then ssh beagle every time. SSH can do both hops automatically using a ProxyCommand. Add this to ~/.ssh/config on your laptop:

Host beagle
  HostName beagle
  AddKeysToAgent yes
  ForwardAgent yes
  IdentityFile ~/.ssh/id_ed25519_cs315_key
  User <your_username>
  ProxyCommand ssh stargate -W %h:%p

Now a single command on your laptop connects straight through to a Beagle board:

ssh beagle

The ProxyCommand ssh stargate -W %h:%p line tells SSH: "to reach beagle, first open a connection to stargate and forward (-W) to the target host (%h) and port (%p)." It transparently does the two-hop dance for you.

flowchart LR
    A["ssh beagle<br/>(on laptop)"] --> B{"ProxyCommand"}
    B -->|"ssh stargate -W beagle:22"| C["Stargate"]
    C -->|"forward to"| D["beagle (one of 1-5)"]
    A -.->|"single command, no second login"| D

6. Editing Files Remotely with micro¶

On the Beagle boards you edit files in a terminal-based editor. Lab 01 requires a real editor — micro, vim, or emacs — not nano. We recommend micro because its shortcuts mirror what you already know from graphical editors. It is preinstalled on the Beagle boards and the RISC-V VMs.

micro hello.c       # open (or create) hello.c

Inside micro:

Keys	Action
`Ctrl-S`	Save
`Ctrl-Q`	Quit (prompts if unsaved)
`Shift-Arrow`	Select text
`Ctrl-C` / `Ctrl-X` / `Ctrl-V`	Copy / Cut / Paste
`Ctrl-F` then `Ctrl-N`	Find, then next match
`Ctrl-T`	New tab; `Ctrl-O` opens a file in it
`Tab` / `Shift-Tab`	Indent / unindent a selection

A useful one-time customization: use spaces instead of tab characters for indentation. Put this in ~/.config/micro/settings.json:

{
    "tabstospaces": true,
    "ft:c": { "tabsize": 4 },
    "softwrap": true
}

See the Micro guide for color schemes and keybinding tweaks.

7. GitHub over SSH¶

Your labs and projects live in GitHub repositories that you will clone onto the Beagle machines. Using SSH keys for GitHub means you never type a GitHub password.

On your laptop, add to ~/.ssh/config:

Host github.com
  AddKeysToAgent yes
  ForwardAgent yes
  IdentityFile ~/.ssh/id_ed25519_cs315_key
  User git

Then paste the contents of id_ed25519_cs315_key.pub into GitHub at github.com/settings/keys ("New SSH key"). Test it:

ssh -T git@github.com
# Hi <yourname>! You've successfully authenticated, but GitHub does not provide shell access.

That message means success (GitHub does not give you a shell, only Git access). Combined with ForwardAgent yes and the Host * agent forwarding on Stargate, the same key works when you git clone from a Beagle board.

A typical Lab 01 setup on a Beagle board, once keys work:

ssh beagle
mkdir -p cs315
cd cs315
git clone https://github.com/phpeterson-usf/autograder
# add the autograder to your PATH in ~/.bash_profile:
#   export PATH=~/cs315/autograder:$PATH

After editing ~/.bash_profile, log out and back in (or source ~/.bash_profile) so the new PATH takes effect. You can then run the Lab 01 autograder with grade test.

8. Optional: Local RISC-V VM with QEMU¶

A local RISC-V VM is a convenient fallback. QEMU emulates a RISC-V machine on your laptop. Note: on Apple Silicon, emulating a different architecture is CPU-intensive (it is full emulation, not virtualization), so it can be slow.

Install QEMU:

# macOS (Homebrew)
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# add to ~/.zprofile:  export PATH=/opt/homebrew/bin:$PATH   (then open a new Terminal)
brew install qemu

# Ubuntu / WSL
sudo apt update && sudo apt upgrade
sudo apt install qemu qemu-system-misc

Download and run the course image:

mkdir cs315 && cd cs315
curl https://www.cs.usfca.edu/~benson/cs315/files/ubuntu-22.04-riscv.zip --output ubuntu-22.04-riscv.zip
unzip ubuntu-22.04-riscv.zip
cd ubuntu-22.04-riscv
./start.sh

Log in as user ubuntu, password goldengate. The VM forwards host port 4444 to its SSH port, so from a second terminal:

ssh -p 4444 ubuntu@localhost

You can reuse the same key workflow from Section 4 to get passwordless access (create ~/.ssh in the VM, scp -P 4444 your .pub in, append to authorized_keys), then add a riscv host to your config:

Host riscv
  HostName 127.0.0.1
  Port 4444
  AddKeysToAgent yes
  ForwardAgent yes
  IdentityFile ~/.ssh/id_ed25519_cs315_key
  User <your_username>

Always shut the VM down cleanly:

sudo poweroff

9. Sanity Check: Compile and Run C on RISC-V¶

Once you can reach a Beagle board, confirm the full toolchain works. This mirrors the Lab 01 hello program.

/* hello.c - prints a greeting for its single argument */
#include <stdio.h>

int main(int argc, char *argv[]) {
    if (argc != 2) {
        fprintf(stderr, "Usage: %s <str>\n", argv[0]);
        return 1;
    }
    printf("Hello, %s!\n", argv[1]);
    return 0;
}

Build and run it on the Beagle board (real RISC-V hardware):

gcc -g -O2 -Wall -Wextra -o hello hello.c
./hello World
# Hello, World!

Confirm you are really on RISC-V:

uname -m        # riscv64
file hello      # hello: ELF 64-bit LSB ... RISC-V ...

Seeing riscv64 and a RISC-V ELF binary proves the entire pipeline — SSH, editor, compiler — is working on real hardware. That is the Lab 01 dev-setup deliverable in a nutshell.

10. Common Mistakes and How to Fix Them¶

Symptom	Likely cause	Fix
`Permissions 0644 ... are too open`	Key files world/group readable	`cd ~/.ssh && chmod 600 *`
Still prompted for password on every login	Public key not in `authorized_keys`, or you edited the wrong machine's file	Re-check Section 4 Step 5 on Stargate; verify with `cat ~/.ssh/authorized_keys`
`scp` to `.ssh` fails with "No such file or directory"	`~/.ssh` does not exist on the remote	`ssh` in, `mkdir -p ~/.ssh && chmod 700 ~/.ssh`, retry
Connection times out from off campus	Not on the USF VPN	Connect to the USF VPN, then retry
`authorized_keys` lost your other keys	Used `>` instead of `>>`	Re-append all needed public keys with `>>`
Commands "do nothing" or hit the wrong host	Ran them on the wrong machine	Read the prompt; `exit` until you are back on your laptop
GitHub `git clone` over SSH asks for a password on Beagle	Agent not forwarded	Add `Host *` / `ForwardAgent yes` to `~/.ssh/config` on Stargate
`Permission denied (publickey)`	Wrong `IdentityFile` or `User` in config	Double-check the path and username in `~/.ssh/config`

A quick diagnostic when login fails is verbose mode, which prints exactly which key SSH offers and why a host rejects it:

ssh -v stargate

Key Concepts¶

Concept	Definition	Example
SSH	Encrypted protocol for remote login and command execution	`ssh stargate`
Key pair	A matched private/public key used for authentication	`id_ed25519_cs315_key` and `.pub`
Private key	Secret half kept only on your laptop	`~/.ssh/id_ed25519_cs315_key`
Public key	Shareable half placed on servers	appended to `~/.ssh/authorized_keys`
Passphrase	Secret that unlocks the private key locally	a memorable English sentence
authorized_keys	File of public keys allowed to log into an account	`cat key.pub >> authorized_keys`
Stargate	CS Department public gateway to internal machines	`stargate.cs.usfca.edu`
BeagleV / Beagle	Real RISC-V hardware boards, `beagle1`–`beagle5`	`ssh beagle`
ProxyCommand	Config directive that hops through an intermediate host	`ssh stargate -W %h:%p`
Agent forwarding	Lets your local key be used on an intermediate host	`ForwardAgent yes`
QEMU	Emulator that runs a RISC-V VM on your laptop	`./start.sh`, `ssh -p 4444`

Practice Problems¶

Problem 1: Which machine, which key?¶

You are following the lab and the prompt reads [benson@stargate ~]$. You are about to run ssh-keygen -t ed25519 .... Is this correct? What goes wrong, and where should you actually generate the key?

Click to reveal solution

This is **wrong**. The prompt shows you are logged into **Stargate**, but the key pair must be generated **on your laptop**, where the private key will permanently live. Generating it on Stargate would place the private key on a shared server (insecure and pointless). Fix: type `exit` to return to your laptop, confirm the prompt shows your laptop's name, then `cd ~/.ssh` and run `ssh-keygen`. The whole model is: **private key on the laptop, public key copied out to servers.**

Problem 2: `>` vs `>>`¶

On Stargate you run:

cat id_ed25519_cs315_key.pub > authorized_keys

A teammate who already shared a key with this account now cannot log in. What happened, and how do you avoid it?

Click to reveal solution

`>` **truncates and overwrites** the file, so it replaced the entire `authorized_keys` with just your one key, deleting any keys that were there before (including your teammate's, or your own from another laptop). Always **append** with `>>`, which adds to the end and preserves existing entries:

cat id_ed25519_cs315_key.pub >> authorized_keys

`authorized_keys` is meant to hold many keys, one per line — every machine you want to log in from contributes one public key.

Problem 3: Permissions error¶

You try ssh stargate and get:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/id_ed25519_cs315_key' are too open.

Why does SSH refuse the key, and what command fixes it?

Click to reveal solution

Mode `0644` means the file is **readable by group and others**. A private key that other users on the system can read is a security hole, so SSH refuses to use it entirely (it does not just warn). Fix the permissions so only the owner can read/write:

cd ~/.ssh
chmod 600 id_ed25519_cs315_key      # or: chmod 600 *

The digits mean: `6` = read(4)+write(2) for the owner, `0` = nothing for group, `0` = nothing for others. The `.ssh` directory itself should be `700`.

Problem 4: Decode the SSH config¶

Explain, line by line, what this entry lets you do and what the single resulting command is equivalent to:

Host beagle
  HostName beagle
  IdentityFile ~/.ssh/id_ed25519_cs315_key
  User benson
  ProxyCommand ssh stargate -W %h:%p

Click to reveal solution

- `Host beagle` — defines an alias; typing `ssh beagle` triggers this block. - `HostName beagle` — the actual hostname to connect to (resolved on the Stargate side, where `beagle` is a valid name). - `IdentityFile ...` — use this private key for authentication. - `User benson` — log in as `benson`. - `ProxyCommand ssh stargate -W %h:%p` — instead of connecting directly (impossible from off-network), first SSH to `stargate` and forward (`-W`) the connection to the target host `%h` (beagle) on port `%p` (22). Net effect: a single `ssh beagle` on your laptop transparently hops through Stargate to a Beagle board, with no second login and no password. Without this config you would have to type `ssh stargate` then `ssh beagle` manually.

Problem 5: Passphrase vs password¶

The first time you ssh stargate after setting up keys, it asks for a passphrase; the second time it is silent. But your account password is never requested again. What is the difference between the passphrase and the password, and why does the second login skip the prompt?

Click to reveal solution

- The **account password** (your CWID by default) authenticates you to Stargate's *operating system*. With key auth working, SSH proves your identity with the key instead, so the password is no longer needed. - The **key passphrase** is a *local* secret that decrypts your private key on your laptop. The server never sees it. The second login is silent because the **SSH agent** caches the decrypted key in memory after the first use (enabled by `AddKeysToAgent yes`). Subsequent connections in the same session reuse the cached key, so neither passphrase nor password is requested.

Problem 6: GitHub on the Beagle board¶

You configured GitHub SSH on your laptop and ssh -T git@github.com works locally. But when you git clone git@github.com:USF-CS315-F25/lab01.git on a Beagle board, it asks for credentials. What is missing?

Click to reveal solution

The Beagle board does not have your GitHub private key, and that is intentional — you should not copy private keys to shared servers. Instead, use **SSH agent forwarding** so the Beagle board borrows the key from your laptop's agent for the duration of the session. Ensure both: 1. Your laptop config uses `ForwardAgent yes` for the `beagle`/`stargate` hosts. 2. Stargate's `~/.ssh/config` contains:

Host *
    ForwardAgent yes

so the agent connection is forwarded across the second hop to the Beagle board. After that, `git clone` over SSH on the Beagle board uses your forwarded key with no password.

Summary¶

CS 315 develops on RISC-V, primarily on the CS Department's five remote BeagleV-Ahead boards (beagle1–beagle5), with an optional local QEMU VM as a convenience.
The Beagle boards sit behind Stargate, the CS gateway. You reach them in two hops, laptop → Stargate → Beagle, and off campus you must be on the USF VPN.
SSH public-key authentication keeps the private key on your laptop and places the public key on servers; no secret crosses the network and no password is typed after setup.
The setup recipe is: generate a key on your laptop, write ~/.ssh/config, chmod 600 your keys, scp the public key to Stargate, and append it to authorized_keys. The silent second ssh stargate confirms success.
A ProxyCommand config turns the two-hop dance into a single ssh beagle, and agent forwarding lets your GitHub key work after the hop.
Read the prompt before every command — running steps on the wrong machine or in the wrong directory, using > instead of >>, and loose file permissions are the most common failures.
Edit remotely with micro (not nano) and verify the toolchain by compiling a small C program on a Beagle board, confirming uname -m reports riscv64.
Configure GitHub over SSH so repositories clone without a password on both your laptop and the Beagle boards — the foundation for every lab and project this semester.

Development Environment and Course Setup¶

Overview¶

Learning Objectives¶

Prerequisites¶

1. The CS 315 Development Topology¶

2. Command Line Refresher¶

3. SSH and Public-Key Cryptography¶

4. Step-by-Step: SSH Keys for Stargate¶

Step 0: First login with a password (to confirm your account)¶

Step 1: Generate the key pair (ON YOUR LAPTOP)¶

Step 2: Create the SSH config (ON YOUR LAPTOP)¶

Step 3: Fix permissions (ON YOUR LAPTOP)¶

Step 4: Copy the public key to Stargate (ON YOUR LAPTOP)¶

Step 5: Authorize the key (ON STARGATE)¶

Step 6: Test it (ON YOUR LAPTOP)¶

5. Reaching the Beagle Machines¶

Method A: Two hops (works immediately)¶

Method B: One hop with ProxyCommand (recommended)¶

6. Editing Files Remotely with micro¶

7. GitHub over SSH¶

8. Optional: Local RISC-V VM with QEMU¶

9. Sanity Check: Compile and Run C on RISC-V¶

10. Common Mistakes and How to Fix Them¶

Key Concepts¶

Practice Problems¶

Problem 1: Which machine, which key?¶

Problem 2: > vs >>¶

Problem 3: Permissions error¶

Problem 4: Decode the SSH config¶

Problem 5: Passphrase vs password¶

Problem 6: GitHub on the Beagle board¶

Further Reading¶

Summary¶

Problem 2: `>` vs `>>`¶