DEV Community: Irene Githundi

Permission Denied? The SSH Agent is the Secret Sauce for GitHub 🔑

Irene Githundi — Fri, 30 Jan 2026 09:49:23 +0000

If you're just starting out in DevOps, you've probably hit that wall: you've generated your SSH keys, you've added the public one to GitHub, and yet...

git push origin main
# Error: Permission denied (publickey)

It's maddening, isn't it? You've done all the steps, but GitHub still won't let you in. I spent ages on this, so let me save you the headache.

The Key Pair is Only Half the Story

We all know the basics of SSH authentication:

•
The Public Key (.pub): This is the one you give to GitHub. It's like the lock on the door.

•
The Private Key: This stays on your machine. It's the actual key that opens the lock. Keep it safe!

I had both, and I had the right lock on the door. So what was the problem?

The Missing Link: The SSH Agent

Here's the bit that often gets left out of the beginner tutorials: your computer needs a way to use that private key automatically. That's where the SSH Agent comes in.

Think of the Agent as a secure, temporary vault for your private keys. When you try to push code, the Agent automatically presents the key to GitHub. If the Agent isn't running, or if you haven't loaded your key into it, your terminal has no idea how to prove your identity.

This was my "Aha!" moment. I hadn't told my system to load the key!

The Two-Line Fix That Changes Everything

If you've generated your key and added the public part to GitHub, this is likely the missing piece of the puzzle. Run these two commands in your terminal:

# 1. Start the SSH agent (if it's not already running)
eval "$(ssh-agent -s)"

# 2. Load your private key into the agent
ssh-add ~/.ssh/id_ed25519

Pro Tip: If you used a different name for your key, adjust the path in the ssh-add command.

Once you've done that, you can test the connection:

ssh -T git@github.com
# You should see: Hi [YourUsername]! You've successfully authenticated... 🎉

And just like that, your git push will work without a password.

Why This Matters for DevOps

This isn't just a convenience; it's a fundamental part of the DevOps workflow. Automated systems—like CI/CD pipelines or deployment scripts on a server—can't type passwords. SSH keys, managed by the Agent, provide the secure, non-interactive authentication that makes automation possible.

If you're hitting this error, you're not alone. It's a classic beginner hurdle. Now you know the secret sauce!

Understanding Git Origins and Upstreams

Irene Githundi — Fri, 30 Jan 2026 09:33:17 +0000

When you fork a repository on GitHub, you're making a copy. But here's what nobody tells you clearly: you now have TWO versions of the same project.

git remote -v

origin    git@github.com:IreneGithundi/project.git
upstream  git@github.com:pravinmishra88/project.git

Think of it like this:

upstream = The official project (the "source of truth")
origin = Your personal copy (your "sandbox")

Why Both?
Here's the scenario that made it clear after much struggle:

You fork a project on Monday
You spend Tuesday and Wednesday coding your feature
Meanwhile, 10 other developers push changes to the official project (upstream)
On Thursday, you try to contribute your code back

The problem: Your code is now outdated. You're working with Monday's version while everyone else is on Thursday's version.
The solution: Sync **with upstream **BEFORE you push.

# Get the latest from the official project
git fetch upstream

# Merge those updates into your branch
git merge upstream/main

# Now push to YOUR fork
git push origin my-feature-branch

What's Actually Happening Here?
Think of upstream as the company headquarters and origin as your local office branch:

Fetch upstream = "Hey headquarters, what's new?"
Merge = "Let me update my local office with headquarters' latest policies"
Push to origin = "Now I'll save MY work to MY office"
Pull Request = "Headquarters, I've made improvements. Want to add them to the official policy?"

The lightbulb moment: You never push directly to upstream. You push to origin (your fork), then create a Pull Request asking upstream to accept your changes. This protects the official project from breaking.

DevOps as a Career Food-Tech Startup (and Autonomous Racing)

Irene Githundi — Thu, 15 Jan 2026 08:31:29 +0000

Who knew DevOps could be used in food industries in Africa? Certainly not me when I started in 2025. But looking back from 2029, it's wild how things turned out. I'm now running SafeFood Systems, a company that helps food manufacturers across Kenya track quality and compliance automatically. And on weekends? I consult for university teams competing in the A2RL autonomous racing league. Here's how DevOps made all of this possible.

When I started the DevOps Micro-Internship (DMI) by Pravin Mishra in early 2026, I honestly just wanted to learn CI/CD and land a tech job. But something clicked while building my first monitoring dashboard. I realized the same principles we use to keep software running could solve real problems in industries I actually cared about.

By 2027, I started playing around with an idea: what if we monitored food processing the way we monitor servers? I wrote a few LinkedIn posts about it, mostly to organize my thoughts. A small dairy company in Nairobi saw one of my posts and reached out for help with their quality control nightmares. I built them a basic system using Docker and Jenkins to automate their quality checks. The results were immediate—they cut their failures by 30% in four months.

That proof of concept became SafeFood Systems in 2028. By 2029, we had scaled to 6 clients across East Africa and 2 in Southern Africa. The platform monitors temperature, humidity, and contamination risks in real-time, then automatically generates compliance reports. I finally got to combine my DevOps skills with something that genuinely matters to people's health.

The motorsport consulting started by accident. I've always loved watching Formula 1 and endurance racing series. When I discovered A2RL in 2026, I noticed something familiar: their systems worked perfectly in testing but failed under race pressure. I did my bootcamp project on this problem and documented everything publicly. One team noticed my work and asked for help building proper CI/CD pipelines for their autonomous racing code. That team placed second in the 2027 season.

The craziest part? I'm not the smartest engineer. I just stayed consistent, built things people could see, and stopped waiting for someone to hand me opportunities. DevOps wasn't the end goal; it was the tool that let me work on problems I actually care about.

This is part of DevOps Micro-Internship (DMI) by Pravin Mishra.

The Journey of a 2.0 Newbie

Irene Githundi — Thu, 21 Aug 2025 10:45:19 +0000

Learning a new skill is never easy; and programming has proven to be one of the hardest challenges I’ve faced.

I began my coding journey in 2024 when I joined ALX, knowing nothing but eager to write those magical lines of code that bring apps or games to life. But reality hit me very fast. We began with Shell basics, which were smooth, then moved to C language, which humbled me. Starting C, I thought: “If I can print Hello, World!, then I can do anything.” On came about functions, pointers and arrays which didn’t just confuse me but crush me to the pits. Instead of truly learning, I took shortcuts: copying code just to pass. Soon, I was drowning in recursion, data structures, and memory allocation without understanding the foundations. By June 2024, I knew I had to take a step back: I felt guilty, defeated, and convinced maybe programming wasn’t for me.

Still, the dream never left. After months of reflection, I realized the first thing I needed to fix wasn’t my code; it was my mindset.

Now, as I restart my journey, I come better prepared: mentally, emotionally, and practically. I know there will be long nights of debugging. I know errors will test my patience. But I also know this: quitting isn’t an option anymore.

This time, my path is clear: Progress >>> Perfection.