We have all been there. A server goes down, you grab the nearest laptop, try to install PuTTY, and get instantly blocked by a Windows UAC prompt asking for an administrator password you do not have.
If you are stuck on a corporate workstation, a university lab computer, or a borrowed machine, you cannot run installers. You have to bypass the restrictions using portable software or native tools. Here are three ways I usually handle this.
The Portable PuTTY Executable
Everyone knows PuTTY. What many people forget is that the developers offer a standalone executable alongside the standard MSI installer.
You can grab putty.exe directly from their site and drop it into your Downloads folder or run it straight from a thumb drive. Windows usually lets portable executables run without throwing a permissions fit.
It works, but there is a major annoyance. PuTTY saves its configuration profiles and host key fingerprints directly into the Windows Registry. Strict IT departments often lock down registry writes for standard users. If you are on one of those machines, PuTTY will let you connect, but it will throw a nasty error when it tries to cache the host key. That means you have to manually re-accept the fingerprint every single time you connect.
The Hidden Windows OpenSSH Client
Before you download anything, check if Windows already has what you need. Windows 10 and 11 ship with a native OpenSSH client integrated into the command line.
Open PowerShell or Command Prompt and type:
ssh -V
If it spits out a version number, you are done. You can connect exactly like you would on a Linux box:
ssh root@your_ip_address
The catch is that OpenSSH is categorized as a Windows "Optional Feature." Some sysadmins intentionally strip it out of the base corporate image to reduce the attack surface. If typing ssh returns a "command not found" error, you are out of luck. Enabling Optional Features requires the exact admin rights you are missing.
The Browser-Based Escape Hatch
If they blocked portable executables and ripped out OpenSSH, your best bet is a web terminal.
This scenario is exactly why I built SSHDock. It runs entirely inside Chrome, Edge, or Firefox. You do not install a thing, and it completely ignores local OS privileges because the entire SSH protocol compiles down to WebAssembly and runs inside the browser sandbox.
As long as the network firewall allows outbound traffic on port 22, it will connect.
- Go to the SSHDock Terminal.
- Enter your IP and username.
- Paste your private key.
Your private key stays encrypted in your browser's IndexedDB storage. It never touches the Windows Registry, so it persists across sessions without triggering security alarms.
Beating Deep Packet Inspection
There is one last trap on corporate networks. Even if you get a client running, the firewall might just drop the traffic.
Many enterprise networks use Deep Packet Inspection (DPI). They do not just block port 22; they analyze the traffic shapes on port 80 and 443. If they see an SSH handshake pretending to be web traffic, they kill the connection instantly.
If you hit a DPI firewall, a portable client will not save you. You will need to route your SSH traffic over a pre-configured WebSocket or use an HTTPS tunneling service like Cloudflare Tunnels to mask the packets.
Assuming they are not doing deep packet inspection, stick to portable PuTTY or a web terminal. They are the fastest ways around a UAC prompt when the server is on fire.