Import connections in bulk

Transit AI imports your existing SSH connections in bulk from five sources — a SecureCRT export, an MTPuTTY server list, a MobaXterm sessions or configuration export, an OpenSSH ssh_config, or a CSV file. It reads host, port, username, folder structure, and key-file paths, then walks you through mapping each login to a credential before anything is saved.

Transit never reads or decrypts your stored passwords. The SecureCRT password vault and config passphrase are ignored entirely, MTPuTTY’s encrypted password fields are never read, MobaXterm keeps its passwords in its own credential store (they aren’t in the exported session lines at all), and a CSV has no password column. Secrets are enrolled separately into your OS keychain during the import — they never live in the imported file.

Open the importer

Three equivalent ways:

Click the Import button (down-arrow) in the connections sidebar header.
On the welcome screen, choose the Import option.
Press ⌘K and run Import connections….

The importer is a three-step, full-pane wizard: 1 · Source, 2 · Credentials, 3 · Review & import. Nothing is written to your inventory until you click Import on the last step, and the batch is all-or-nothing — a single bad row writes nothing, so your existing connections are never left half-changed.

What Transit reads — and what it never touches

Reads from your file	Never reads
Hostname / IP, port, username	Stored passwords
Folder / session hierarchy → groups	The SecureCRT password vault (`Password V2`) / MTPuTTY `Password` fields
Key-file paths (never key contents)	The SecureCRT config passphrase
Jump-host / `ProxyJump` references	(CSV has no password column)

Credentials are mapped in step 2, not pulled from the file. Transit groups your connections by distinct login, shows one row per login, and lets you point each at an existing auth profile or create a new one — the secret goes straight to your OS keychain. See Create an auth profile.

Method 1 — SecureCRT

Select your SecureCRT SCRTConfig.xml — the single-file session store SecureCRT keeps in its configuration folder (you can also produce it with SecureCRT’s Export Settings action). Transit parses the modern VanDyke version="3.0" format as real XML.

SecureCRT field	Transit field
`Hostname`	Host
`[SSH2] Port`	Port (default `22`)
`Username` (or the named credential’s username)	Username
Session folders	Group, e.g. `Lab/Core`
`Firewall Name`	Jump host (unless `None`)
`Identity Filename V2`	Key-file path
`Credential Title`	Links to a shared credential, deduped once

Only SSH2 sessions are imported. Telnet, Serial, RDP, and Local Shell sessions are skipped — you’ll see them listed in the notes — as are SecureCRT’s built-in Default templates.

The encrypted password vault (Password V2) and the configuration passphrase are never read, not even into a discarded variable. You re-enter those secrets once, in step 2.

Method 2 — OpenSSH ssh_config

Point the importer at an OpenSSH client config — your ~/.ssh/config, or any file containing Host blocks.

`ssh_config` directive	Transit field
`Host <alias>`	Connection name
`HostName`	Host (falls back to the alias)
`Port`	Port (default `22`)
`User`	Username
`ProxyJump`	Jump host (unless `none`)
`IdentityFile` (the first one wins)	Key-file path

Three things to know:

Wildcard-only blocks are skipped. Host * and similar are defaults, not real hosts. A block that mixes a concrete name and a wildcard (e.g. Host edge *.lab) is kept under the concrete name.
Include directives are not followed. Transit reads only the single file you pick. If your hosts live in included files, point the importer at the file that actually holds the Host blocks, or concatenate them first. Any skipped Include is reported in the notes.
No vendor or folder. ssh_config carries neither, so set the vendor and group in the review grid (you can bulk-set a whole selection at once).

Method 3 — CSV (the universal format)

CSV is the escape hatch — build it from a spreadsheet, an inventory export, or a script. Only the host column is required; everything else is optional.

Columns

Column	Accepted headers	Required	Default	Notes
Host	`host`	Yes	—	IP or hostname. The only required column.
Name	`name`, `id`	No	the host value	The connection’s name.
Port	`port`	No	`22`
Username	`username`, `user`	No	—
Vendor	`vendor`	No	`unknown`	One of the tags below.
Group	`group`	No	—	`/`-separated folder path, e.g. `Lab/Core`.
Key path	`key_path`, `identity_file`	No	—	Path to a private key; `~` is expanded.

Headers are matched by name, case-insensitively, in any order — Host, HOST, and host are equivalent, and columns can appear in any sequence. Unknown columns are ignored. There is no password column: a CSV row never carries a secret.

Vendor tags

The vendor value is lowercase and case-sensitive. Use one of:

Tag	Device
`junos`	Juniper Junos
`cisco_ios`	Cisco IOS
`cisco_ios_xe`	Cisco IOS-XE
`nxos`	Cisco NX-OS (alias: `cisco_nxos`)
`arista_eos`	Arista EOS
`pan_os`	Palo Alto PAN-OS
`linux`	Linux / Unix (unrestricted policy)
`unknown`	Other / unset

Any other lowercase tag — letters, digits, and underscores — is accepted as a custom vendor that you pair with your own permit list. See Vendor coverage.

Save as UTF-8 without a BOM

Save the file as plain UTF-8 with no byte-order mark. Some spreadsheet apps add one (Excel’s CSV UTF-8 option does); a BOM hides the host header from the parser, and the import fails with missing required host column. A normal editor’s UTF-8, and the template below, are correct.

Download the CSV template

Download transit-connections-template.csv — a ready-to-edit header row with example rows for several vendors plus one minimal host-only row.

name,host,port,username,vendor,group,key_path
core-rtr1,192.0.2.1,22,netops,junos,Lab/Core,
dist-sw1,192.0.2.2,22,netops,arista_eos,Lab/Distribution,~/.ssh/id_ed25519
edge-fw1,192.0.2.3,22,admin,pan_os,Lab/Edge,
spine1,192.0.2.4,2222,admin,nxos,DC1/Spine,
app-server1,192.0.2.10,22,root,linux,Servers,
,192.0.2.50,,,,,

The addresses use the 192.0.2.0/24 documentation range, so they won’t collide with real gear. The last row shows the minimum — a bare host — which imports as a connection named 192.0.2.50, port 22, vendor unknown, with no credentials yet.

Method 4 — MTPuTTY

In MTPuTTY, use Server → Export and save the XML file, then point the importer’s MTPuTTY tile at it. Copying the app’s own %APPDATA%\\TTYPlus\\mtputty.xml works too — both file shapes are accepted.

What comes across: display names, host, port, username, and your folder tree (as groups). Entries whose username, port, or key file live only in the PuTTY command-line parameters (-l, -P, -i, user@host) are picked up from there as a fallback.

Two kinds of entries are listed as skipped in the review notes rather than imported:

Registry-backed entries — an MTPuTTY server that only references a PuTTY saved session stores its host and port in the Windows registry, not in the XML. Open the session in PuTTY, note the host, and add it in Transit manually (or set the host on the MTPuTTY entry and re-export).
Non-SSH connection types — telnet, rlogin, raw, and serial entries are named in the notes and left out.

MTPuTTY’s Password / PlainPassword fields are never read — you map each login to a Transit credential in step 2, same as every source.

Method 5 — MobaXterm

Any of MobaXterm’s three session-bearing files works:

Right-click User sessions → Export sessions to file (.mxtsessions) — sessions only, the tidiest option.
Settings → Export configuration (.mobaconf) — the full backup; Transit reads just the bookmark sections and ignores the rest.
The live MobaXterm.ini from %APPDATA%\\MobaXterm (or next to the portable executable).

SSH sessions import with host, port, username, private-key path (when one is set), and your bookmark folder tree as groups. Everything else — telnet, RDP, VNC, SFTP, WSL, browser sessions — is named in the review notes as skipped, so nothing disappears silently.

MobaXterm stores session passwords in its own credential store; they are not present in the exported lines and Transit never touches them. Accented session names are fine — the importer handles MobaXterm’s Windows-1252 file encoding automatically.

Review, de-duplicate, and import

The review grid lists every connection found. Edit any cell inline — name, host, port, vendor, group, auth profile — or select several rows and bulk-set a field. Each row shows a status, and a notes disclosure collects every parser warning (skipped sessions, unfollowed Includes, rows with no host).

De-duplication is automatic and never destructive:

Duplicate within the file — a second connection that resolves to the same name gets a numeric suffix (core-rtr1, then core-rtr1-2). Nothing is dropped.
Already in your inventory — a connection whose name matches an existing device is flagged and left unchecked. Rename it to import it, or leave it excluded to skip it. Transit never silently overwrites a connection you already have.

Names are normalized to letters, digits, _, and -; other characters collapse to a single - (so core rtr 1 becomes core-rtr-1).

Click Import to commit. Auth profiles you created are already saved, and the connections are written in one atomic batch.

Limits

File size — 64 MiB. The parser refuses anything larger; a real SecureCRT export is ~1–2 MiB, so this is generous.
Connection count — no limit.
Encoding — UTF-8, plus Windows-1252 (what MobaXterm and other Windows exports actually write) detected automatically.

Troubleshooting

missing required host column — The CSV’s header row has no host column, or the file was saved with a BOM that hid it. Add a host header and re-save as UTF-8 without a BOM.
“No connections were found in that file.” — For ssh_config, the hosts may live in Included files (not followed), or the file is all wildcard Host * blocks; point at the file with real Host blocks. For SecureCRT, confirm you selected the SCRTConfig.xml (it has a <VanDyke> root).
A SecureCRT session is missing — Non-SSH2 sessions (Telnet, Serial, RDP, Local Shell) are skipped by design. Check the notes list on the review step.
The vendor imported as unknown — The vendor cell was empty or not one of the tags above (values are lowercase and case-sensitive). Set it in the grid, or bulk-set a selection.
Where do my passwords go? — Nowhere, from the file. You map each login to a credential in step 2, and the secret is enrolled into your OS keychain at that point.