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

ws: conditional start of ssh-agent #21202

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

engelant
Copy link

Fixes #21170

In unprivileged mode the label-run script should respect an already existing set SSH_AUTH_SOCK env.
Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This also needs an integration test, but I'm happy to create that - unless you want to, of course!

@@ -119,6 +119,10 @@ You can also mount encrypted private keys inside the container. You can set an e

Private keys can be encrypted; then cockpit uses the provided password to decrypt the key.

### SSH_AUTH_SOCK
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this belongs into the previous "SSH auth" section.

@@ -119,6 +119,10 @@ You can also mount encrypted private keys inside the container. You can set an e

Private keys can be encrypted; then cockpit uses the provided password to decrypt the key.

### SSH_AUTH_SOCK

By default the container starts its own ssh-agent. Alternatively `SSH_AUTH_SOCK` environment variable can be set to surpress starting ssh-agent.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"surpress" typo, and I think it would be better to describe a "positive" use case:

Suggested change
By default the container starts its own ssh-agent. Alternatively `SSH_AUTH_SOCK` environment variable can be set to surpress starting ssh-agent.
By default the container starts its own ssh-agent. Alternatively you can pass an `SSH_AUTH_SOCK` environment variable and a corresponding socket volume to the container to re-use your host's socket.

and perhaps give an example? Does this work?

-v $SSH_AUTH_SOCK:/ssh.sock -e SSH_AUTH_SOCK=/ssh.sock

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might under a non SElinux system, for now I'm just running it as --privileged.

Otherwise, yeah, that works.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, perhaps with -v $SSH_AUTH_SOCK:/ssh.sock:Z then?

@@ -42,8 +42,10 @@ else

/usr/libexec/cockpit-certificate-ensure

if [ -z "$SSH_AUTH_SOCK" ]; then
if [ -z ${SSH_AUTH_SOCK+x} ]; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please write that in standard shell syntax and with quotes: [ -z "${SSH_AUTH_SOCK:-}" ]

Comment on lines +47 to +48
else
echo Agent sock ${SSH_AUTH_SOCK}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Debugging leftover, please drop.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I put that in on purpose, as the previous output was Agent pid N .
But sure, can remove.

Copy link
Member

@martinpitt martinpitt Nov 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant, it's not really useful, as the user explicitly specified the path -- there's no surprise? And that path is only valid inside the container.

@martinpitt martinpitt changed the title Ws container auth socket ws: conditional start of ssh-agent Nov 15, 2024
@martinpitt
Copy link
Member

@engelant Do you still want to continue with this? No pressure, we all have other work to do, I was just curious if you lost interest or just don't have time. I.e. I can finish this at some point too, just don't want to step on your toes.

@engelant
Copy link
Author

@martinpitt terribly sorry for the long response time, but yeah stuff...

Anyhow, as for the selinux part,, :z is propably insufficent, as this only affects the mount ns and not the ipc one afaik.
Imho this useage example is kind of out of scope, or I would just go with the --privileged for now.

Further more the integration tests, I'm not sure what's required there.
So if you want to drag this over the finish line here I'd very much welcome that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

cockpit-ws bastion/unprivilleged forced ssh-agent
2 participants