Asbru Connection Manager treats Expect scripts as part of the connection record

The connection record is where the automation lives

Most connection managers store a host, a port and a username. Asbru stores a small execution environment with each connection, and that is the design decision the whole tool rests on.

The feature list describes what can hang off a connection. There are configurable pre or post connection local commands, so something runs before or after the session connects. There is a configurable list of macros, commands to execute locally when connected or to send to the connected client. There is a configurable list of conditional executions on the connected machine via Expect, with four named uses: forgetting about SSH certificates, chaining multiple SSH connections, automating tunnel creation, and line-send delay capabilities.

That last group is the unusual part. Expect is a tool for scripting a conversation with a program that expects input. Chaining multiple SSH connections means a script can walk through a sequence of hosts where each one prompts for the next. Automating tunnels means a session that asks a question before the tunnel exists can be scripted.

Local and global variables complete the picture, and the README's description of them is unusually concrete: write down a password once, use it anywhere, centralizing its modification for faster changes. The named uses are a password vault and reusing connection strings.

Together these mean Asbru is closer to a terminal automation tool with a connection list attached than to a bookmark manager. That is the honest characterisation, and it is why the dependency on Expect matters more than the dependency on SSH.

Installation is a Cloudsmith script per distribution

The recommended installation is a pre-built package from Cloudsmith, and the pattern is identical across distributions: add a repository with a curl-piped script, then install.

On Debian and Ubuntu:

curl -1sLf 'https://dl.cloudsmith.io/public/asbru-cm/release/cfg/setup/bash.deb.sh' | sudo -E bash
sudo apt-get install asbru-cm

On Fedora:

curl -1sLf 'https://dl.cloudsmith.io/public/asbru-cm/release/cfg/setup/bash.rpm.sh' | sudo -E bash
sudo dnf install asbru-cm

The Debian one adds an apt repository and the Fedora one adds a dnf repository, but the shape is identical, which is what a Cloudsmith-hosted package set looks like.

Two distributions are handled differently. Pacman-based systems such as Arch and Manjaro go through the AUR rather than Cloudsmith, by cloning `asbru-cm-git` and running `makepkg -si`. MX Linux is served through the MX Package Installer under a Test Repo tab, or by enabling the Test Repo and running the same `sudo apt-get install asbru-cm`.

Once installed, you run `asbru-cm` in a terminal, which on a native Linux system means it opens its own window.

The Windows route is the one to read carefully. On Windows 10 Build 19044 and later, or Windows 11, you install or update WSL, follow the Ubuntu instructions above, and the application appears in the start menu,. On older Windows 10 or older WSL, you enable WSL and use a separate application, Asbru-CM Runner, and if WSLg is unavailable you additionally need an X server such as Xming. The Runner project also has the stated benefit of running without a console window left open in the background.

A separate section covers legacy 5.x installs through packagecloud rather than Cloudsmith, which matters only if you are pinned to the older line.

master is stable, loki is where new work lands

The branching model is stated with an analogy that makes it clear, and the analogy is deliberately unflattering.

Master and the snapshots are kept as stable as possible, and new features for new major releases are developed inside the `loki` branch. The README then warns that Loki can sometimes behave in an unexpected manner, and compares it to the same concept as Debian sid, the rolling unstable release.

That is a plain statement that the development branch is not usable for anything you care about. Compare it to a package channel: you install from master and you test on loki.

The loki builds are hosted on Cloudsmith as a separate repository, with the same per-distribution script shape. The deb and rpm scripts differ only in the path, using the `loki` segment instead of `release`:

curl -1sLf 'https://dl.cloudsmith.io/public/asbru-cm/loki/cfg/setup/bash.deb.sh' | sudo -E bash

One instruction in that section is worth internalising for anyone who installs by piping a script into a shell. The README says that if you do not wish to run third party scripts on your systems, you can access manual install instructions at the Cloudsmith setup page for the loki repository instead. Manual instructions exist for both channels; the script is a convenience, not a requirement.

The repository listing shows a `ci/` directory alongside `build.sh`, `dist/`, `contrib/` and `scripts/`, and the README carries two workflow badges, one for building and deploying documentation and one for building snapshot and master packages. So both the packages and the docs are built in CI, and snapshot builds are what you get between releases.

The recent releases include a `snapshot` build dated 2026-08-04, ahead of v6.4.1 from 2026-04-04, and 6.4.0 from 2022-11-13. So the last tagged release before the current one is four years older than the one before it, which tells you the 6.4 line sat for a long time and the current work is the run up to the next major.

It is a fork of PAC Manager, and that explains the feature set

The FAQ answers the naming question and then the origin question, and the second answer explains more about the software than the feature list does.

The name comes from Norse mythology, where Ásbrú is a burning rainbow bridge connecting Midgard, the Earth, with Asgard, the realm of the gods.

The project is a fork of PAC Manager, Perl Auto Connector. The FAQ states it as a fact and explains why: the author of PAC Manager, named in the answer, could not find the time, for reasons the project respects, to continue the work, and was not open for external contributions, linked to an issue on the original repository. A fork was needed to ensure the future and give the community the opportunity to take over.

That origin explains several things about the feature list. The scripting capabilities are described as being 'ala SecureCRT, which names the model: a GUI over a terminal emulator with scriptable connections. The tunnel client topic, the Expect integration and the macro lists are all features you would add to a connection manager once you have more than a handful of connections and need to repeat the same sequence on each.

The GUI stack features GNOME and Gtk integration, plus a tray icon for right-click quick launching of managed connections. There is also a KeePassXC integration.

Remaining features are conventional for the category: connecting through a proxy server, cluster connections for the same session across multiple machines, tabbed or windowed terminals, Wake On LAN, and DEB, RPM and tar.gz packages.

Maintenance state, licensing and what to check first

The repository is not archived and the last push was on 2026-08-04, a little over two months before today, which is consistent with active work on the loki branch rather than maintenance of a finished product.

Licensing is GNU General Public License version 3, with the LICENSE file at the repository root. For a tool that stores connection credentials and can run Expect scripts that answer prompts, GPL-3.0 is worth thinking about before you modify it for internal use: the copyleft obligation attaches to a distributed derivative, and how far that reaches for an unmodified packaged installation depends on your distribution. This is not legal advice, but it is the kind of question worth asking early rather than after you have built a workflow on it.

The governance files are unusually complete for a project of this size. There is a `CONTRIBUTING.md`, a `CODE_OF_CONDUCT.md` under the Contributor Covenant, a `CODING_STANDARD.md`, a `CHANGELOG.md` and a `NEWS.md`. The contributing instructions ask you to check the issues first and say issues and pull requests will be triaged and responded to as quickly as possible.

Funding is handled through Liberapay and a set of cryptocurrency addresses in the project documentation, and the README also carries donation badges for both. The docs are built with mkdocs from the `mkdocs.yml` at the root.

Three checks are worth doing before you commit a workflow to it. First, run `master`, not loki, and confirm the Expect scripts behave on your terminals, since Expect interacting with an interactive prompt is exactly where version differences show up. Second, decide how you will handle credentials: if you use the local variables feature as a password vault, understand that the password is stored in Asbru's own configuration, which is a different trust position from KeePassXC. Third, if you are on Windows, confirm your WSL version and whether you have WSLg, because the documented GUI path depends on it and the fallback involves a third-party runner application.

Editorial conclusion

Asbru Connection Manager fits a Linux administrator who has twenty SSH connections and keeps retyping the same post-login commands, since variables, macros and Expect blocks make that work part of the connection record rather than a shell history. Do not adopt it on a machine without a display, because it is a GTK application that needs X11 or WSLg, and do not treat the loki branch as production, since the README compares it to Debian sid. Verify first whether your terminals can run Expect, because that is the feature everything else is built around and the one most likely to need review before you trust it with credentials.

Frequently asked questions

Official sources

1. asbru-cm/asbru-cm on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases