The other day I was troubleshooting a simple Ansible connectivity issue and decided to peek under the hood. Using Border0's session recording feature I went down a bit of a rabbit hole. What I found was… a bit more chatty than expected.
Here’s what happens when you run just this:
You’d naively expect a single SSH connection, maybe one exec, and done… But in reality, here’s what Border0 recorded: 8 SSH sessions, multiple exec calls, and a full SFTP transfer ... just to run uptime.
🔍 What Happens Behind the Scenes
Border0's SSH session logs provide detailed visibility into every SSH event, the screenshot below shows the various sessions channels and types!
If you're wondering why Ansible sometimes feels slow, well… this is why! Lots to dig into.
Session 1 – Find Home Directory
Ansible needs to know where to drop temp files. In this case the output was /root. It will use that for the next few steps.
Session 2 – Create Temporary Working Dir
It prepares a temp directory for module execution.
Session 3 – Discover Python
It tries to figure out which versions of Python are available.
Session 4 – Confirm Python Works
Just making sure the interpreter doesn’t blow up.
Session 5 – Upload Module via SFTP
Ansible now uploads its payload (AnsiballZ_command.py) over SFTP. No command, just file transfer.
Session 6 – Make the Script Executable
Session 7 – Run the Payload
This is where the actual "uptime" gets run.
Border0 captures STDOUT, so we can see for each shell or exec, what happened. Here you'll recognize the familiar ansible output, notice that it comes straight from the server.
Session 8 – Cleanup
Deletes all the temporary files it just created.
🐢 And That’s Why It Feels Slow
Ansible isn’t just SSH-ing in and running a command. It’s:
• doing discovery
• uploading Python scripts
• setting permissions
• running temporary code
• cleaning up after itself
All good practices… but it adds a lot of overhead.
⚡️ Pro Tip: Use Raw Mode
If you just want to run a command like uptime, use raw mode:
Raw mode skips the module upload and just executes your command directly: one SSH session, one exec, done
🤔 So Why Was I Looking at This?
This all started while helping a customer run Ansible over Border0, using AWS SSM as the upstream protocol.
Turns out there's a catch: Ansible can work over SSM, but only in raw mode, where it just issues a single exec.
The default mode, with all its file uploads and session juggling, doesn’t work well with SSM. That’s because the SSM API isn’t a real interactive shell, you can’t stream input or output. You just send a command and get back a response later. Kind of limiting, honestly 😅
The good news? You can skip all that and just run Ansible directly over Border0, no SSM required.
For what seemed like a “simple” issue… this turned into a surprisingly deep dive. Reminded me a bit of this scene 👇
Sometimes it's just a lightbulb.
Other times, it's… a whole thing. 😄 Luckily, with the right tools everything can be fixed!
.png)
Ready to level up
your security?
