Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using a user in the host property with SSH does not work since 4.0.1 #635

Closed
limond opened this issue May 15, 2023 · 5 comments
Closed

Using a user in the host property with SSH does not work since 4.0.1 #635

limond opened this issue May 15, 2023 · 5 comments
Assignees
Labels
kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed

Comments

@limond
Copy link
Contributor

limond commented May 15, 2023

What happened?

Hello,

I am trying to connect to a remote docker daemon through SSH. Based on the error I get and the Issue #580 I assumed this is not implemented yet.

However, after some digging, I found that there is a problem with using certain symbols in the host property of the ProviderArgs since 4.0.1.

The following typescript example works for the docker provider in 4.0.0:

const provider = new docker.Provider("provider", {
  host: "ssh://limond@localhost:22",
});

const exampleNginx = new docker.Container("example-nginx", {
  image: "nginx:latest",
  ports: [{
    internal: 80,
    external: 80,
  }],
}, { provider });

However, in 4.0.1 up to the latest release this produces the following error on my debian machine:

docker:index:Container (example-nginx):
    error: 1 error occurred:
        * Error pinging Docker server: Error response from daemon: 400 Bad Request: malformed Host header

The reason behind this error is the change in 0b2969f. The patch for the smarter host resolution ignores the dummy header coming from the ConnectionHelper and seemingly uses limond@localhost:22 as the Host header.

The following code works as there is no @ in the host property in the latest version too:

import * as pulumi from "@pulumi/pulumi";
import * as docker from "@pulumi/docker";

const provider = new docker.Provider("provider", {
  host: "ssh://localhost",
  sshOpts: ["-l", "limond", "-p", "22"],
});

const exampleNginx = new docker.Container("example-nginx", {
  image: "nginx:latest",
  ports: [{
    internal: 80,
    external: 80,
  }],
}, { provider });

Expected Behavior

I think, using a host like host: ssh://limond@localhost:22 should connect to a remote docker daemon just like DOCKER_HOST=ssh://limond@localhost:22 does with the docker cli.

Steps to reproduce

  1. Clone the gist containing the code from above git clone https://gist.github.com/61930b03929d469cb7fff39eb89f1471.git
  2. Install: npm install
  3. pulumi up

The code assumes a running docker daemon and sshd on port 22 as well as a$USER env variable.

Output of pulumi about

CLI
Version 3.67.0
Go Version go1.20.4
Go Compiler gc

Plugins
NAME VERSION
docker 4.2.0
nodejs unknown

Host
OS debian
Version 12.0
Arch x86_64

This project is written in nodejs: executable='/home/limond/.nvm/versions/node/v16.17.1/bin/node' version='v16.17.1'

Current Stack: test

Found no resources associated with test

Found no pending operations associated with test

Backend
Name mainPC
URL file://~
User limond
Organizations

Dependencies:
NAME VERSION
@pulumi/docker 4.2.0
@pulumi/pulumi 3.67.0
@types/node 16.18.30

Pulumi locates its logs in /tmp by default

Additional context

As I wrote above, there is a workaround using the sshOpts property. Still I think it would be a good idea to restore the behavior of 4.0.0 as others will most likely also assume ssh://<user>@<domain> to work as the host property.

I think #580 is a result of this regression but I was not entirely sure and since the thread in this issue goes more into the arm64 direction I decided to open a new issue.

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@limond limond added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels May 15, 2023
@limond
Copy link
Contributor Author

limond commented May 15, 2023

I made a suggestion for a fix: #637

@t0yv0 t0yv0 removed the needs-triage Needs attention from the triage team label May 16, 2023
@t0yv0
Copy link
Member

t0yv0 commented May 16, 2023

Thank you for the PR!

@guineveresaenger guineveresaenger self-assigned this May 16, 2023
@limond
Copy link
Contributor Author

limond commented May 16, 2023

Thank you for reviewing and merging my PR so swiftly, love pulumi 😃
I will close this issue. ... Or I thought so.

@limond limond closed this as completed May 16, 2023
@pulumi-bot pulumi-bot reopened this May 16, 2023
@pulumi-bot
Copy link
Contributor

Cannot close issue without required labels: resolution/

@guineveresaenger guineveresaenger added the resolution/fixed This issue was fixed label May 22, 2023
@guineveresaenger
Copy link
Contributor

thank YOU for contributing!
Adding the labels to satisfy our bot...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Projects
None yet
Development

No branches or pull requests

4 participants