Import from ~/.ssh/config

Anyone managing a fleet almost certainly has ~/.ssh/config. Retyping thirty hosts by hand is the kind of reason why a tool gets abandoned during the trial period.

How to Use

1. Choose the project to import into.
2. Import from SSH config.
3. The app reads ~/.ssh/config (or a path you specify) and lists the hosts found.
4. Checkbox the hosts you need, then Import.

The preview step writes nothing — only reads and displays. Nothing gets created until you press the final button.

What Gets Read

In config	Into app
Host	VM name
HostName	Host — if missing, use the Host label itself, just as ssh does
Port	Port (default 22)
User	Display only for reference
IdentityFile	Display only, key content is not read

What Is Intentionally Skipped

This reader deliberately does incomplete work:

• Include is not followed.
• Match blocks are ignored.

Both can cause a host to resolve differently depending on context, and that cannot be faithfully represented in a checkbox list. Import the simple items and handle the rest yourself is better than import something subtly wrong.

If your config uses many Include statements, import from each file separately by specifying the exact path.

Credentials Are Not Imported

This is the most important point and also deliberate:

IdentityFile only displays. The app never opens or reads your private keys.

After importing hosts, add credentials for each VM intentionally — see Credentials. Sounds more tedious, but that’s the right boundary: a tool that automatically vacuums all keys from ~/.ssh should not exist.

After Importing

• Tag the group of imported machines for fast filtering later.
• Rename if the config label is too cryptic (h3 → db-primary).
• Enable monitoring for critical machines.

No ~/.ssh/config?

You can still add by hand, or write a minimal config file and import it:

Host web-01
    HostName 10.0.1.11
    Port 22
    User deploy

Host db-01
    HostName 10.0.1.20
    User deploy