> ## Documentation Index > Fetch the complete documentation index at: https://www.rumus.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Host groups & known_hosts > Organize hosts into nested groups, and manage the trust list of host keys Rumus has seen before. Two related housekeeping tasks live on this page: * **Host groups** — collapsible folders for organizing your saved hosts. * **Known hosts** — the list of SSH host keys Rumus has trusted, plus how it handles new and changed keys. ## Host groups Once you have more than a handful of hosts, scrolling a flat list gets tiring. Groups let you organize them by environment (`prod`, `staging`, `dev`), team, region, or whatever taxonomy fits. ### Create a group **Settings → Vaults → Hosts** (or the **Remote Connection** dialog from the tab-bar chevron). Give it a name. Optionally pick a parent group — groups can nest, so you can have e.g. **prod → us-east → web**. Drag hosts into the group, or use the row menu's **Move to group** action. Hosts that aren't in any group sit under the **Ungrouped** label. ### Edit / rename / delete groups Right-click a group (or use its row menu) for **Edit Group** (rename, change parent) and **Delete Group**. Deleting a group does **not** delete the hosts inside it — they fall back to **Ungrouped** unless they had another parent in the chain. ### Tips * Groups are collapsible. Closing the ones you're not using right now is the fastest way to keep the list readable on a small screen. * Pair group names with **tab colors** ([per host](/docs/remote/hosts)) so the visual hierarchy carries into your tab bar. ## Known hosts SSH's first defense against impersonation is the **host key** the server presents at connection time. Rumus tracks the keys it's seen before and warns you when something changes. ### Trust on first use The first time you connect to a host whose key isn't in your known list, Rumus shows the **Trust new host key?** dialog with: * The **Host** name. * The **Key Type** (e.g. `ssh-ed25519`, `rsa-sha2-512`). * The **SHA256 fingerprint**. * **Trust** and **Cancel** buttons. Compare the fingerprint to whatever your team / vendor has documented before clicking **Trust**. Once trusted, Rumus doesn't ask again — until the key changes. ### Host key changed If the key on the server doesn't match what Rumus has stored, you get a much louder dialog: **Host key changed**, with a warning that the host key does not match your known host record. The legitimate causes are: * The server was reinstalled. * An admin rotated the host key. The not-legitimate cause is **someone is intercepting your connection**. If you're not expecting a key change, **cancel** and verify with whoever runs the server before continuing. Trusting the new key updates your known host record going forward. ### Manage trusted keys Open **Settings → Vaults → Known Hosts** to see every host key Rumus has trusted. Each entry shows the host label, key type, and fingerprint. Available actions per entry: * **Delete** — forgets the key. The next connection to that host will trigger the **Trust new host key?** dialog again. The page also has an **Import from System** button that scans your OS's `~/.ssh/known_hosts` (and equivalents) and pulls those entries into the Rumus trust list. The import dialog reports how many entries were imported, how many were skipped (already known), and which sources contributed. ### Where the trust list lives The known-hosts list is part of your encrypted [vault](/docs/account/vault). It syncs across devices through [Vault sync](/docs/account/vault-sync), so trusting a host on your laptop also makes it trusted on your desktop. ## Next steps Add and edit the hosts inside your groups. How known\_hosts (and everything else sensitive) is stored.