# SSH Between Nodes

> Connect to a Whalenet member over SSH with the host key checked inside the client against a DNSSEC-validated SSHFP record, and no key of yours copied.

*Source: https://www.whisper.security/docs/whalenet/ssh*

---
`whisper whale ssh` connects to a fleet node with the host key verified before the connection is trusted, and with no key of yours copied to the target. It wraps `ssh(1)` rather than replacing it, so the arguments you already know still work.

## 1. See what will be checked, first

```bash
whisper whale ssh db-01 --explain
```

This names the SSHFP record for the node and the validation chain that leads to it, and connects to nothing. Run it first on a node you have not reached before: it tells you whether the host key is publishable and verifiable at all, which is the only thing that can stop step 3.

`--print-command` prints the exact `ssh` command the wrapper would run, and runs nothing.

## 2. Connect

```bash
whisper whale ssh alice@db-01
```

Write the login name either as `user@node` or with `-l`, and set a non-default port with `-p`. The argument shape is `ssh`'s own: anything after the destination is the remote command, and anything after `--` is an `ssh(1)` option inserted before it.

```bash
whisper whale ssh db-01 systemctl status whisper
```

## 3. Know what the host key check actually is

The host key is checked here, in this process, against the SSHFP record published for the node, validated from the IANA root trust anchor compiled into the binary. It does not read a resolver's `AD` bit, so a resolver that answered cannot decide the outcome for you.

There is no trust-on-first-use. A node with no SSHFP published, or one offering a key that matches none of the published digests, is refused, and the message says which of the two happened. A record carrying only a SHA-1 digest is refused, and so is a certificate host key: neither pins the key the way a digest over the key itself does.

| Flag | Does |
|---|---|
| `--resolver` | Walk the DNSSEC chain through a specific resolver. Defaults to the system resolvers, then public validating ones. |
| `--ssh` | Use a different `ssh(1)` binary. |

Where the SSHFP record comes from, and the other record types a node publishes about its keys, is [keys, signing and encryption](/docs/identity/keys).

## 4. Know who is allowed in

The host key check proves you are talking to the right machine. Who may log in is a separate decision, made on the target by its authorized-keys command reading a DNSSEC-signed access list. That means a principal you remove is denied on the target itself, and the denial lands in the target's own auth log where an audit will find it.

`--explain` names both halves, which is why it is the first step on this page rather than a footnote.

## When a connection fails

Work from the outside in. `whisper whale ping <node>` says whether anything reached the node at all, and on which port; [inspect your fleet](/docs/whalenet/inspect) covers it. If the node answers but SSH is refused before a password or key is offered, the reachability decision is the thing to read: `whisper whale acl test <src> <node>:22` says what [the access document](/docs/whalenet/access) makes of that exact flow. If the node answers and the wrapper refuses, the host key is the thing to read, and `--explain` says why.