Seamless-cockpit and Foreman

Development
21

The second option is interesting. What would end/close such job? The third seems most natural but requires extra infra to setup and maintain. The first is probably most straightforward, but wouldn’t it have to ignore target host key verification? Ssh known hosts check would fail I guess after first connection.

22

Thanks for the feedback, that helps a lot. Please keep it coming. :slight_smile:

The client closing the TCP connection would end the job, the same as pressing C-d closes a regular SSH session.

I start to like this option most since it fits best into the existing Foreman architecture, no? No new communication patterns between master and proxies, no new ports need to be opened, etc.

But this option also needs the biggest code changes to both Foreman and Cockpit. I’ll play around with this a bit to get a feel for how big.

23

Okay, this starts to look promising.

Here is a demo, with terrible sound (apologies):

The central piece for the Cockpit session is cockpit-auth-foreman: https://github.com/mvollmer/foreman-cockpit/blob/master/cockpit-auth-foreman

It uses the new /api/v2/remote_execution/ssh_params API of Foreman to get parameters like proxy, user, keyfile, password, etc, that are also used by REX.

It then uses the new /remote_execution/ssh_session API in the Smart Proxy to start a interactive SSH session on the target host that runs cockpit-bridge. Once running, it will pump the Cockpit protocol messages in both directions until the session ends. That API does a protocol upgrade on its connection, which is something new for Smart Proxy, I think.

Code for the /api/v2/remote_execution/ssh_params API: https://github.com/mvollmer/foreman_remote_execution/commit/d35647905b19b23b76bbdd2f25c96fbbdff5a62e

Code for the /remote_execution/ssh_session API: https://github.com/mvollmer/smart-proxy/commit/5f0ded7db4049a7c08877f3c86f9137b8c7ad21d

Super dirty code for the button in Foreman and the OAuth bits: https://github.com/mvollmer/foreman/commits/seamless-cockpit

Open issues:

  • I should rewrite cockpit-auth-foreman in Ruby.

  • This doesn’t work without a proxy, but I think it should. A Ruby version of cockpit-auth-foreman can probably quite easily use Net::SSH directly on that case, and we should factor the code to make that elegant.

  • The ssh_session API needs to be implemented by smart_proxy_remote_execution_ssh, not by smart-proxy.

  • The code that uses Net::SSH should share as much as possible with script_runner.rb in foreman_remote_execution

But overall, I am pretty happy with this. Next steps for me would be

  • Rewrite cockpit-auth-foreman in Ruby.

  • Figure out how Foreman runs behind Apache in production and put Cockpit behind it as well.

  • Make a PR for the ssh_params API, with tests and everything.

2 Likes
24

Nice to see the progress here! So if I understand the workflow properly, when I click the Web Console,

  1. it goes first to the Cockpit
  2. user gets redirected back to the Foreman to confirm the OAuth2 access
  3. then Foreman redirects back to Cockpit: at this point Cockpit trusts the user
  4. Cockpit asks the Foreman for the connection details
  5. Cockpit starts the session on the proxy to connect to the remote host
  6. profit

It that right?

If I understand it correctly, in point 4, Cockpit uses the same session id to authenticate to the Foreman, as user’s browser, right?

I’m just trying to rephrase this here to make sure I understand how the whole thing works, as there are multiple pieces in play.

25

Yes, except for the “trust” part.

Cockpit itself is unprivileged and doesn’t make decisions related to authentication. The credentials given out by Foreman in step 4 just need to be accepted by sshd in step 5. Foreman might decline access in step 4 based on which user the session is for, etc.

Yes, the Foreman API fortunately allows access with a valid _session_id cookie, and the token exchanged in steps 2 and 3 is the value of that cookie. cockpit-auth-foreman turns the token back into a cookie.

26

A customer asked for better integration in regard to PCP performance data from hosts. While we will unlikely be writing a Foreman PCP plugins to present data from PCP, we should be able to have a button for hosts that opens up Cockpit interface on Performance page. I see there are plans on elaborating Cockcpit-PCP integration: https://github.com/cockpit-project/cockpit/wiki/Feature:-PCP-Integration

27

Hi,

time for a status update.

Ivan has helped me greatly and we have made good progress towards getting the code into Foreman.

The current plan doesn’t require any changes to Foreman or the SmartProxy anymore; we can get it all done in the Remote Execution plugins.

We now have four pull requests:

There is also the code for running the special Cockpit instance that the “Web Console” button is supposed to link to: https://github.com/mvollmer/foreman-cockpit.

Putting it all together to make it actually work is still a bit tricky.

Next steps for me:

  • Look into adding tests to my PRs above
  • Move foreman-cockpit-session into foreman_remote_execution and turn the foreman-cockpit repo into mostly documentation for how to set it all up, including the Apache reverse proxy thing.
  • Learn how the Foreman installer works and how we could do the setup

Open issues:

  • Normally, connections to the SmartProxy are done via HTTPS with client certificates. The foreman-cockpit-session program needs to be able to do that.

  • If the only supported way to set this all up is to have Cockpit on the same origin as Foreman (via a Apache reverse proxy), can’t we then rely on getting the session cookie directly and do away with the OAuth complication? This might need changes to Cockpit itself…

Thanks!

1 Like
28

Three! We have three pull requests.

1 Like
29

Thanks, we only allow edits 5 minutes after for typos. People read via email a lot. Cheers.

30

Hi,

we have HTTPS between the Cockpit session helper and the Smart Proxy working now, but the details of where the session helper gets the certificates from are still open.

Documentation exists now and a couple of people have successfully run through them: https://github.com/mvollmer/foreman-cockpit/tree/master

Here is a demo with three machines, which also shows that error messages are getting better: https://www.youtube.com/watch?v=LVURfdfIuCs

2 Likes
31

from where i can change user , so instead of root it open cockpit with non root user ?

32

There is a setting in Administer - Settings.

33

thank you for the reply , I did but it still login with root when I click on web console (cockpit)

34

Is there any parameter for cockpit web console user name I can add in host

35

Hi, Firstly when I read it first time I understand you want to open the cockpit with different Foreman User. That is possible as lzap wrote, You will create new user with correct roles and you can open the cockpit.

But if I understand correctly you want to achieve something else:
With new_user you want to open cockpit and you want to differentiate also the cockpit users. Right now you are logged as root and you would expect to be logged as new_user right ?

Can you please explain why you need to this behavior, please ?
IMO when you create a new user and you give him enough roles to open cockpit
You are giving the new_user access, and now he can manipulate with host in cockpit. So in this point of view it doesn’t matter if he is logged as root inside the cockpit because you as admin already gave him a permission to manipulate with a machine.

I think this behavior is not implemented. I am not sure. @lzap hopefully knows the answer.

1 Like
36

I forgot to mention you @masadrasheed :wink: ^^

1 Like
37

As per my understanding cockpit login is nothing to do with foreman user , when you click on Webconsole it open new tab on browser and open cockpit with root as I already add foreman -proxy key in host authorise keys.

example:

ssh-copy-id -i ~foreman-proxy/ .ssh/id_rsa_foreman_proxy.pub root@centos7.xxxx.io

But I want to copy that key to

ssh-copy-id -i ~foreman-proxy/ .ssh/id_rsa_foreman_proxy.pub asad@centos7.xxxxx.io

And I want cockpit to open with asad user instead of root , doesn’t matter which foreman user try to access that host and click on web console.

39

before foreman and cockpit SSO , I mean initial versions you have to put username and password to login to cockpit to do certain operations.

40

But if I understand correctly you want to achieve something else:
With new_user you want to open cockpit and you want to differentiate also the cockpit users. Right now you are logged as root and you would expect to be logged as new_user right ?

I don’t want any new user in foreman, I just want existing foreman admin user open cockpit web console with non root user simple.

Can you please explain why you need to this behavior, please ?
IMO when you create a new user and you give him enough roles to open cockpit
You are giving the new_user access, and now he can manipulate with host in cockpit. So in this point of view it doesn’t matter if he is logged as root inside the cockpit because you as admin already gave him a permission to manipulate with a machine.

User is admin with full rights but foreman webconsole open cockpit only with root which I don’t want , I want cockpit should open with non root user.

I think this behavior is not implemented. I am not sure. @lzap hopefully knows the answer.

I think there is some simple parameter I can add in host parameters and It will work @lzap help me out bro.

41

Understand.
As far as I remember this is was not implemented and this will be RFE.
So everything is up to developers :slight_smile: .

2 Likes