Set up only the environment one course requires. Record the supported Linux distribution, exact tools and versions, repository host, authentication method, project location, and verification command. Then install through the distribution’s supported package path and prove the environment with a disposable practice project.
Do not install every language, copy a classmate’s dotfiles, or create an SSH key before checking whether the course uses SSH at all.
Write the requirement sheet
Ask the syllabus, instructor, or official course environment:
Course and term:
Supported distribution and release:
Required Git version or minimum:
Repository host and protocol: HTTPS | SSH | other
Required language, compiler, runtime, and version:
Package or environment manager:
Editor and required extensions:
Project filesystem location:
Build, test, or run command:
Institution policy or managed-device limits:
Mark unknown items and stop. A generic “latest version” can conflict with grading. If the course provides a container, virtual machine, dev container, or remote laboratory, use its boundary instead of recreating it on the host.
Install from the distribution path
Use the package workflow from the previous article. On Ubuntu or Debian, Git and OpenSSH client package names are commonly installed through APT. On Fedora and RHEL-family systems, use the documented DNF package names. Other distributions have their own names and package managers.
Inspect exact packages and versions before installation. Do not add an unofficial repository or language-version manager simply because a tutorial uses it. When a course requires a version absent from the distribution, follow the course’s supported method and keep it scoped to that environment.
Verify:
git --version
ssh -V
ssh -V commonly writes version information to standard error. Capture the
observed output rather than assuming no standard output means failure.
Configure Git identity at the right scope
Git’s user.name and user.email become author and committer fields in commits;
they are not login credentials. The official
git-config reference documents system,
global, and repository-local configuration.
Inspect origins without displaying credential values:
git config list --show-origin
git config get user.name
git config get user.email
If personal and institutional work need different identities, prefer a repository-local setting:
git config set --local user.name "Course Name"
git config set --local user.email "approved-address@example.edu"
Use the actual name and email policy approved for the repository. Do not copy the example address. Verify:
git config get --show-origin user.name
git config get --show-origin user.email
Avoid publishing an address unintentionally. Some hosting services provide a privacy address; institutional repositories may require the school address.
Choose HTTPS or SSH deliberately
Use the protocol the course supports. HTTPS can use a platform-approved
credential helper or interactive sign-in. Do not configure Git’s plaintext
store helper for a token: the official
Git credential documentation
states that this helper writes credentials unencrypted to a file.
For SSH, inspect first:
ls -la "$HOME/.ssh"
ssh-add -l
The second command may report that no agent or identities are available. Do not
display or copy private-key contents. Files ending in .pub are public-key
files by convention, but verify the path and purpose before sharing.
If no appropriate key exists and the host’s official guide calls for one, use the key type and command it currently recommends. GitHub’s current Linux SSH setup guide walks through inspecting existing keys, generating a key, adding its public half, and testing access. A campus GitLab or other host has its own hostname, key policy, and verification instructions.
Protect a new private key with an appropriate passphrase and approved agent or credential mechanism. Never:
- upload the private-key file;
- paste it into a ticket, chat, repository, or AI prompt;
- reuse an instructor or classmate’s key;
- copy a host key from an unauthenticated search result; or
- disable host-key checking.
Verify the host before accepting it
The first SSH connection can present a host-key fingerprint. Stop and compare it with the repository host’s official, independently accessed documentation. GitHub’s SSH connection test explicitly requires fingerprint comparison.
Use the host-specific test command only after verification. A service can authenticate successfully while returning a nonzero status because it does not offer interactive shell access. Interpret the status using that host’s documentation.
Build one disposable practice project
Use an instructor-provided practice repository or a repository you are authorized to clone. Do not test against a graded submission containing uncommitted work.
mkdir -p "$HOME/course-practice"
cd "$HOME/course-practice"
git clone HOST-SPECIFIC-URL practice-project
cd practice-project
git remote -v
git status
Replace the placeholder with the approved URL. Inspect git remote -v for
unexpected usernames, tokens, or hosts before sharing output.
Then follow the repository README for its exact dependency and verification steps. Keep language environments project-local when the course supports that model. For example, Python virtual environments, Node project dependencies, and Java build tools have different lockfiles and isolation behavior; no one command applies to all.
Run the course’s harmless build, test, or “hello” workflow. Verify command paths and versions inside the same shell and environment used for the project.
Record the bounded environment
## Course toolchain verification
- Distribution and release:
- Git path and version:
- Git identity scope and origin:
- Repository host and protocol:
- SSH or HTTPS method verified:
- Runtime/compiler path and version:
- Project dependency method:
- Practice repository and commit:
- Build/test command and result:
- Secrets excluded: yes
- Unresolved course requirement:
Common mistakes
- Installing tools before reading course requirements.
- Setting one global Git identity for unrelated personal and institutional work.
- Treating Git identity as authentication.
- Generating duplicate SSH keys without inspecting existing ones.
- Accepting a host key without an independent fingerprint.
- Storing tokens in a remote URL, shell history, or plaintext helper.
- Running dependency installation as
root. - Testing only
--versioninstead of the course workflow.
Do this now
Complete the requirement sheet for one course. Configure Git identity at the narrowest useful scope, set up only the approved repository protocol, clone a disposable practice project, and run its documented verification. Stop on any unknown host fingerprint, secret-handling question, or unsupported version.
Log what you learned
The course requirement sheet and verified practice-project result are the learning log. Save the approved protocol, version evidence, stop condition, and next action there without recording private keys.
Next, preserve this bounded environment in a reproducible Ubuntu setup repository.