Make sure you've exported the dev Boundary server address: `export BOUNDARY_ADDR=http://127.0.0.1:9200`
The default target is a TCP target with a default port of `22` (SSH). The host
sets for this target contain the default host, which has the address
`127.0.0.1`. When we run `boundary connect` against this target, the single
available host will be selected and we'll open a local authenticated proxy to
the target host on the target's default port (`127.0.0.1:22`). Because this
target is proxying to our local SSH server, we can use our built-in `connect
ssh` command to wrap the proxied TCP connection and SSH via Boundary:
The default target is a TCP target with a default port of `:22`. The default host associated with this target is `127.0.0.1`. When we run `boundary connect` against this target, we'll open a local authenticated proxy to the target host's default port (`127.0.0.1:22`). Because this target is proxying our SSH server locally, we can use our built-in `connect ssh` command to wrap the proxied TCP connection and SSH via Boundary:
```
boundary connect ssh -target-id ttcp_1234567890
```
This will execute SSH on the target and port combination specified by the local
boundary proxy. If you want to specify a username other than your currently
logged-in user, you can do so via the `-username` flag.
If you want to pass additional flags to the SSH client, you can do so by adding
them to the command line separated by a double-dash; anything after the double
dash will be passed to the executed client. For instance, rather than using
This will execute SSH on the target and port combination specified by the local boundary proxy. The `--` usage allows you to specify flags to pass to the SSH session, in this case, `-l <username>` allows us to override the username SSH will use in starting the session.
There is also a `-style` flag to allow the command to format arguments in a
different style expected by different SSH clients. At the moment, besides `ssh`
(the default), the `boundary connect ssh` command supports `-style putty` to
support passing connection information to PuTTY.
## Built-In vs. Exec
Boundary comes with built-in wrappers for popular layer 7 connection protocols, such as:
Boundary comes with built-in wrappers for popular layer 7 connection protocols,
such as:
- `ssh`: defaults to the local SSH client (`ssh`)
- `postgres`: defaults to your local Postgres client (`psql`)
- `rdp`: defaults to your local RDP client (`mstsc`)
- `postgres`: defaults to the official Postgres CLI client (`psql`)
- `rdp`: defaults to the built-in Windows RDP client (`mstsc`)
However, we know that sometimes you may want to do something totally off the cuff, and for that we have a built in connect flag called `-exec`. The `-exec` flag is a very powerful tool, allowing you to wrap Boundary TCP sessions in your preferred client. You can use this flag to create an authenticated proxy to almost anything.
However, `boundary connect` can accommodate executing clients even when there is
no built-in support for a specific client using `-exec`. The `-exec` flag is a
very powerful tool, allowing you to wrap Boundary TCP sessions in your preferred
client. You can use this flag to create an authenticated proxy to almost
anything.
For example, if we wanted to use Boundary to create an authenticated firewall around DNS lookups, we can update the default TCP target from a default port of `:22` to `:53`
For example, if you wanted to use Boundary to create an authenticated firewall
around DNS lookups, you could update the default TCP target from a default port
@ -113,6 +143,20 @@ google.com. 299 IN A 216.58.193.78
;; MSG SIZE rcvd: 55
```
In the above example, we override the nameserver with `@{{boundary.ip}}` to tell dig to use the local Boundary proxy IP as the namesever. We also overrode the port dig uses with `-p {{boundary.port}}` to tell dig to use the ephemeral port that Boundary proxy will run the session on.
In the above example, the normal system nameserver is being overridden with
`@{{boundary.ip}}` to tell dig to use the local Boundary proxy IP as the
namesever. The port dig uses has also been overriden with `-p {{boundary.port}}`
to tell dig to use the ephemeral port on which Boundary proxy will run the
session.
Lastly, you'll notice we used the `+tcp` flag for the dig command here. DNS by default will use UDP and the session that Boundary creates is a TCP connection, so we override this to force dig to use TCP by default.
Lastly, the `+tcp` flag was specified for dig, as DNS by
default will use UDP and the session that Boundary creates is a TCP connection.
Note that `-exec` is available for subcommands that wrap clients as well. As an
example, if `putty.exe` is available on a Windows host but the command is being
run from WSL, the following allows usage of the wrapper but while specifying the
correct available binary, as WSL must use `.exe` when invoking Windows binaries:
Jeff Mitchell
6 years ago