Hey @r1ddl3, the SSH Target Type is currently an HCP Boundary only feature. This comes with Credential Injection – the ability for Workers to inject credentials on-behalf of users. Our feature matrix is also published here.
With Boundary OSS, TCP Targets will support any TCP type connection. This includes the SSH protocol, however you will only be able to broker credentials back to users. This guide walks through the process of setting up a TCP target.
Hi, so the user would either have to type the credentials from the vault/brokering or have the SSH key on their machine? Unless we pay for the enterprise version?
Yeah – Brokering is supported on Boundary OSS, whereas Brokering & Injection of Credentials is supported on HCP Boundary. You can broker any credential you desire(e.g using the Static Credential Store or Vault, including usernames & passwords, key pairs, JSON blobs, api tokens, etc.
Brokering means the credentials are returned to the user, so yes, in this case, the contents of an SSH key would be shared with the user, but you can handle the lifecycle of credentials using Vault’s Dynamic Secrets Engine.
Credential Injection is currently a paid only feature on HCP Boundary(with the first 50 sessions being free).
An additional piece that @louisruchmentioned in another thread: The Boundary CLI has a concept of consuming credentials on behalf of the user. This happens when using the connect helper commands, so for example boundary connect ssh... with a brokered ssh_private_key credential, Boundary will attempt to use that credential without the user having to manually enter it.
This does not work for username_password unless you use -style sshpass and have sshpass(1) - Linux man page installed on your client machine.