Vai al contenuto

Questa pagina non è ancora nella sua lingua. Sta leggendo il testo in inglese.

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

Your browser never needs to know anything about SSH. 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 the profile launches like any other and nothing is downgraded behind your back.

The entry itself sits in the same library as every other address: you type it as one line and paste it 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

The profile takes a free local port when it opens and holds it until it closes. Launch a profile that is already open and it 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 inmacOS and LinuxWindows
Key file with no passwordWorksWorks
Key file with a passwordWorksDeclined with a reason
Server passwordWorksDeclined 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 you get a refusal instead, for a key with a passphrase of its own too, with a line that names what to use. 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 your password never goes into one. The ssh client asks for it its own way, and your answer reaches it through a channel in a folder only you can open.

Your password never reaches the disk at all, and it is gone the moment the tunnel stands.

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

Your personal ssh configuration is switched off while the tunnel runs. A jump host or a name rewrite living in it could send a profile somewhere you never chose, and you would never know.

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

    Your profile never reads it, so nothing written there can redirect it.

  • Your known hosts

    Never written to: the tunnel keeps a list of servers of its own instead.

  • Your other keys

    Never offered: name a key file and only that key is tried, name none and 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 never stays looking alive. The local entrance belongs to it and dies with it, so every request from that window is turned away.

How the tunnel comes back

The app then raises it again on the port your browser already knows: 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 you are told aloud at the third failure.

  1. 1

    Watched for you

    Every 15 seconds, so a dead connection is known in under a minute.

  2. 2

    Three tries in a row

    Three times on the same port, with a growing pause between tries.

  3. 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 check is done. A check that passes therefore means a launch will get that far too.

It also names the country your server comes out of, and from that country the profile takes its clock and its language list.

A tunnel that will not come up tells you 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: the exit is 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 check for an ordinary proxy takes the same road a launch takes
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 the app finds one that outlived a crash and closes it 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

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