authenticating password for commands #16195
-
Hey, I'm building out a custom page in cockpit that runs a script on the system. The problem is I'm using scp in that script to pull custom files stored on a remote server and I cant figure out how to have our system prompt the user for their password or be able to use the cockpit bridge to pass a few files. What is the best way to accomplish this? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
That is indeed a bit tricky -- the cockpit.file() API (like the general cockpit.channel() one does support a But you mentioned that you need to prompt for a password, so supposedly you don't have an SSH key setup. Is it an option for you to use that instead of passwords? If not, then we could look into extending the API to pass a password to the channel options, but this is always a dangerous proposition: The password would be stored in clear in JavaScript's memory, and also go over the wire to cockpit-bridge and cockpit-ssh, so there is plenty of opportunity to leak it somewhere. Or perhaps you have the option to use something else than scp, e.g. HTTP with basic auth, or without any auth and firewalling to restrict your server to the internal network? |
Beta Was this translation helpful? Give feedback.
-
It's reasonable to just have a normal dialog that asks for the password and to pass it to your script in some way, preferrably over stdin. |
Beta Was this translation helpful? Give feedback.
That is indeed a bit tricky -- the cockpit.file() API (like the general cockpit.channel() one does support a
host
option. This works great if you already have a trust relation to the target, i.e. SSH knows the target's host key and can use an established public/private key pair. In other words, ifssh user@host
works, then you can use cockpit.file's{ host: "user@host" }
option.But you mentioned that you need to prompt for a password, so supposedly you don't have an SSH key setup. Is it an option for you to use that instead of passwords? If not, then we could look into extending the API to pass a password to the channel options, but this is always a dangerous proposition: The password wo…