SSH, exec and copy

These commands use your computer's OpenSSH, with the server's address and user filled in for you.

layerbeat ssh agent-01                     # an interactive shell
layerbeat ssh agent-01 -- uptime           # one command
layerbeat exec agent-01 -- df -h /         # one command, never prompts (for scripts and agents)
layerbeat cp ./app.tar agent-01:/root/     # copy to the server
layerbeat cp agent-01:/var/log/syslog .    # copy from the server
layerbeat cp -r ./site agent-01:/srv/      # a folder

Host keys are pinnedCopy Anchor Link

When Layerbeat sets up a server it records the server's SSH host keys. The CLI checks every connection against them and refuses a server that presents a different key — so you never have to answer "Are you sure you want to continue connecting?", and an agent never trusts an unknown machine. The keys are kept in ~/.config/layerbeat/known_hosts.

A server set up before host keys were recorded has none on file. For those, --accept-new-host-key (on exec and cp) trusts the first key it sees and pins it from then on.

exec for scripts and agentsCopy Anchor Link

exec never asks a question. The remote command's output streams through, and its exit status becomes exec's, so layerbeat exec agent-01 -- test -f /etc/app.conf works in an if.

With --json the output is captured instead:

layerbeat exec agent-01 --json -- systemctl is-active caddy
# {"exit_code": 0, "stdout": "active\n", "stderr": ""}

Then the CLI exits 0 once the command ran (whatever its own exit code), and 9 if SSH itself failed. --timeout sets how many seconds to wait for the connection (default 10).

Log-in user and keysCopy Anchor Link

The CLI logs in as the server's own login user (root or ubuntu, depending on the image) with the SSH keys you chose when buying. Servers bought with a password: read it with layerbeat password reveal agent-01. Windows servers use Remote Desktop rather than SSH; see Windows servers.