Use ssh-argv0 to Turn a Hostname into an SSH Command

ssh-argv0 is the trick behind a launcher that behaves like ssh HOSTNAME just because of what you named the symlink. It reads its own invoked name, puts that in front of your arguments, and hands everything to ssh. The examples use the installed OpenSSH client 9.6p1, package version 1:9.6p1-3ubuntu13.19, on a Debian-family system.

Allow about ten minutes. You need the openssh-client package, a writable directory for a symlink, and a host name you are authorised to connect to. This guide makes one reversible symlink and touches nothing in SSH configuration, remote accounts or services.

1. Check the installed helper

Confirm the helper is present and note the package version. These are ordinary read-only commands, no elevated privileges needed:

$ command -v ssh-argv0
/usr/bin/ssh-argv0
$ dpkg-query -W -f='${Package} ${Version}\n' openssh-client
openssh-client 1:9.6p1-3ubuntu13.19
$ ssh -V
OpenSSH_9.6p1 Ubuntu-3ubuntu13.19, OpenSSL 3.0.13 30 Jan 2024

The helper is a plain POSIX shell script, not a second SSH implementation, so there is nothing clever happening under the hood. Try running it directly as ssh-argv0 and it deliberately refuses, because that name is not a usable host.

2. Create a hostname-named symlink

Pick a name that is also a valid SSH host name. buildbox.example.org below is a placeholder: replace it with the host you actually intend to reach.

$ install -d -m 700 "$HOME/bin"
$ ln -s /usr/bin/ssh-argv0 "$HOME/bin/buildbox.example.org"
$ ls -l "$HOME/bin/buildbox.example.org"
lrwxrwxrwx 1 ... /home/you/bin/buildbox.example.org -> /usr/bin/ssh-argv0

• Target is the helper. The symlink must point at ssh-argv0; the link name is what carries the host.
• Never name the link ssh-argv0. That triggers the helper's deliberate refusal instead of a connection.
• install -d only touches your home directory. It creates the target directory if missing and nothing else.

If your shell cannot find the new command, add the directory to your current shell's PATH:

$ export PATH="$HOME/bin:$PATH"
$ command -v buildbox.example.org
/home/you/bin/buildbox.example.org

Only edit a shell startup file if you want this available in every future shell. That is a persistent change, so inspect the file and keep a backup first. The launcher itself never needs root.

3. Verify argument construction without connecting

OpenSSH's -G flag prints the effective configuration and exits without touching the network, which makes it a safe smoke test. Substitute your link name:

$ buildbox.example.org -G | sed -n '1,8p'
host buildbox.example.org
user your-local-user
hostname buildbox.example.org
port 22
addressfamily any
batchmode no
canonicalizefallbacklocal yes
canonicalizehostname false

The local user, defaults and remaining lines will differ on your machine. What matters is that host and hostname both show the symlink's basename, and that the command exits cleanly. It proves nothing about DNS, authentication or the remote service, only that the launcher assembled the right arguments.

For a firmer check, add an option and a command-shaped argument. -p is consumed by SSH itself, while trailing words remain arguments after the host:

$ buildbox.example.org -G -p 2222 | grep -E '^(hostname|port) '
hostname buildbox.example.org
port 2222

Do not put the host name after the options the way you would with plain ssh. The helper takes the host from its own invocation name, so the shape is always launcher [SSH options] [remote command].

4. Use it for a real connection

Once the no-network checks look right, a normal login is just this:

$ buildbox.example.org
[email protected]'s password:

That can prompt for credentials and run a remote shell, so confirm the host, account, port and key policy before you hit enter. A safer first remote command is a read-only identity check:

$ buildbox.example.org 'printf "host=%s user=%s\n" "$(hostname)" "$(id -un)"'
host=buildbox.example.org user=remote-user

Output depends on the remote machine. Quote the remote command as one local shell argument if you want its substitutions to happen on the far end, and SSH options still go before that command, for example buildbox.example.org -p 2222 'id -un'.

Everything else the helper receives passes straight to ssh, so identity files, config files, forwarding and escape characters all follow the ordinary SSH manual. Do not borrow an option from an unrelated client without checking what it actually does; forwarding in particular can expose local or remote services and deserves its own review.

5. Recover from the common traps

• Running /usr/bin/ssh-argv0 directly prints a warning and exits 1. That is the helper working as designed. Invoke the symlink whose basename is the target host instead.
• "command not found". Check PATH with command -v.
• -G shows the wrong host. Confirm the symlink's actual basename with basename -- "$(readlink -f "$HOME/bin/buildbox.example.org")", then check you invoked the intended link. The host comes from the link's basename, never from its target path.
• A real connection fails. Separate launcher problems from SSH problems: rerun buildbox.example.org -G first, then fall back to ordinary SSH diagnostics like -v. A failed DNS lookup, a refused port, a missing key or a remote policy is not fixed by recreating the symlink.

6. Remove the launcher when it is no longer needed

Removing the link is the whole undo operation. Check the exact path before deleting it, especially if the name came from a variable:

$ ls -l "$HOME/bin/buildbox.example.org"
$ rm "$HOME/bin/buildbox.example.org"
$ command -v buildbox.example.org || printf '%s\n' 'launcher removed'
launcher removed

This removes only the symlink, never /usr/bin/ssh-argv0 and never any remote data. No elevated privilege is needed for a link inside your own directory, and there is no reason to reach for a broad recursive removal command here.