news
today's howtos and tmux drama
-
Fernando Borretti ☛ Using the Brother DS-640 Scanner on NixOS
The DS-640 is a compact USB scanner from Brother. It was surprisingly hard to get it working on NixOS, so I wrote up my solution so others don’t have this problem. The bad news is you need Brother’s proprietary drivers to make this work.
You need this configuration: [...]
-
Feld ☛ Tmux and SSH Agent Forwarding
You don't need custom tools, you just need a shell alias.
-
Blog System/5 ☛ ssh-agent broken in tmux? I've got you!
In that article, I presented the ssh-agent-switcher: a program I put together in a few hours to fix this problem. In short, ssh-agent-switcher exposes an agent socket at a stable location (/tmp/ssh-agent.${USER?} by default) and proxies all incoming credential requests to the transient socket that the sshd server creates on a connection basis.
In this article, I want to formalize this project by presenting its first actual release, 1.0.0, and explain what has changed to warrant this release number. I put effort into creating this formal release because ssh-agent-switcher has organically gained more interest than I imagined as it is solving a real problem that various people have.
-
[Old] Medium ☛ Why I Always Disable SSH Agent Forwarding on Linux (And How Attackers Steal Your Keys Through It)
Most admins enable SSH Agent Forwarding because it makes life easier — you can hop between servers without typing your key passphrase again. Convenient? Yes. Secure? Absolutely not. Agent forwarding is one of the most misunderstood and quietly dangerous features in the SSH ecosystem.
-
[Old] Medium ☛ The Hidden Risks of SSH Agent Forwarding (And How I Avoid Them)
SSH agent forwarding is one of those features Linux admins love because it makes life easier. You can hop from server to server without retyping passphrases, and your private keys never leave your laptop.
Sounds safe, right?
Not always. Over time, I’ve learned that careless use of SSH agent forwarding can actually expose you to silent, high-impact attacks. -
[Old] Carlo Contavalli ☛ The pitfalls of using ssh-agent, or how to use an agent safely
In a previous article we talked about how to use ssh keys and an ssh agent.
Unfortunately for you, we promised a follow up to talk about the security implications of using such an agent. So, here we are.
If you are the impatient kind of reader, here is a a few rules of thumb you should follow: [...]
-
[Old] Teleport ☛ 5 SSH Agent Best Practices
However, the more critical security risk is associated with SSH agent forwarding. When agent forwarding is used to jump between SSH servers, the local SSH agent is forwarded to the jump server. By design, agent forwarding lets you authenticate with the upstream server without copying private keys to the jump server. But it also means that any user with root access to the jump server can access the SSH agent and misuse it to authenticate with SSH servers on your behalf. So it is essential to follow a few best practices to harden usage of SSH agents and minimize the risk of them being compromised.
-
[Old] Graham Helton ☛ Zero Effort Private Key Compromise: Abusing SSH-Agent For Lateral Movement
To demonstrate why this could be really bad, lets assume that admin IS infact connecting to a server with the ssh -A root@<server> command. But first, why would anyone do this in the first place. Can’t we just make a policy to disallow our admins from using agent forwarding? Well, there are a few possible scenarios where this could be useful. 1. Jumphosts: In enterprise environments, accessing sensitive servers from your personal machine is not a great security policy. Instead, Jumphosts should be used. These special servers are (ideally) the only servers able to connect to sensitive machines via ssh. This segmentation can be implemented through firewalls. IE: ssh root@super_important_dns_server would not be possible from your local machine UNLESS your traffic is being proxied through a jumpserver. 2. You’re connected to a dev server that needs special access to something (IE: a git repository), but you don’t want to put your private key on the dev server.
These are two very simple scenarios, but you get the idea.
-
Make Use Of ☛ How to build a Linux home office server for creative work
I know, creative work is messy! Digital Post-its everywhere! Files multiply like gremlins! Versions drift. You save something as "final" then "final-final" then "FINAL_FOR_REAL_THIS_TIME!!!" We all know that's not the final. At some point, a cloud service helpfully syncs the wrong thing, and you'll spend the next twenty minutes whispering threats, hopefully not in binary, at a progress bar. A Linux home office server exists to stop this nonsense.
Not in a grand, enterprise way. No, no, in a quiet, practical, please-don't-break way. It sits there, holds your stuff, and backs things up. It doesn't ask for attention, subscriptions, or permission to reboot when you are mere seconds from missing a deadline. It just gets the job done.