My first real terminal project - setting up Git and SSH as a complete beginner

I'm a student learning data analytics, working my way toward data engineering eventually. A few weeks ago, I started building out a proper Ubuntu setup for it — Python, Anaconda, Jupyter, the usual list you get told to install before you've written a single line of code. Git and GitHub were on that list too, and I figured it would be the easy part. Install it, connect it, move on to the actual data stuff.

Doing all this on Ubuntu

Quick note before I get into it: everything here happened on Ubuntu, using the built-in terminal. If you're on Windows or Mac, most of the concepts carry over, but some of the specific paths and package commands won't match exactly.

Wait, what exactly is Git?

Before touching any commands, I had to figure out what Git even was.

Think about writing a big assignment in Google Docs. You make changes, your lecturer or a classmate suggests edits, you accept some and reject others, and at any point you can look back at the version history and see exactly what the document looked like yesterday, or roll back to before you deleted that one paragraph you actually needed.

Git is that idea, but for code and data projects instead of documents, and it works even when nobody's connected to the internet at the moment they're making changes.

Every time you save a "checkpoint" of your work (called a commit), Git remembers exactly what changed, who changed it, and when. If you break something, you can go back to any earlier checkpoint. If two people are working on the same project, Git can combine both sets of changes instead of one person's work silently overwriting the other's.

GitHub, then, is just a website that hosts a copy of that project online, so you and your classmates (or your future employer) can see it, download it, and contribute to it from anywhere.

For someone studying to be a data analyst, this matters more than it might seem at first. Datasets and analysis scripts change constantly; you clean the data one way, then realize you need to redo it, then want to compare your old approach against the new one. Git is what makes that safe to do without ever losing earlier work. It's less "extra tool to learn" and more "safety net for every project you're about to start."

Why I even needed this

Part of my coursework involves pushing projects to GitHub, and I already had two accounts sitting around: an old one I'd made last year ago and barely touched — I think I used it for one small project for a couple of days and then forgot about it — and a newer one I set up specifically for my current data analyst studies, which is the one that actually matters to me now.

I didn't think having two accounts would be a problem. It became the entire problem. Let's talk about it, especially the mistakes I made while learning and implementing git at one sitting.

Mistake #1: one lowercase letter took down the whole command

The very first real command I typed was supposed to generate an SSH key:

ssh-keygen -t ed25519 -C "[e-mail]"

-t sets the type of key (Ed25519 is the modern default you're supposed to use), and -C attaches a comment — usually your email — so you can tell your keys apart later if you ever have more than one.

I typed -c instead of -C. As a total beginner, that felt like an insignificant difference. It is not. Ssh-keygen threw "Too many arguments" at me along with a wall of usage text that meant nothing to me at the time.

It turns out lowercase -c is an entirely different flag, used for editing the comment on a key that already exists, and it doesn't even work alongside -t. Nobody warns you that the terminal treats uppercase and lowercase letters as completely different instructions. I do now.

Mistake #2: GitHub told me my key was "already in use"

Once I actually generated a key correctly, I copied the public half and pasted it into GitHub's "New SSH key" page. GitHub's response: "Key is already in use."

I assumed I had broken something. I hadn't. What actually happened is that a key already existed at the default location from an earlier attempt, and when ssh-keygen asked if I wanted to overwrite it, I said no without understanding what that choice actually meant.

So it kept the old key instead of making a new one — and that old key was already sitting on my other, barely-used GitHub account from way back. I wasn't generating anything new; I was just re-pasting something that had already been claimed somewhere else.

The actual fix was giving the new key its own filename instead of relying on the default path:

ssh-keygen -t ed25519 -C "[e-mail]" -f ~/.ssh/id_ed25519_github

That -f flag turned out to matter a lot more than I expected. Without it, I kept colliding with whatever was already sitting at the default location.

Mistake #3: a space I couldn't even see

This one is embarrassing in hindsight. Trying to load my new key into the agent, I typed:

ssh-add ~/.ssh/id_ed 25519_github

There's a space between id_ed and 25519_github in there. I didn't notice it. The terminal doesn't interpret that as a typo — it reads it as two completely separate filenames, neither of which exists, and complains about both.

As someone brand new to typing commands instead of clicking buttons, I hadn't yet learned to read my own input carefully before hitting enter. I now use Tab to auto-complete filenames specifically so this can't happen again.

Mistake #4: copying the wrong file, three times in a row

I was using xclip to copy a key straight to my clipboard instead of manually highlighting text in the terminal:

xclip -sel clip < ~/.ssh/id_ed25519_github.pub

Except I ran this exact command pointed at the old key file, three separate times, without catching it — because the two filenames only differed by one word, and I genuinely couldn't tell them apart at a glance yet.

Every time I pasted into GitHub afterward, I was pasting the same already-claimed key from Mistake #2.

If you're new to this too: when something you think you already fixed keeps failing in the exact same way, don't assume your approach is wrong. Check whether you actually did the thing you meant to do.

The one that really got me: SSH was authenticating as the wrong account

With a key finally added successfully, I ran the standard connection test:

ssh -T [e-mail]

And it replied with something like: "Hi [my old, barely-used account]!" Not the account I actually wanted to use for my coursework.

This is the part that no beginner guide had prepared me for. ssh-agent holds onto every key you've loaded during your current terminal session, and when you connect to GitHub without telling it which one to use, it just offers them up one at a time until GitHub accepts one — whichever loads first wins, correct account or not. There's no warning. It just quietly logs you in as someone else. If I'd pushed a project right after that test, it would have gone up under the wrong identity with Git not batting an eye.

The real fix is a config file at ~/.ssh/config that tells SSH exactly which key belongs to which account:

# Old account
Host github.com-old
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

# Current studies account
Host github.com-studies
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github
    IdentitiesOnly yes

That IdentitiesOnly yes line isn't optional extra credit — without it, SSH goes right back to trying every key in the agent regardless of what you told it, which quietly undoes the entire point of setting this up. I left it out my first attempt and couldn't understand why nothing had changed.

With that saved, testing each identity separately actually worked the way I expected:

ssh -T [e-mail]-old
ssh -T [e-mail]-studies

Each one greeted me with the correct, matching username. First time that happened, I actually said "finally" out loud to an empty room.

Fixing the repo I'd already cloned

The config file only affects new connections going forward. A project I'd already cloned earlier was still pointed at a plain github.com URL with no account attached to it at all. I checked it with:

git remote -v

and pointed it at the correct alias:

git remote set-url origin [e-mail]-studies:username/repo-name.git

Same repo path, just swapping out the host for my new alias. Running git fetch afterward confirmed it actually worked end-to-end, not just in theory.

The thing that still trips me up

ssh-agent forgets everything the second I close the terminal or restart my laptop. The config file stays put, the keys stay on disk, but the agent itself resets constantly. So most sessions I still have to run:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_github

before doing anything else. I don't love it, but at least now I understand why it's asking again instead of assuming I broke something new.

What I'd tell another beginner starting this today

Read your own commands back before hitting enter, especially flag casing and filenames — your terminal will not guess what you meant. If an error repeats after you think you've fixed it, check whether you actually ran the fixed version, not just whether your reasoning was sound.

And if you're a student like me juggling more than one GitHub account for different parts of your life, set up the ~/.ssh/config file before you start pasting keys into GitHub, not after four rounds of confusion like I did.

None of this was actually complicated once I understood what was happening underneath it. It just wasn't explained anywhere I looked as a total beginner — so hopefully now, for someone else starting exactly where I did, it is.

Quick reference, if you're doing this right now

The commands I actually needed, in order, minus every detour above:

# 1. Generate a uniquely named key
ssh-keygen -t ed25519 -C "[e-mail]" -f ~/.ssh/id_ed25519_accountname

# 2. View it so you can paste it into GitHub
cat ~/.ssh/id_ed25519_accountname.pub

# 3. Load it into the agent (repeat after every reboot/new terminal)
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_accountname

# 4. Add a matching Host block to ~/.ssh/config, then test it
ssh -T [e-mail]-accountname

# 5. Point any existing repo at the right alias
git remote set-url origin [e-mail]-accountname:org-name/repo-name.git

If you only remember one thing from this: type slowly around flags and filenames, and set up your ~/.ssh/config aliases before you have two accounts competing for the same terminal session. Future you — probably mid-assignment, on a deadline — will thank you for it.

Go get Git!