boundary/website/content/docs/getting-started/connect-to-target.mdx

---
layout: docs
page_title: Connect to Target
sidebar_title: Connect to Target
description: |-
  Connecting to your first target
---

# Connect to Your First Target

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:

```
$ 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
`-username`, an equivalent alternative would be:

```
$ boundary connect ssh -target-id ttcp_1234567890 -- -l some-other-user
```

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:

- `ssh`: defaults to the local SSH client (`ssh`)
- `postgres`: defaults to the official Postgres CLI client (`psql`)
- `rdp`: defaults to the built-in Windows RDP client (`mstsc`)

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 you wanted to use Boundary to create an authenticated firewall
around 'curl', you could update the default TCP target from a default port
of `:22` to `:443`:

```
$ boundary targets update tcp -default-port 443 -id ttcp_1234567890

Target information:
  Created Time:               Fri, 25 Sep 2020 18:35:47 PDT
  Description:                Provides an initial target in Boundary
  ID:                         ttcp_1234567890
  Name:                       Generated target
  Session Connection Limit:   1
  Session Max Seconds:        28800
  Type:                       tcp
  Updated Time:               Fri, 25 Sep 2020 18:36:18 PDT
  Version:                    2

  Scope:
    ID:                       p_1234567890
    Name:                     Generated project scope
    Parent Scope ID:          o_1234567890
    Type:                     project

  Host Sets:
    Host Catalog ID:          hcst_1234567890
    ID:                       hsst_1234567890

  Attributes:
    Default Port:             443
```

In the output above the default port for the target has now changed to `:443`.

Now, `curl` can be used as the executed client for the TCP target session to do
an authenticated download of hashicorp.com:

```
$ boundary connect -exec curl -target-id ttcp_1234567890 \
         -- -vvsL --output /dev/null hashicorp.com

*   Trying 76.76.21.21...
* TCP_NODELAY set
* Connected to hashicorp.com (76.76.21.21) port 80 (#0)
> GET / HTTP/1.1
> Host: hashicorp.com
> User-Agent: curl/7.64.1
> Accept: */*
...<truncated output>...
```

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:

```
$ boundary connect ssh -style putty -exec putty.exe -target-id ttcp_1234567890
```