DEV Community: 254 Stack

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

254 Stack — Sat, 29 Aug 2026 20:40:52 +0000

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 "your_email@example.com"

-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 "your_email@example.com" -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 git@github.com

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 git@github.com-old
ssh -T git@github.com-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 git@github.com-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 "your_email@example.com" -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 git@github.com-accountname

# 5. Point any existing repo at the right alias
git remote set-url origin git@github.com-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!

Programmable business email infra for teams and AI agents

254 Stack — Fri, 28 Aug 2026 09:14:29 +0000

We've been rethinking business email for a while. I'm Stefan, and Chibu and I are building Venmail.

The problem

Business email is needlessly expensive and fragmented. Per-seat pricing turns headcount into a tax. And even for teams fully on Gmail or Outlook, the tools that actually run the business around email — CRM, payments, prospecting, workflow automation — still live in a separate stack of subscriptions Google and Microsoft don't include.

We started from a simple premise: email is business infrastructure, but it's still sold like per-user SaaS. So we rebuilt the underlying model around identities, storage, permissions, and usage instead of headcount. Email as a hub, not a silo.

Storage, not seats

Venmail scales on storage, not headcount. Paid plans have no per-seat fees. Organizations can bring their own storage — S3, Azure Blob, or self-hosted — instead of storage we control on your behalf. A company with 10x the employees doesn't need 10x the infrastructure, so a five-person team and a fifty-person team on similar mail volume pay roughly the same.

For a human team, that's a compliance and portability story: your mail data lives on infrastructure you already govern.

Sending mail is a plain REST call:

curl -X POST https://m.venmail.io/api/v1/send/message \
  -H "X-Server-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": ["user@example.com"],
    "from": "hello@yourdomain.com",
    "subject": "Test email",
    "html_body": "<p>Hello from Venmail API!</p>"
  }'

Or with the Node/TypeScript SDK:

npm install @venmail/vsm

Then AI agents came along

We didn't start with AI agents. We started with the idea that email should be infrastructure. Once we had an API-native email layer, giving agents their own identities and scoped access followed naturally.

It's a bigger deal than it sounds. Machine and agent identities already outnumber human identities in the average enterprise by roughly 109 to 1 — up from 82 to 1 the year before — and agent-specific identities are projected to grow another 85% over the next twelve months (Palo Alto Networks, 2026 Identity Security Landscape). Most of those agents are still getting access the same bad way: a shared OAuth grant, or someone's personal app password.

An agent shouldn't need a human-style paid seat, and it shouldn't need to borrow a person's inbox. It should have its own identity, its own inbox, and permissions scoped to exactly what it does.

So we built an agent API: dedicated inboxes, scoped tokens for read/send/reply, independent rotation and revocation, a full audit trail, and MCP support so Claude Desktop or Claude Code can use it as a tool directly.

import { vvs } from '@venmail/vsm';

// Generate a keypair for the agent (once)
const keyPair = vvs.generateKeyPair();

VVS-1: knowing which agent actually sent a message

Email has no native way to verify that a message from billing@yourcompany.com was actually sent by your billing agent, and not spoofed or tampered with in transit. DKIM proves the domain sent it. It says nothing about which agent, script, or process behind that domain actually authored it.

That's what VVS-1 (Venmail Verification Standard) is for — Ed25519 signatures, standard SMTP headers, and existing DNS/HTTPS infrastructure. It doesn't touch SMTP itself; it layers on top of delivery, so a receiver that doesn't support it just gets the message normally.

Sender side: each agent gets an Ed25519 keypair, publishes its public key at /.well-known/venmail-agent/{name} or as a DNS TXT record, and signs the message body and headers before DKIM is applied.

import { vvs } from '@venmail/vsm';

const result = vvs.signMessage(
  'Hello, world!',
  { from: 'billing@yourco.com', to: 'user@example.com', subject: 'Invoice #1234', date: new Date().toUTCString() },
  { agentId: 'billing@yourco.com', privateKey: keyPair.privateKey, verifyMethods: ['well-known'] }
);

// result.headers = { 'X-Venmail-Agent': '...', 'X-Venmail-Signature': '...', ... }

Receiver side: extract the X-Venmail-* headers, resolve the sender's public key (well-known, DNS, or embedded), and verify:

import { vvs } from '@venmail/vsm';

const result = await vvs.verifyMessage(vvsHeaders, emailBody, emailHeaders);

console.log(result.trustLevel); // 'VERIFIED' | 'PARTIAL' | 'FAILED' | 'UNKNOWN'

Four trust levels, deliberately non-blocking:

Level	Meaning
`VERIFIED`	Signature valid, key resolved via `.well-known` or DNS
`PARTIAL`	Signature valid, key from embedded header only
`FAILED`	Headers present but verification failed
`UNKNOWN`	No VVS headers — a normal email

Nothing gets blocked at the SMTP layer. Trust levels are annotations, shown as a badge in the Venmail inbox, not gatekeepers that bounce mail.

This matters most for AI agents sending on your behalf, automated workflows where authenticity is load-bearing, financial communications that need to be tamper-evident, and agent-to-agent mail across organizations — cases where "the domain looked right" isn't actually good enough anymore.

Is this just Microsoft/Google/Nylas?

Microsoft's Entra Agent ID and Google's Gemini Enterprise both already ship agent identity, and Nylas already offers agent-owned mailboxes with MCP support. We're not claiming to have invented "give an agent an inbox."

What we think is different: Microsoft and Google bundle agent identity into their most expensive enterprise tiers, stack it on top of per-seat licensing, and build it for an IT team managing thousands of agents — not a small team wanting one scoped inbox via a single API call. Nylas is a sync layer over your existing Gmail or Outlook account; Venmail hosts the mailbox itself. And VVS-1's cross-organization verification — any mail server, not just Venmail, can check a signature — isn't something we've seen elsewhere yet.

Try it

It's live: venmail.io. Docs are at docs.venmail.io.

We'd especially like to hear from anyone who's built email infrastructure, run larger teams, self-hosted mail, or built AI agents — drop a comment.