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.
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.
Checkpoint: the version and path shown above should match the machine you plan to install the launcher on. Package updates can change the implementation, so treat the local manual page as the contract for this specific host.
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
ssh-argv0; the link name is what carries the host.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.
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].
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.
PATH with command -v.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.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.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.
ssh-argv0 is installed and its OpenSSH package version is known./usr/bin/ssh-argv0.launcher -G shows that basename as the effective host without connecting.