connections

Connections

Pre-alpha. The connection manager with its connection test, the vault, login scripts, the host-key and certificate dialogs, SSH servers in a panel (SFTP), SSH terminals and commands run on a server, FTP and FTPS servers in a panel, copying to and from servers and resuming a broken transfer are in the current build.

rCommander has a small connection manager for SSH (and FTP) servers — not a remote desktop manager: there is no RDP or VNC.

The connection manager

Ctrl+F or Net > Connections... in the menu bar opens the connection manager: the tree of folders and connections on the left, the selected connection's form on the right. It opens with the keyboard in the tree, on the connection you used last (the one you last connected to, or the row you left the manager on), so the arrows and Enter choose at once; a folder that holds it opens. Typing a letter there puts it into Filter by name or host, which filters as you type; the arrows and Page Up/Down still move in the tree, Enter connects. Settings page Keyboard, The connection manager opens in its list, on the connection used last, off: the manager opens in the filter. Tab and Shift+Tab go round everything in the manager - the filter, the tree, the buttons under it, each field of the form and the buttons - and the keys work where the frame is. Escape closes the manager from anywhere in it.

The manager is a window of its own: move it, resize it, leave it open and work on in the main window beside it - the main window's keys go to the panels while the manager does not have the keyboard. It opens where you left it; Ctrl+F brings it to the front, its X closes it as Escape does. Run command opens over it, in its window; the login-script editor opens in a window of its own beside it. Settings page Appearance, Large dialogs in windows of their own, switches this off: the manager then opens over the main window.

The tree (for example Customers / Acme / web-01): folders nest up to 32 levels, names are unique within a folder. A folder lists its folders, its connections, then its shared credentials (a diamond, the user beside the name).

Key	Action
Arrows, Enter	Move; Enter opens or closes a folder, and shows a connection in the active panel
Shift+Enter	Terminal on the SSH server at the cursor, in the active panel
Ctrl+Enter	Connect to the SSH server at the cursor; the manager stays open
Insert	New connection (a shared credential: the New credential button)
Shift+F5	Duplicate the connection: a copy named web (2) right under it, with its password, key and passphrase; its name is open to change
F7	New folder
F2	Rename
F8, Del	Delete, after a question; a folder goes with everything in it and their stored secrets
Space	Show the connection in the drive bar, or no longer
Ctrl+X, Ctrl+V	Move: cut, choose a folder, paste; dragging with the mouse works too
A letter	Into the filter, which then has the keyboard
Tab	On to the buttons under the tree, then the form
Alt+O, Alt+M, Alt+U	Open in panel, Terminal, Run command... of the SSH server whose form shows, from anywhere in the manager; holding Alt underlines these letters on every button

Enter, Shift+Enter and Ctrl+Enter work in the filter too, on the row the cursor is on.

Duplicate under the tree (or Shift+F5) copies the connection at the cursor: every field, its login script, the shared credential it uses and its own secrets, which are encrypted again for the copy. With the vault locked the master password is asked first. The copy is not marked for the drive bar (one at the top level shows there anyway) and keeps no session settings. An AI assistant cannot duplicate over MCP: the copy carries secrets.

Filter by name or host above the tree narrows it as you type. Each row is one line, the name and the host in columns; a value too long for its column is cut and shows whole as a tooltip, and a narrow tree shows the names alone. The manager fills the window but for a margin.

The form of a connection: Name, Protocol (SSH, FTP (unencrypted), FTPS (explicit TLS), FTPS (implicit TLS)), Host, Port, User, Log in with (Password, Private key, SSH agent or Pageant, Keyboard-interactive, Anonymous), Password, Private key file (Browse... opens Windows' file dialog in ~/.ssh; with Take the key file into the vault when saving), Key passphrase, Login script, Opens as (Files or Terminal), Start folder, Notes and Show in the drive bar. Save checks every field and shows a problem at the field; nothing is saved while one is wrong - a name, user or start folder with a line break or another control character included. A save is all or nothing: when a part is refused - a key file that cannot be read, a wrong passphrase, a locked vault - the connection stays as it was, and the reason shows at its field. The fields offered follow the protocol: FTP logs in by password or anonymously, and opens as files only. Credential takes the user and secrets from a shared credential instead.

Test connection in the form tests the connection without keeping a session, for SSH and FTP alike: connect, check the host key, log in, disconnect; it shows the login method and the time it took, or why it failed. An SSH connection's form also shows its session - No session open., Connecting... or Connected, 2 channels open. - with Connect or Disconnect.

Opening a server

An SSH server opens in a panel over SFTP, an FTP or FTPS server over FTP, in its Start folder or else its home folder (on FTP where the login starts), and the panel then works as on a local drive (see Panels).

• From the connection manager: Enter (or a double click) on an SSH connection, or Open in panel under its form, shows it in the active panel and closes the manager. Terminal (Shift+Enter in the tree) starts a shell on the server in the active panel (see Terminal), Connect (Ctrl+Enter) opens its session and leaves the manager open, and Run command... opens the dialog of one command; these are for SSH servers.
• From the drive bar: a click on a server shows it in that panel. The bar shows each server marked Show in the drive bar (Space in the tree) as a button of its own; by default those are the connections at the top of the tree. Every folder at the top of the tree is one button too: it opens the drive menu at its servers, marked or not, and in the menu each server stands under its folder path. Alt+F1 and Alt+F2 list every server.
• Typed: the path bar's Go to: field takes sftp://<connection name>/<path> and ftp://<connection name>/<path> (also ftps://).
• Back where you were: opening a server again returns to the folder the panel last showed there.
• Large folders show their first entries while the rest is still arriving; the Owner column (Settings, Appearance) shows who owns each entry (see Panels).

Ctrl+Shift+F in the file list closes the active panel's server connection. Every panel that showed that server goes back to a local folder: the last one in its tab's history, otherwise the other panel's folder, otherwise your home folder. The next step on the server logs in again.

Quick connection

Ctrl+N connects to an SSH server that is not in the tree, as Total Commander's New connection does: Host, Port (22), User, and a Password or a Private key file with its Key passphrase; Connect shows the server's home folder in the active panel. Unlike Total Commander the dialog has fields, not one URL line. Esc closes it.

• Not saved (the default), the connection lives only in memory until you close rCommander or disconnect it with Ctrl+Shift+F; its password is never written to the database or a log, and no master password is asked. It appears in the drive bar while it is open.
• Save as connection with a Name puts it into the tree, its password or passphrase into the vault - only then is the master password asked (or set, the first time: then you type it twice).
• The host key is checked as for every SSH connection.
• An assistant cannot reach a quick connection: over MCP it does not exist.

Running a command

Run command... in the connection manager, or a command typed into the command line while the active panel shows an SSH server, opens Run a command on . Run sends the command to the server, where your login shell runs it without a terminal, and shows its Output, its Errors and its Exit code (or the signal that ended it). The command is stopped after 60 seconds, and at most 1 MiB of output and of errors is kept ((cut off at the limit)). Cancel stops a running command; Esc closes the dialog.

Nothing can answer a prompt there, so a sudo that asks for a password does not work - use the SSH terminal with a login script for that. On the command line, cd still moves the panel instead of running anything.

An assistant runs a command with ssh_exec; you confirm each call in the window, with the connection and the full command shown. See MCP server.

Passwords, keys and the master password

A connection can keep its password, its private key and the key's passphrase, each encrypted in rCommander's database. You type them in the connection manager's form; a stored secret is never shown again (Stored - type to replace it), and Remove the stored password (key, passphrase) deletes it.

• No secrets, no master password. If you only use ssh-agent, Pageant or local files, rCommander never asks for one - not at start, not when you add a connection that uses an agent.
• The master password is set when you store the first secret (at least 8 characters). There is no recovery: without it the stored secrets are lost; connections and everything else stay.
• It is asked for only when a secret is about to be stored, or a connection needs one while the vault is locked (Unlock the vault), never at start-up. Cancelling the question cancels only that action.
• The vault locks itself after 15 minutes without your use - what an AI assistant does never counts as use - and after 8 hours unlocked at the latest, however busy it is. It also locks when Windows locks (Win+L) or goes to sleep. Settings, page Vault, changes all three.
• After it locks a password still on a terminal screen stays hidden from AI assistants.
• Two rCommander windows on one database: after one changes the master password, the other refuses to store a secret with the old one and asks you to unlock again, instead of losing it.
• Removing the last secret offers to remove the vault and its master password; then nothing asks again.
• Changing the master password re-encrypts every stored secret in one step and leaves no old encrypted value in the database file. Older backups keep the old password.
• How it is kept: the master password is never stored; a key is derived from it (Argon2id) and each secret is encrypted on its own (XChaCha20-Poly1305), bound to its row, so a value moved to another connection does not open. After three wrong passwords each try waits longer. A database from elsewhere cannot make unlocking hang or run out of memory: rCommander refuses key settings above 1 GiB of memory or 16 passes. An AI assistant can lock the vault, never unlock it.

Private keys live in the database, so that one backup holds your connections, passwords and keys together. Taking a key in reads its file once (OpenSSH, PEM, PKCS#8 or PuTTY .ppk version 2 or 3, at most 64 KiB), opens it with its passphrase to prove both are right, and stores it encrypted. The key's type, fingerprint and comment stay readable for display; the file itself is left where it was. A connection can also keep pointing to a key file by its path.

AI assistants never see a secret: no MCP tool takes, returns or unlocks one, and every answer is masked. See MCP server.

A secret from a password manager

With a secret-source plugin installed (a password manager such as Bitwarden, see plugins), a stored connection's password, private key or passphrase can come from the password manager instead of the vault. Under the form, Secret source shows one choice per secret the connection uses: Vault, or each source with its state (ready, locked, not answering, no licence, failed).

• Choose the source, type part of a title, user or address and press Search; click the entry. It is mapped at once - no Save needed. Choosing Vault again removes the mapping.
• Only the mapping is stored - which source and which entry, with its title and user to show. The secret itself is fetched from the password manager at every connect and never written to rCommander's database, its log or a backup.
• When the password manager cannot answer, connecting says why and names the source: locked (unlock it in the password manager - rCommander never asks for its master password), not answering (start its service), no licence, or the plugin failed. The connection stays editable.
• A source that is removed or switched off is named when you connect, not before; so is an entry that is no longer in the password manager - pick it again.
• Export and import carry the mapping, never the secret. An imported connection with mappings is not ticked by itself: tick it only if you trust the file, because its server would receive the password manager's secret.
• AI assistants can list the sources and search one (titles, users, addresses), never map a secret or read one; a connection with a mapping changes its server, port, kind or user only in the window.

A password from the Windows Credential Manager

On Windows, Secret source also offers the Windows Credential Manager, free and without a plugin. It lists the generic credentials (Control Panel > Credential Manager > Windows Credentials > Generic Credentials, or cmdkey /generic:<name> /user:<user> /pass): search by name, user or comment, click the entry. Its password is read at every connect, as above.

• rCommander only reads: create, change and delete the entries in Windows.
• Entries stored by Windows itself, cmdkey and Git Credential Manager are read correctly.
• Settings > Vault > Offer the Windows Credential Manager as a secret source switches it off; only you, in the window, can change it.

Shared credentials

When many servers share one account, keep its user and secrets once: New credential under the tree adds a shared credential to the folder at the cursor, shown with a diamond. Its form has Name, User, Password, Private key file (with Take the key file into the vault when saving) and Key passphrase; saving it asks for the master password as a connection does.

In a connection's form, Credential chooses Its own or a shared credential. With one chosen, the connection's own password, key and passphrase fields go away: it logs in with the credential's secrets, and as the credential's user unless its own User is filled in (FTP always names its own user). Change the password in the credential once, and every connection on it uses the new one at its next connect.

• F2 renames a credential, Ctrl+X and Ctrl+V or dragging moves it, F8 or Del deletes it after a question that says how many connections use it; they fall back to their own user and secrets.
• A new master password re-encrypts the credentials together with every other secret.
• Settings > Vault > Let connections use shared credentials switches them off: every connection uses its own user and secrets again, and the manager shows no credentials. Only you, in the window, can change it.
• An AI assistant can list, add, rename, move and delete credentials, but never sees or stores a secret of one, changes its user or points a connection at it - and the host of a connection on a credential stays yours to change.
• Not yet: the import from Remote Desktop Manager does not take RDM's credential entries, and a configuration export does not carry which credential a connection uses.

ssh-agent and Pageant

If your keys are already in an agent, rCommander uses them and stores nothing.

• Windows: the OpenSSH agent service (ssh-agent, started with Get-Service ssh-agent | Start-Service and filled with ssh-add) and Pageant. Both are asked, the OpenSSH agent first; a key held by both is listed once.
• Linux and macOS: the agent named by SSH_AUTH_SOCK.
• Listing the keys shows each key's type, comment, SHA256 fingerprint and which agent holds it - never the key itself - within a second; without a running agent the answer says so at once. An assistant reaches the list over MCP (ssh_agent_identities).
• At a login the connection's own key is offered first, then the agents' keys, at most Settings, page Terminal, Most agent keys offered per login (5, 1 to 20) - a server counts every key it is offered against its limit of tries.

Import from ~/.ssh/config

Your OpenSSH client configuration can be imported into the tree: Import ssh config... in the connection manager, or an assistant over MCP (connections_import_ssh_config).

• What is read: only your own ~/.ssh/config (on Windows %USERPROFILE%\.ssh\config) and the files under ~/.ssh/config.d/, or the same files of a WSL distribution. Include lines are followed, with wildcards, up to 8 levels deep and with a guard against loops.
• What becomes a connection: every literal Host name, with HostName, User, Port and the first IdentityFile as a key path (not the key itself). Several names on one Host line give one connection each. A host with an identity file uses key authentication, others the agent.
• What is skipped, with its reason: hosts with patterns (*, ?, !), Match blocks and defaults before the first Host. ProxyJump and further identity files are noted in the connection's notes as not used. Other options are listed by name only.
• Preview first: Read shows every host as New, Update, Already imported or Not imported (for example when the folder already has a connection of that name) before anything is written; you tick the hosts to import. Changing the path afterwards drops the preview, so Import always takes the file you saw (the same on the Total Commander and RDM pages).
• Where they go: a folder you choose (New connections go to), by default Imported from ssh config, created with the first new connection.
• Key files stay paths unless you tick Key into the vault for a host. Then, after the import, the key goes into the vault - the master password is asked at that moment, and only then. What became of each key is shown under its host: taken, or why not. An encrypted key shows a passphrase field under its host: type the passphrase and press Take key (or Enter); a wrong one is said there and you can try again. A key that cannot be taken does not stop the others. Only a key file on this computer or in a WSL distribution is taken; one on a network share (\\server\share\...) is refused, so a configuration cannot make rCommander open a share. An assistant over MCP never takes a key into the vault.
• Importing again updates the imported connections instead of duplicating them, even after you renamed or moved one; it changes only host, port, user and key path.
• Safety: a file that contains key material, or an include that points to a key file, stops the whole import. The report never repeats the text of your file beyond option names and line numbers.

Import from Total Commander

Settings → Import → Import from Total Commander... takes over what you set up in Total Commander (it moved there from the connection manager, because it brings more than connections): the directory hotlist, the folder tabs, the list colours and the list font from wincmd.ini, and the FTP, FTPS and SFTP connections from wcx_ftp.ini. An assistant can do it over MCP (import_total_commander), never with passwords.

• Where the files are found: wincmd.ini in %APPDATA%\GHISLER, else where Total Commander's registry entry says; wcx_ftp.ini where wincmd.ini names it or beside it. You can also type the path of either file or pick it with Browse.... They are read as UTF-16, UTF-8 or ANSI, at most 1 MiB each, and never changed. Of the %variables% in their paths only those Total Commander itself uses are filled in (%COMMANDER_PATH%, %APPDATA%, %USERPROFILE%, %ProgramFiles% and the like); any other one leaves its entry Not imported, so a file cannot pull other values from your environment.
• Preview first: Read lists the hotlist entries, the tabs of the left and right panel and the connections, each as New, Already there, Changed, Folder missing or Not imported with its reason. You tick what to import, then Import.
• Hotlist: entries that change folders, with their submenus as folders, go into a hotlist folder Imported from Total Commander. Entries that start programs, run Total Commander commands or point to servers or plugin folders are not imported.
• Tabs: added to the open tabs, or replacing them (Replace the open tabs); locked tabs stay locked. A tab whose folder no longer exists is imported only when you tick it.
• Connections go into the connection folder Imported from Total Commander, Total Commander's own folders below it (a | in a Total Commander connection name separates its folders, as Total Commander shows them); the protocol comes from the host's prefix (sftp://, ftps://, port 990 for implicit FTPS, else FTP).
• Passwords are taken only when you tick Take the passwords: then rCommander asks for your master password and puts them straight into the vault. A password that Total Commander protects with its own master password cannot be read; such a connection comes without one and asks you to enter it again. Total Commander's password scrambling is not encryption, so rCommander treats these passwords as secrets from the first byte: never shown, never logged.
• Colours and fonts: the colours of Total Commander's Configuration → Color go to the Colours tab - those of the normal look to rCommander's light look, those of Total Commander's dark mode to the dark look: text, background, second background, cursor, cursor text and marked names. A colour Total Commander leaves at its default, and its cursor when it follows the theme, stays as it is in rCommander. Its Define colors by file type rules are added after yours (a rule for the same mask is replaced where it stands); rules on a saved search filter are not imported, since rCommander colours by file mask only, and at most 64 rules fit. The file list font (Configuration → Display → Fonts, the setting for all resolutions) becomes the file lists' font; Total Commander's 10 points are rCommander's size 13. An inverted cursor or selection has no counterpart and is listed as not imported.
• Importing again adds nothing twice.

Keys, button bars and other settings of Total Commander are not imported.

Import from Remote Desktop Manager

Import RDM export... under the tree of the connection manager takes over the SSH connections you keep in Devolutions Remote Desktop Manager (RDM). An assistant can do it over MCP (import_remote_desktop_manager), never with passwords.

• What is read: an export you made in RDM with File → Export → Export vault (.rdm), without a master key - you pick it with Browse... or type its path. An export protected with a master key is encrypted as a whole and is refused with a message saying so; export again without one. The file is read as XML, at most 16 MiB, and never changed.
• What becomes a connection: SSH shells, PuTTY's SSH sessions, SFTP and SCP entries become SSH connections, with host, port, user and a key file path. A key path on a network share or with RDM's variables is not taken; the connection then asks for a password.
• What is not imported (yet): FTP and FTPS entries are listed as Not imported - not supported yet; they follow in a later version. RDP, VNC, web, database and every other kind of entry rCommander has no connection for are listed as Not imported with the reason; RDM's folder entries themselves are no row.
• Preview first: Read lists every entry as New, Update, Already imported or Not imported, with its folder, kind, host, user and port. You tick what to import, then Import.
• Where they go: into the folder Imported from Remote Desktop Manager, RDM's folders below it.
• Importing again, of the same file or a later export, adds nothing twice: entries are known by RDM's own ID, and only host, port, user and key path are updated.
• Passwords are not imported. RDM keeps them obfuscated with its own, undocumented scheme (SafePassword); rCommander does not decode it. The preview marks which entries have a password (Password not taken); enter it once in the connection and it goes into the vault. For the same reason an assistant cannot read an .rdm file over MCP; only the import reads it.

SSH connections

rCommander keeps one SSH session per connection and shares it between everything that uses the server; it sends a keepalive every 30 seconds, closes an idle session, and connects again on the next use after the line dropped: an SFTP panel and an SSH terminal on the same server share one TCP connection. In the connection manager Test connection tests it and Connect / Disconnect open and close its session; Ctrl+Shift+F in the file list closes the active panel's connection (for FTP also the session it keeps for its panels). An assistant connects, disconnects and tests over MCP (connections_connect, connections_disconnect, connections_test).

Logging in, in this order unless a connection sets another:

1. ssh-agent or Pageant - nothing is stored in rCommander.
2. Private key - stored in the vault (with its passphrase), or referenced by its file path.
3. Password - stored in the vault; Keyboard-interactive when the server only asks by prompt.

The server's host key is checked before any secret is read, and the log names the method that got in, never a secret. When a stored secret is needed and the vault is locked, the window asks for the master password; an assistant's call is refused with vault locked instead and never unlocks it.

When it fails, the answer says why:

Message	Meaning
The SSH server cannot be reached.	No connection to host and port: name, port, network or firewall
The SSH server did not answer in time.	Connecting, the handshake or the login took too long
The SSH server accepted none of the login methods tried.	Every method in the order was refused; check user, key, password or agent
This connection has no user name to log in as.	The form's User is empty
The vault is locked. Unlock it in rCommander.	A stored secret is needed and the vault is locked
This SSH server is not trusted yet. / ...presented a different host key...	See Host keys
The connection was lost.	The line dropped; the next use connects again
The SSH server offers no SFTP.	The server allows a login but no file access over SFTP
The SFTP server did not answer in time.	A listing or a file request took too long
The folder on the server holds more entries than a listing may show.	More than 500,000 entries

Host keys

rCommander keeps the SSH host keys you trusted with their SHA256 fingerprint, the way ssh-keygen -lf prints it, and tells an unknown key from a changed one.

• An unknown key opens Unknown SSH host key over the window: Server, Key type, Fingerprint and its randomart picture. Compare the fingerprint with the one the server's administrator gave you, then choose Connect once, Trust and save or Cancel.
• A changed key opens a red warning, WARNING: the server's host key has changed, with the Stored key and the Presented key. The connection is stopped; there is no "connect anyway". Only Replace stored key... and Cancel are offered, and replacing asks once more (Replace the key, Back). That is what a man-in-the-middle attack looks like - replace the key only if you know why it changed.
• The keyboard starts on Cancel (or Back), so Enter alone never trusts anything; Esc cancels. The status bar says what happened; connect again afterwards.
• An unknown key of another type for a server whose key you trusted (say an Ed25519 key where an RSA one is stored) is shown as unknown with a warning that other key types are stored; rCommander asks the server for the stored key types first.
• These are your decisions only: no assistant can trust, replace or forget a key. An assistant can list the stored keys; over MCP an unknown key is refused.

Managing trusted keys and certificates

Settings, page Host keys, lists every SSH host key and FTPS certificate you trusted in one table: Server, Port, Type (the key type, or FTPS certificate), Fingerprint (SHA-256) and Trusted since (UTC). A key imported from a hashed known_hosts shows as (hashed name) without a port.

• Search filters by server, key type or fingerprint as you type; a hashed name is found by the server it stands for.
• Remove (or Delete on the selected row; the arrow keys select) asks first; Enter removes, Esc keeps it. The next connection to that server asks again, as for a server never seen.
• Import known_hosts reads your own OpenSSH file (%USERPROFILE%\.ssh\known_hosts). The note under the page says how many keys were new, already trusted, changed and skipped. A key in the file that differs from the one you trusted is never taken over: the trusted key stays, and the note is shown as a warning.
• Nothing on this page trusts a key; a new key is trusted only in the question of the connection that meets it.

Login scripts

A login script types after an SSH login what you would type, step by step:

Step	What it does
Wait for	Waits for a pattern (a regular expression such as (?i)password.*:) in the output, with a time limit
Send text	Types a text, optionally followed by Enter
Send secret	Types the connection's password or a secret stored with the script, never shown
Send Enter	Presses Enter
Pause	Waits some milliseconds

Templates start the common cases: sudo -i with password, su - root and Second password after login. A Send secret step must come right after a Wait for its prompt, so a secret is never typed blind. A script has a time limit per step and for the whole run, and a Test run plays it against sample output you paste, without connecting. Each connection names the script it runs (Login script in the form). Secrets stored with a script are encrypted in the vault like the connection's own, and never appear in logs.

The editor opens with Login scripts... in the connection manager, in a window of its own beside it - the manager stays usable, and each closes on its own (Esc, Close or the window's X): New script or Start from a template on the left; on the right a Name, Wait per step and Whole script in milliseconds, then the Steps. They are numbered cards joined by a line and run from top to bottom, each with its kind, its fields, the arrows Move up and Move down and Remove; Press Enter after is a checkbox, and Add a step: adds one at the end. A Send secret step chooses its secret in a list: the connection's password or one stored with the script. Secrets stored with this script (Label, Value, Store, once the script is saved) keeps passwords other than the login's - sudo's or root's password goes here when the connection logs in with a key. A Send secret step says so while no secret is stored, and warns in red when the step before it does not wait for a password prompt: the secret could be typed into the shell and kept in its history (Settings > Terminal > Warn when a login script types a secret without a password prompt). A pattern that is not a valid regular expression shows at its field and is not saved. Test run plays the script against a sample you paste (Run against the sample) and says which step matched on which line, or where it stopped. Save (Enter), Close and, at the left, Delete are the button row at the bottom.

Example - a server you log in to with a key, then sudo -i: start from the template sudo -i with password, Save, store your sudo password under Secrets stored with this script (say with the label sudo), choose sudo in step 3's list, Save again, and pick the script under Login script in the connection. It runs when the connection opens as a terminal (Opens as), not in the file view.

In action: when an SSH terminal opens, the connection's script runs on the new shell before you can type: the status line shows Login script : step 2 of 4 - Ctrl+C stops it. and then ... done. A script that times out or fails says so in the terminal and the status line, and the shell is yours. Its secrets are read from the vault before anything is typed. With the vault locked, a script that sends the connection's password asks for the master password first; one that sends a secret stored with the script does not open (vault locked) - unlock the vault and open the terminal again. See Terminal.

An assistant can create and edit scripts over MCP too (login_scripts_*); a Send secret step, the steps before it, assigning a script that has one and storing a script's secret are refused there - they are yours alone, in the window.

FTP and FTPS

A connection can be FTP (unencrypted), FTPS with explicit TLS (AUTH TLS, port 21) or FTPS with implicit TLS (port 990). It logs in with a user and the password stored in the vault, or anonymously. Each FTP connection keeps its data mode (passive by default, or active) and the encoding of file names (Latin-1 by default, or UTF-8); an assistant sets them today. Active mode accepts exactly one data connection, from the server's address. Certificates are checked against the system's authorities first; for one they do not vouch for, you decide (below).

An FTP server opens in a panel as an SSH server does; a large folder fills in while it arrives. Links show at once, as links: rCommander asks the server what one points to only when you enter, open or copy it, and from then on a link to a folder shows as a folder. Look up FTP links when listing (Settings, page Transfers, off) asks for every link of a listing instead - up to 64, shown last once the listing is in - for connections made after the change. rCommander keeps one connection per server for listings and commands and up to two more for transfers; a third transfer waits. An idle connection is kept alive and closed after five minutes unused; Ctrl+Shift+F closes it at once. A connection the server dropped meanwhile is noticed before it is used again and replaced by a new login. A server that allows fewer sessions than that (for example two) is respected: the extra transfer waits for a free connection; only a server that takes no session at all shows an error saying so. An assistant reaches the same folders as ftp://<connection name>/<path>.

A server that refuses EPSV gets PASV and the other way round, and one that refuses LIST -a gets a plain LIST; rCommander remembers what worked for that server. When a server refuses a command, the message names it - for example that it refuses both passive modes and active mode is worth a try. The data connection always goes to the server's own address, whatever a PASV reply names. An unencrypted FTP session says in the status line that the password and the files cross the network in clear.

FTPS certificates

Many FTPS servers - NAS devices, routers, small hosters - sign their own certificate. rCommander never switches the check off; it asks you once, as for an SSH host key.

• An untrusted certificate (self-signed, from an unknown authority, or for another name) opens Untrusted FTPS certificate: Server, Fingerprint (SHA-256), Subject, Issuer, Valid from, Valid until and the reason it was refused. Compare the fingerprint with the one the server's administrator gave you, then choose Accept once (the next connection to that server only, within five minutes), Trust and save, or Cancel. Connect again afterwards. No password is sent before the certificate is accepted.
• A changed certificate - another one than you trusted, even a validly signed one - stops the connection with a warning, WARNING: the server's certificate has changed, and both fingerprints. Only Cancel is offered. If you know why it changed, remove the trusted one (below) and connect again.
• An expired trusted certificate warns too and can only be accepted once.
• The trusted certificate shows in the connection manager under an FTPS connection's form (Trusted certificate ..., since ...), with Forget to remove it; the next connection asks again. Settings, page Host keys, lists and removes them too (Managing trusted keys and certificates).
• These are your decisions only: an assistant can list the trusted certificates (certificates_list) but never accept, trust or forget one.

Transfers

• Local ↔ server with F5 and F6 between panels, in the background queue with progress; see server panels for the temporary .rcpart name and the size check before a move removes its source.
• Server ↔ server with F5 and F6 between two server panels: any pairing of SFTP and FTP, two servers or one. The data streams through rCommander - read and written at once, with no copy on your disk and constant memory; within one SFTP server it uses its one connection. If the target fails, the error says so (On the target:); a lost connection on either side resumes as below.
• At once: two transfers per server and four in all by default (settings page Transfers).
• Resume: when the connection breaks, the file is tried again after 5, 10 and 20 seconds on a new connection and continues where its .rcpart part ends - over SFTP and over FTP when the server supports REST (otherwise it starts over). It continues only while the source keeps its size and time and the end of the part matches; otherwise the file starts over. When the retries are used up the job pauses as Interrupted - resume or cancel in the queue; quitting rCommander keeps it, and after the next start a notice says how many interrupted transfers wait there. Cancel removes the part. A copy that finds a part an earlier copy left asks with Resume beside Overwrite. Settings page Transfers: Retries after a lost connection and First wait before a retry.