Gathering ssh config connection issues #601

New Issue

moritz · 2024-04-01T08:44:50Z

moritz commented

2024-04-01 08:44:50 +00:00

First of all, why does abra even gather connection details from the ssh config? It uses ssh -G to parse the ssh config and reads the following connection details: hostname, user, port and IdentityFile.
I came across a bug, because a user of one server was called user. And if you look at this line d5ac3958a4/pkg/ssh/ssh.go (L49) it leads to crash abra with an index out of range Error.

The next issue I came across is that I can only access my server using the ProxyCommand parameter. So at the moment I can not use abra deploy anything on my server.

Therefore I wonder if it's not possible to let abra be completely independent of the ssh config connection details. And use ssh with the user config instead of extracting specific connection details and reusing them. I think every custom ssh config can introduce some more issues if we try to extract all necessary connection details, instead of relying on the whole ssh config.

First of all, why does abra even gather connection details from the ssh config? It uses `ssh -G` to parse the ssh config and reads the following connection details: `hostname`, `user`, `port` and `IdentityFile`. I came across a bug, because a user of one server was called `user`. And if you look at this line https://git.coopcloud.tech/coop-cloud/abra/src/commit/d5ac3958a4543ca7ee94f5c39bf2147d4a8089c4/pkg/ssh/ssh.go#L49 it leads to crash abra with an `index out of range` Error. The next issue I came across is that I can only access my server using the `ProxyCommand` parameter. So at the moment I can not use abra deploy anything on my server. Therefore I wonder if it's not possible to let abra be completely independent of the ssh config connection details. And use ssh with the user config instead of extracting specific connection details and reusing them. I think every custom ssh config can introduce some more issues if we try to extract all necessary connection details, instead of relying on the whole ssh config.

👍 1

moritz added the

bug

label 2024-04-01 08:44:50 +00:00

decentral1se added the

abra

label 2024-04-01 11:30:36 +00:00

decentral1se commented

2024-04-01 11:40:28 +00:00

@moritz AFAIR the ssh -G ... trick is to gather connection details to make abra server add ... gather the correct details. If we didn't do this, we'd need to add a series of flags to abra server add which supported feeding these details in? E.g. --username, --port, etc.

Checking the code again, I see we are invoking /usr/bin/ssh with some flags:

DEBU[0000] commandconn: starting ssh with [-o ConnectTimeout=60 -l <user> -p <port> -- <domain> docker system dial-stdio] caller="/drone/src/pkg/upstream/commandconn/commandconn.go:49 New"

In this case, <user>, <port> and <domain> is parsed from the Docker context, not the SSH configuration. You can verify by running docker context ls to see the connection details contained in a list based on what abra server add fed in from ssh -G ....

So, IIUC, you're proposing to drop all flags on the /usr/bin/ssh invocation? And then we potentially use flags on abra server add ... to feed in username, port and hostname?

Something in this direction would be good because our tight coupling / re-working of SSH led to endless bugs and de-coupling has been better for us. This could help further. Could this also solve coop-cloud/organising#482?

@moritz AFAIR the `ssh -G ...` trick is to gather connection details to make `abra server add ...` gather the correct details. If we didn't do this, we'd need to add a series of flags to `abra server add` which supported feeding these details in? E.g. `--username`, `--port`, etc. Checking the code again, I see we are invoking `/usr/bin/ssh` with some flags: `DEBU[0000] commandconn: starting ssh with [-o ConnectTimeout=60 -l <user> -p <port> -- <domain> docker system dial-stdio] caller="/drone/src/pkg/upstream/commandconn/commandconn.go:49 New"` In this case, `<user>`, `<port>` and `<domain>` is parsed from the Docker context, *not* the SSH configuration. You can verify by running `docker context ls` to see the connection details contained in a list based on what `abra server add` fed in from `ssh -G ...`. So, IIUC, you're proposing to drop all flags on the `/usr/bin/ssh` invocation? And then we potentially use flags on `abra server add ...` to feed in `username`, `port` and `hostname`? Something in this direction would be good because our tight coupling / re-working of SSH led to endless bugs and de-coupling has been better for us. This could help further. Could this also solve https://git.coopcloud.tech/coop-cloud/organising/issues/482?

moritz commented

2024-04-03 07:15:03 +00:00

Ok maybe my question was the wrong one. Why does abra need these details, when are they part of the ssh config?
If you connect to a host with ssh you also don't need to specify all these flags, if you have them in your ssh config.
Why not leave and been handled by ssh?
Does docker context need these details?
From what I see in DEBU[0000] commandconn: starting ssh with [-o ConnectTimeout=60 -l <user> -p <port> -- <domain> docker system dial-stdio] caller="/drone/src/pkg/upstream/commandconn/commandconn.go:49 New" couldn't the ssh command use the ssh config instead of -l <user> -p <port> ?

Ok maybe my question was the wrong one. Why does abra need these details, when are they part of the ssh config? If you connect to a host with ssh you also don't need to specify all these flags, if you have them in your ssh config. Why not leave <user> and <port> been handled by ssh? Does docker context need these details? From what I see in `DEBU[0000] commandconn: starting ssh with [-o ConnectTimeout=60 -l <user> -p <port> -- <domain> docker system dial-stdio] caller="/drone/src/pkg/upstream/commandconn/commandconn.go:49 New"` couldn't the ssh command use the ssh config instead of `-l <user> -p <port>` ?

decentral1se commented

2024-04-04 08:49:55 +00:00

@moritz there are two needs here 1. abra server add 2. "general ssh connectivity"

For 2. I think yes, let's try to drop all options and rely on the .ssh/config, to be tested.

For 1. this is what abra server add runs under the hood: docker context create --docker host=ssh://<user>@<host>:<port> <host> and for that, we need those details. I don't know how to get them other than parsing ssh -G ... or passing them as CLI flags. Ideas?

@moritz there are two needs here 1. `abra server add` 2. "general ssh connectivity" For 2. I think yes, let's try to drop all options and rely on the `.ssh/config`, to be tested. For 1. this is what `abra server add` runs under the hood: `docker context create --docker host=ssh://<user>@<host>:<port> <host>` and for that, we need those details. I don't know how to get them other than parsing `ssh -G ...` or passing them as CLI flags. Ideas?

3wordchant commented

2024-04-04 18:26:15 +00:00

The next issue I came across is that I can only access my server using the ProxyCommand parameter. So at the moment I can not use abra deploy anything on my server.

@moritz can Docker connect to this server which requires ProxyCommand?

docker context create <name> --docker "host=ssh://<user>@<host>:<port>"
DOCKER_CONTEXT=<name> docker ps

> The next issue I came across is that I can only access my server using the `ProxyCommand` parameter. So at the moment I can not use abra deploy anything on my server. @moritz can Docker connect to this server which requires `ProxyCommand`? ``` docker context create <name> --docker "host=ssh://<user>@<host>:<port>" DOCKER_CONTEXT=<name> docker ps ```

moritz commented

2024-04-10 11:12:30 +00:00

@moritz can Docker connect to this server which requires ProxyCommand?
docker context create <name> --docker "host=ssh://<user>@<host>:<port>"
DOCKER_CONTEXT=<name> docker ps

Yes it works also docker doesn't need all these details.

I just run:
docker context create myhostname --docker 'host=ssh://myhostname'
And I configured myhostname inside the ~/.ssh/config with ProxyCommand, a username and a different port and docker is able to connect.
I think abra doesn't need to handle any connection details other than the hostname.

> @moritz can Docker connect to this server which requires `ProxyCommand`? > > ``` > docker context create <name> --docker "host=ssh://<user>@<host>:<port>" > DOCKER_CONTEXT=<name> docker ps > ``` Yes it works also docker doesn't need all these details. I just run: `docker context create myhostname --docker 'host=ssh://myhostname'` And I configured `myhostname` inside the `~/.ssh/config` with `ProxyCommand`, a username and a different port and docker is able to connect. I think abra doesn't need to handle any connection details other than the hostname.

👍 1

3wordchant commented

2024-04-10 12:57:47 +00:00

moritz there are two needs here 1. abra server add 2. "general ssh connectivity"

For 2. I think yes, let's try to drop all options and rely on the .ssh/config, to be tested.

@decentral1se sounds like we can drop all options in both cases? 🤞

> moritz there are two needs here 1. abra server add 2. "general ssh connectivity" > > For 2. I think yes, let's try to drop all options and rely on the .ssh/config, to be tested. @decentral1se sounds like we can drop all options in both cases? 🤞

decentral1se commented

2024-04-11 06:56:07 +00:00

Oh dear dog, I've played us for absolute fools 😆 Will try rip it all out folks, thanks!

EDIT: trying to drum up some budget for this 🤑

Oh dear dog, I've played us for absolute fools 😆 Will try rip it all out folks, thanks! EDIT: trying to drum up some budget for this 🤑

~~decentral1se referenced this issue 2024-06-20 07:04:58 +00:00~~

`abra` v0.10.x-beta release planning #583

decentral1se referenced this issue from a commit

2024-06-20 07:20:03 +00:00

refactor!: drop all SSH opts / config handling

decentral1se referenced this issue from toolshed/abra

2024-06-20 07:23:39 +00:00