Deze pagina is nog niet in uw taal. U leest de Engelse tekst.

Proxies

Your own server as the exit

A machine you already pay for becomes the exit of a profile, with no proxy bought at all. An ordinary ssh runs beside the browser, the password never reaches a command line, and a broken tunnel never becomes a direct connection.

SOCKS5 on loopback: What the browser is handed
Never: Password on the command line
20 seconds: Wait for the tunnel to come up
3: Retries on the same port

What runs next to the browser

The browser knows nothing about SSH and never needs to. An ordinary ssh with dynamic forwarding runs beside the profile and opens a real SOCKS5 entrance on loopback.

For the engine that is an ordinary local address, so no launch path becomes special and nothing is downgraded behind your back.

The entry itself sits in the same library as every other address, typed as one line and pasted in bulk with the rest.

What you type into the library: ssh://user@srv.example:22
What the engine is handed: socks5 on 127.0.0.1, port taken at launch

A free local port is taken when the profile opens and held until it closes. Launching a profile that is already open reuses the tunnel it has rather than pulling the port out from under a live window.

Two ways to sign in

A key file is the road that works on every system. You point at the file and ssh reads it: ARMANOS never opens your private key.

A server password works on macOS and Linux, and so does a key that carries a password of its own.

Way in	macOS and Linux	Windows
Key file with no password	Works	Works
Key file with a password	Works	Declined with a reason
Server password	Works	Declined with a reason

Why Windows takes a key and not a password

There is no way there to hand a password to ssh without putting it on disk or in a command line, so any password is declined, a key with a passphrase of its own included, with a line that names what to use instead. Windows also ships its ssh client switched off for some people, and the app asks about that the moment you pick this type, before you fill anything in.

Where the server password goes

Every process under your account can read a command line, so nothing secret is written into one. The ssh client asks for the password its own way, and the answer arrives through a nameless channel in a folder only you can open.

That channel never holds its content on disk, and it is removed the moment the tunnel stands, together with the small helper that read it.

The key file path stays on this computer

A path out of your home folder means nothing on a second machine, and sometimes points at somebody else's key. So it never travels to your account: a teammate who receives the shared entry points at a key of their own, and ARMANOS never reads the key itself.

Your own ssh setup is left alone

The tunnel runs with your personal configuration switched off. A jump host or a name rewrite living in it could send a profile somewhere you never chose, and do it silently.

Known servers are remembered in a file of the program's own, because the file you sign in to work with is not ours to edit.

Your configuration
Not read at all, so nothing written there can redirect a profile.
Your known hosts
Not written to. The tunnel keeps its own list of servers instead.
Your other keys
Not offered. With a key file only that key is tried, without one only the password.

A changed server key stops the launch

That happens after a reinstall, and a substitution looks exactly the same from here. You can agree to forget the old key from the same message, and only that one server is forgotten.

When the tunnel breaks

A broken tunnel is noticed rather than left looking alive. The local entrance belongs to it and dies with it, so every request from that window is turned away.

It is then raised again on the port the browser already knows, because a window that is already running would never learn a new one.

Endless retries would burn the connection limit at your own server and hide the trouble, so the third failure is spoken aloud instead.

1
It is probed
Every 15 seconds, so a dead connection is known in under a minute.
2
It is retried
Three times on the same port, with a growing pause between tries.
3
You are told
One line says the tunnel came back, another says it did not.

Checking it before a launch

The check button raises a real tunnel, measures through it and takes it down as soon as the answer arrives. A check that passes therefore means a launch will get that far too.

It also reads the country your server comes out of, and that country sets the profile clock and its language list.

A tunnel that will not come up names its own reason, from a login the server refused to a key that changed, rather than blaming the address.

This one is not checked from the web dashboard

A check from our side would have to speak proxy words to an ssh port, and the tunnel belongs on your machine, not ours. So a row like this is marked as checked in the app rather than failed.

What this does not do

It does not give you a server. ARMANOS neither sells, rents nor sets up machines, and this uses one you already reach.
It is not a residential address. The traffic leaves from a hosting network, and a platform reads it as exactly that.
It does not take a password on Windows, and a key carrying a password of its own is declined there too. A plain key file is the road that works.
It does not vouch for the first connection. A server key is trusted as given the first time and remembered, and only a later change stops a launch.

How to check

Each claim above is one place in the code and one stand.

A tunnel is raised against a real server, traffic passes, and a break heals on the same port: apps/desktop/src/lib/sshTunnel.js · apps/desktop/test/выход-по-ssh.js
No password reaches the arguments handed to ssh, and an encrypted key still signs in: apps/desktop/src/lib/sshTunnel.js · apps/desktop/test/выход-по-ssh.js
The answering helper and the channel live only while the tunnel comes up: apps/desktop/src/lib/secureFile.js · apps/desktop/test/secrets-on-disk.js
The check for an ordinary proxy takes the same road a launch takes; the SSH tunnel it raises separately: apps/desktop/src/main/main.js · apps/desktop/test/proxy-check-uses-bridge.js

Questions

Does my key file travel to my account?: No. Only a path could travel, and a path from this machine means nothing on another one. Sync, sign in and a shared entry all leave it alone: each computer points at its own key.
Can another program on this computer use the tunnel?: While the profile is open, yes: the local entrance takes no password. It is bound to loopback, so nothing off this machine reaches it, and it dies with the profile.
What if the app is closed while a profile is open?: Tunnels go down with it, on a window closing and on quit alike. On macOS and Linux one that outlived a crash is found by our own file name and killed at the next start.
Is this the same thing as a bought SOCKS5 address?: The same shape, a different machine. The far end is yours and not shared with strangers, though its address is a hosting one.

Make an exit of a server you already have

Install ARMANOS, add one SSH row to the library and open a profile behind it.

Download ARMANOS See what a launch actually does