sshw: a Go wrapper that remembers your servers and logs in for you

What the tool actually does

sshw is described in one line as an ssh client wrapper for automatic login, and that description is accurate rather than a marketing flourish.

The idea is that you keep a list of your servers in a YAML file and then log in by name. The configuration supports a name, a user, a host, a port, a password, a key path, a passphrase and an alias, and any of them except the host may be omitted, with sensible defaults filled in. The example configuration shows a fully specified server, a server with a key path, a server with a passphrase-protected key, a server without a port, a server without a user, a server without a password, a server with an emoji in its name, and a server with an alias.

The repository layout shows a small Go program. There is a client.go, a config.go and a log.go at the root, a cmd directory holding the main package, a go.mod and go.sum, an assets directory with a demo recording, and a .goreleaser.yml for building release binaries.

The dependency list is short and says what the tool is built from. It uses the homedir package to resolve the home directory, the ssh_config package to parse OpenSSH style configuration, promptui for an interactive selection prompt, the crypto package for the SSH protocol, and yaml.v2 for the configuration format. The indirect dependencies are the readline library, the terminal handling package and the system calls package, which are all pulled in by promptui and the crypto library.

Installing it and the six config file locations

Installation is a go install, with a release binary as the alternative:

go install github.com/yinheli/sshw/cmd/sshw@latest

The README also points to the releases page for downloading a binary directly, and the .goreleaser.yml at the root is the configuration for producing those binaries.

The configuration file is loaded from one of six locations, in order. The home directory variants come first, with a dotfile named .sshw, then .sshw.yml, then .sshw.yaml, followed by the same three names in the current directory, .sshw, .sshw.yml and .sshw.yaml. The order matters because it determines which file wins when more than one exists, and it is worth knowing that a project-local file sits behind the home directory one, so a repository you clone cannot silently override your personal configuration.

The go.mod declares go 1.25, and the module path is github.com/yinheli/sshw. The last release was v1.1.2 on 2024-12-31, before that v1.1.1 in August 2022 and v1.1.0 in March 2019, and the last push to the repository was on 2026-05-11.

The configuration format and what each key buys

The example configuration is a YAML list of server entries, and it doubles as the documentation of the format. The inline flow style is used for the simple cases:

- { name: dev server fully configured, user: appuser, host: 192.168.8.35, port: 22, password: 123456 }
- { name: dev server with key path, user: appuser, host: 192.168.8.35, port: 22, keypath: /root/.ssh/id_rsa }
- { name: dev server with passphrase key, user: appuser, host: 192.168.8.35, port: 22, keypath: /root/.ssh/id_rsa, passphrase: abcdefghijklmn}

The block style appears when an entry needs more structure, such as a jump host:

- name: server with jump
  user: appuser
  host: 192.168.8.35
  port: 22
  password: 123456
  jump:
  - user: appuser
    host: 192.168.8.36
    port: 2222

The jump key takes a list, so more than one hop is expressible, and each hop carries its own user, host and port. That is the feature that distinguishes sshw from a plain alias script, since a chain of two hops is exactly the case where typing the command by hand is most error prone.

There is also an alias key, which is a short name to type instead of the descriptive one, and a name field that is free text. The example includes a server whose name contains an emoji, which is a small sign that the names are meant for interactive selection rather than for scripting.

Groups and the callback mechanism

Two further features round out the configuration.

Groups are expressed with a children key under a name, and the example shows two of them with three servers each:

# server group 1
- name: server group 1
  children:
  - { name: server 1, user: root, host: 192.168.1.2 }
  - { name: server 2, user: root, host: 192.168.1.3 }
  - { name: server 3, user: root, host: 192.168.1.4 }

The point of a group is that a set of related hosts can be named as one thing, which matters when the set is a cluster or a service tier.

The callback feature is the more unusual one, and it is the closest thing here to automation. A server entry can carry a callback-shells list, and each entry is a command with an optional delay:

- name: dev server fully configured
  user: appuser
  host: 192.168.8.35
  port: 22
  password: 123456
  callback-shells:
    - { cmd: 2 }
    - { delay: 1500, cmd: 0 }
    - { cmd: "echo 1" }

The numeric commands are sent to the remote shell, and the delay in milliseconds waits before sending the next one. The pattern of a numeric command followed by a delay followed by a shell command is the standard way of answering a prompt such as a password or a confirmation, and the delay covers the case where the remote side needs a moment before the prompt appears. This turns a scripted login into something you can drive without typing the responses by hand.

The trade is that these are stored commands executed on the remote host as part of the session, and the delay-based approach is timing dependent, so a slow remote makes the sequence fragile.

Where sshw is the wrong choice

The first limitation is the credentials file. The documented example stores a plaintext password next to the host, and a passphrase for a key in the same file, in a file that the loader will pick up from your home directory or from a project directory. Any workflow that forbids that, whether through policy or through the fact that the file is committed by accident, rules the tool out. There is no mention of an encrypted store, a system keychain, or a reference to a secret manager in the documentation.

The second is the relationship with the standard SSH configuration. The dependency list includes a library for parsing OpenSSH style configuration, which suggests the tool reads your existing ssh_config for some settings, and the config file format mirrors it closely enough that the two could be confused. But an OpenSSH config can express things this wrapper has no field for, including ProxyCommand, LocalForward, host key algorithms and identity handling. If your servers need a tunnel or a bastion with a specific command, the ssh_config you already have is the better tool, and it is already installed.

The third is the scope. This is a convenience wrapper for interactive sessions, with promptui for choosing a server and a Go SSH client under the hood. It does not manage keys, it does not do host key verification in any documented way, and it does not script. For a fleet of machines, an orchestration tool is the right category, and for a handful of hosts, aliasing ssh in your shell profile is nearly as good and has none of the credential file concerns.

The fair comparison is with a shell alias or an ssh_config Host block. Both give you a short name. sshw gives you more: saved passwords, jump chains, groups and callbacks, at the cost of a Go binary that holds your credentials in a file it reads for you.

Editorial conclusion

sshw fits a developer or administrator with a fixed set of servers they log into every day and who finds retyping the same ssh command tedious. It does not fit an environment that forbids storing credentials in a file, and it does not replace an SSH config for anything that needs host key verification, tunnels or a ProxyCommand. Before using it, decide where the config file will live, since the loader walks the home directory and the current directory, and note that the documented example puts plaintext passwords in that file. If you use key path with a passphrase, check how that passphrase is handled, and if you rely on jump hosts, test the chain before you need it in a hurry.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. yinheli/sshw on GitHub