Command Line support #55

Author

Owner

@Midnex commented on GitHub (Oct 5, 2021):

Glad to see this reopened.

@Midnex commented on GitHub (Oct 5, 2021): Glad to see this reopened.

deekerman commented

Author

Owner

@rustdesk commented on GitHub (Oct 5, 2021):

Because someone mentioned this on discord, and I have been investigating on AnyDesk/TeamViewer/Parsec API lately.

@rustdesk commented on GitHub (Oct 5, 2021): Because someone mentioned this on discord, and I have been investigating on AnyDesk/TeamViewer/Parsec API lately.

deekerman commented

Author

Owner

@radiobut commented on GitHub (Jul 27, 2022):

It would be very nice to be able to start a connection from the command line. For example, to integrate with other remote connection management tools.

@radiobut commented on GitHub (Jul 27, 2022): It would be very nice to be able to start a connection from the command line. For example, to integrate with other remote connection management tools.

deekerman commented

Author

Owner

@bilogic commented on GitHub (Jul 29, 2022):

Teamviewer https://community.teamviewer.com/English/kb/articles/34447-command-line-parameters

I normally use teamviewer.exe -i <id>, and it prompts for password, very useful if there are many machines to manage.

@bilogic commented on GitHub (Jul 29, 2022): Teamviewer https://community.teamviewer.com/English/kb/articles/34447-command-line-parameters I normally use `teamviewer.exe -i <id>`, and it prompts for password, very useful if there are many machines to manage.

deekerman commented

Author

Owner

@rustdesk commented on GitHub (Jul 29, 2022):

--connect <id>

@rustdesk commented on GitHub (Jul 29, 2022): `--connect <id>`

deekerman commented

Author

Owner

@bilogic commented on GitHub (Jul 29, 2022):

--connect <id>

wow thanks! is it documented anywhere?

@bilogic commented on GitHub (Jul 29, 2022): > `--connect <id>` wow thanks! is it documented anywhere?

deekerman commented

Author

Owner

@Shahin-rmz commented on GitHub (Aug 2, 2022):

Hello,
A power user (not a dev) here.
First:
Rustdesk is WAY better than Anydesk or Teamviewer.
I have installed it on my parent's Raspberry pi.
and can control the Raspberry remotely and play Movie for them.
Thanks <3

Now a question:

Can I connect via SSH and generate a password, (or see the password) and then connect via client to the Raustdesk?

Thanks

@Shahin-rmz commented on GitHub (Aug 2, 2022): Hello, A power user (not a dev) here. First: Rustdesk is WAY better than Anydesk or Teamviewer. I have installed it on my parent's Raspberry pi. and can control the Raspberry remotely and play Movie for them. Thanks <3 ### Now a question: _________________________________________________________________ Can I connect via SSH and generate a password, (or see the password) and then connect via client to the Raustdesk? _____________________________________________________________________________ Thanks

deekerman commented

Author

Owner

@bilogic commented on GitHub (Aug 3, 2022):

Can I connect via SSH and generate a password, (or see the password) and then connect via client to the Raustdesk?

Are you suggesting this is more secured than having a static complex password on rustdesk?

Frankly, I think it takes the same flow and effort to steal your static complex password vs your SSH password/key.

@bilogic commented on GitHub (Aug 3, 2022): > Can I connect via SSH and generate a password, (or see the password) and then connect via client to the Raustdesk? Are you suggesting this is more secured than having a static complex password on rustdesk? Frankly, I think it takes the same flow and effort to steal your static complex password vs your SSH password/key.

deekerman commented

Author

Owner

@Shahin-rmz commented on GitHub (Aug 3, 2022):

Frankly, I think it takes the same flow and effort to steal your static complex password vs your SSH password/key.

You are right.
Ultimately I like to:

have a dynamic password for every new connection every time but a static password for trusted connections.
Or other way around,
trusted connections make a pair of password each time.

@Shahin-rmz commented on GitHub (Aug 3, 2022): > Frankly, I think it takes the same flow and effort to steal your static complex password vs your SSH password/key. You are right. Ultimately I like to: - have a dynamic password for **every new connection every time** but a static password for trusted connections. Or other way around, - trusted connections make a pair of password each time.

deekerman commented

Author

Owner

@bilogic commented on GitHub (Aug 3, 2022):

Haha, we are going in circles: how do you determine if a connection is a trusted one?

Teamviewer does it by having 2 passwords, a dynamic one and static one, either one will allow you to login.

The closest I can think of is to have the dynamic password regenerate after each disconnection, but the static remains and is available to all connections, just make sure to keep it complex.

@bilogic commented on GitHub (Aug 3, 2022): Haha, we are going in circles: how do you determine if a connection is a trusted one? Teamviewer does it by having 2 passwords, a dynamic one and static one, either one will allow you to login. The closest I can think of is to have the dynamic password regenerate after each disconnection, but the static remains and is available to all connections, just make sure to keep it complex.

deekerman commented

Author

Owner

@Shahin-rmz commented on GitHub (Aug 4, 2022):

Haha, we are going in circles: how do you determine if a connection is a trusted one?

You are right. :) I am thinking that if both parties check the trusted box, then we the connections are trusted.

The closest I can think of is to have the dynamic password regenerate after each disconnection, but the static remains and is available to all connections, just make sure to keep it complex.

This is one good approach, the other one is to have static password just for some connections and not global.

@Shahin-rmz commented on GitHub (Aug 4, 2022): > Haha, we are going in circles: how do you determine if a connection is a trusted one? You are right. :) I am thinking that if both parties *check the trusted box*, then we the connections are *trusted*. > The closest I can think of is to have the dynamic password regenerate after each disconnection, but the static remains and is available to all connections, just make sure to keep it complex. This is one good approach, the other one is to have static password just for some connections and **not global**.

deekerman commented

Author

Owner

@paulbdavis commented on GitHub (Aug 18, 2022):

Jumping in this issue to say it would be good to be able to get the current ID and password via the command line.

The use case is having a machine that's out in the field where there is not someone present to read off the ID and password or interact with the UI component (the UI would not even be launched). It would be good to dump these out on the command line when connected to said machine via SSH

like:

$ rustdesk --info

ID: 123 123 123
Password: abcdef

@paulbdavis commented on GitHub (Aug 18, 2022): Jumping in this issue to say it would be good to be able to get the current ID and password via the command line. The use case is having a machine that's out in the field where there is not someone present to read off the ID and password or interact with the UI component (the UI would not even be launched). It would be good to dump these out on the command line when connected to said machine via SSH like: ``` $ rustdesk --info ID: 123 123 123 Password: abcdef ```

deekerman commented

Author

Owner

@paspo commented on GitHub (Aug 18, 2022):

you can read ID and password from the config files:

C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\RustDesk\config\RustDesk.toml (windows)
/root/.config/rustdesk/RustDesk.toml (linux)
/Library/Preferences/com.carriez.RustDesk/RustDesk.toml (OSX)

(password can be salted)

@paspo commented on GitHub (Aug 18, 2022): you can read ID and password from the config files: - C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\RustDesk\config\RustDesk.toml (windows) - /root/.config/rustdesk/RustDesk.toml (linux) - /Library/Preferences/com.carriez.RustDesk/RustDesk.toml (OSX) (password can be salted)

deekerman commented

Author

Owner

@rustdesk commented on GitHub (Aug 18, 2022):

will be encrypted in next release

@rustdesk commented on GitHub (Aug 18, 2022): will be encrypted in next release

deekerman commented

Author

Owner

@bilogic commented on GitHub (Aug 18, 2022):

Jumping in this issue to say it would be good to be able to get the current ID and password via the command line.

I think it is generally not safe to expose the ID and password via an "API" approach. Anything else can also call the "API" and gain access. Getting a dynamic password via "API" using SSH is equivalent to setting a static password (SSH being the static in this case).

It is probably best to just let Rust Desk do its best to protect the static password instead of making it leak credentials via an "API".

@bilogic commented on GitHub (Aug 18, 2022): > Jumping in this issue to say it would be good to be able to get the current ID and password via the command line. I think it is generally not safe to expose the ID and password via an "API" approach. Anything else can also call the "API" and gain access. Getting a dynamic password via "API" using SSH is equivalent to setting a static password (SSH being the static in this case). It is probably best to just let Rust Desk do its best to protect the static password instead of making it leak credentials via an "API".

deekerman commented

Author

Owner

@paulbdavis commented on GitHub (Aug 22, 2022):

For the password, sure, I suppose that makes sense, but getting the ID and being able to set the password would be enough really.

Having it disabled by default would obviously be best as well, but there should be a way to get/set the credentials for a remote machine without anyone actually being present.

@paulbdavis commented on GitHub (Aug 22, 2022): For the password, sure, I suppose that makes sense, but getting the ID and being able to *set* the password would be enough really. Having it disabled by default would obviously be best as well, but there should be a way to get/set the credentials for a remote machine without anyone actually being present.

deekerman commented

Author

Owner

@bilogic commented on GitHub (Aug 22, 2022):

Having it disabled by default would obviously be best as well, but there should be a way to get/set the credentials for a remote machine without anyone actually being present.

In that case, I think it is better to state the problem ("How to perform unattended remote installation") instead of suggesting the solution.

In one of the VPS that I use, they ask for my SSH public key when provisioning the server. i.e. unattended installs must have a static password, but please don't quote me on that, authentication/credential modifications must always be rigorously thought out.

@bilogic commented on GitHub (Aug 22, 2022): > Having it disabled by default would obviously be best as well, but there should be a way to get/set the credentials for a remote machine without anyone actually being present. In that case, I think it is better to state the problem ("How to perform unattended remote installation") instead of suggesting the solution. In one of the VPS that I use, they ask for my SSH public key when provisioning the server. i.e. unattended installs must have a static password, but please don't quote me on that, authentication/credential modifications must always be rigorously thought out.

deekerman commented

Author

Owner

@jcelerier commented on GitHub (Sep 28, 2022):

In that case, I think it is better to state the problem ("How to perform unattended remote installation") instead of suggesting the solution.

what's the solution to this problem? how can I get a remote desktop remotely from a machine which has nothing installed and to which I have a ssh access ?

@jcelerier commented on GitHub (Sep 28, 2022): > In that case, I think it is better to state the problem ("How to perform unattended remote installation") instead of suggesting the solution. what's the solution to this problem? how can I get a remote desktop remotely from a machine which has nothing installed and to which I have a ssh access ?

deekerman commented

Author

Owner

@paulbdavis commented on GitHub (Oct 11, 2022):

Sure, for the password that is fine, I can just set it manually, but what about getting the ID? Will that also be encrypted on the next release?

On Aug 18, 2022, at 7:14 PM, bilogic @.***> wrote:

Jumping in this issue to say it would be good to be able to get the current ID and password via the command line.

I think it is generally not safe to expose the ID and password via an "API" approach. Anything else can also call the "API" and gain access. Getting a dynamic password via "API" using SSH is equivalent to setting a static password (SSH being the static in this case).

It is probably best to just let Rust Desk do its best to protect the static password instead of making it leak credentials via an "API".

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

@paulbdavis commented on GitHub (Oct 11, 2022): Sure, for the password that is fine, I can just set it manually, but what about getting the ID? Will that also be encrypted on the next release? > On Aug 18, 2022, at 7:14 PM, bilogic ***@***.***> wrote: > > > Jumping in this issue to say it would be good to be able to get the current ID and password via the command line. > > I think it is generally not safe to expose the ID and password via an "API" approach. Anything else can also call the "API" and gain access. Getting a dynamic password via "API" using SSH is equivalent to setting a static password (SSH being the static in this case). > > It is probably best to just let Rust Desk do its best to protect the static password instead of making it leak credentials via an "API". > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you commented.

deekerman commented

Author

Owner

@rustdesk commented on GitHub (Oct 11, 2022):

Yes， enced in next release.

@rustdesk commented on GitHub (Oct 11, 2022): Yes， enced in next release.

deekerman commented

Author

Owner

@ssteeltm commented on GitHub (Oct 13, 2022):

would be nice if I could connect via CMD with:
rustdesk.exe --connect <ID> --password <password>

@ssteeltm commented on GitHub (Oct 13, 2022): would be nice if I could connect via CMD with: `` rustdesk.exe --connect <ID> --password <password> ``

deekerman commented

Author

Owner

@bilogic commented on GitHub (Oct 14, 2022):

--connect <id>, use rustdesk to remember the password

@bilogic commented on GitHub (Oct 14, 2022): `--connect <id>`, use rustdesk to remember the password

deekerman commented

Author

Owner

@Onyx47 commented on GitHub (Oct 22, 2022):

Lack of an option to retrieve the ID programmatically, possibly from a file or as a command-line option that can only be read/ran as root/elevated user is what's currently stopping me from replacing AnyDesk with RustDesk for my use case.

Having the ID recorded somewhere where it's only accessible to root/admin does not strike me as a huge security risk (AnyDesk does this as well, as an aside), and enables easier automation for cases where you already have some kind of elevated access available to you and you just need that extra step of being able to access the GUI.

Also, just to point out, when starting RustDesk from terminal on Linux, it still spits out the ID to stdout, so it's technically still possible to grab the ID programatically, but this is not something I'd rely on, plus it's inconsistent - it's encrypted in a file but it's readable by a regular user if they can just execute a command as an unprivileged user.

@Onyx47 commented on GitHub (Oct 22, 2022): Lack of an option to retrieve the ID programmatically, possibly from a file or as a command-line option that can only be read/ran as root/elevated user is what's currently stopping me from replacing AnyDesk with RustDesk for my use case. Having the ID recorded somewhere where it's only accessible to root/admin does not strike me as a huge security risk (AnyDesk does this as well, as an aside), and enables easier automation for cases where you already have some kind of elevated access available to you and you just need that extra step of being able to access the GUI. Also, just to point out, when starting RustDesk from terminal on Linux, it still spits out the ID to `stdout`, so it's technically still possible to grab the ID programatically, but this is not something I'd rely on, plus it's inconsistent - it's encrypted in a file but it's readable by a regular user if they can just execute a command as an unprivileged user.

deekerman commented

Author

Owner

@mikelwellsmore commented on GitHub (Nov 15, 2022):

Agreed - we need a way to programmatically retrieve or set the ID (as it looks like the password can be set via rustdesk.exe --password)

@mikelwellsmore commented on GitHub (Nov 15, 2022): Agreed - we need a way to programmatically retrieve or set the ID (as it looks like the password can be set via `rustdesk.exe --password`)

deekerman commented

Author

Owner

@kapytanhook commented on GitHub (Nov 26, 2022):

we need to be able to set or read the ID or there is no point to this software, going to have to make my own build just to do that now.

@kapytanhook commented on GitHub (Nov 26, 2022): we need to be able to set or read the ID or there is no point to this software, going to have to make my own build just to do that now.

deekerman commented

Author

Owner

@Onyx47 commented on GitHub (Dec 9, 2022):

For anyone needing this functionality and is willing to build their own release, this is my current solution until there is a more definite decision on this: github.com/Onyx47/rustdesk@ed9e92fc2e

It enables you to run rustdesk --id as admin/root and simply prints out the ID and quits. Certainly not sophisticated but it should do for scripting purposes. Only tested on Linux but I'd assume Windows should be fine as well, it's using the same logic as --password argument.

@Onyx47 commented on GitHub (Dec 9, 2022): For anyone needing this functionality and is willing to build their own release, this is my current solution until there is a more definite decision on this: https://github.com/Onyx47/rustdesk/commit/ed9e92fc2e46fb3272cb4d694802ac8915a45ba7 It enables you to run `rustdesk --id` as admin/root and simply prints out the ID and quits. Certainly not sophisticated but it should do for scripting purposes. Only tested on Linux but I'd assume Windows should be fine as well, it's using the same logic as `--password` argument.

deekerman commented

Author

Owner

@knro commented on GitHub (Jan 18, 2023):

It would be nice to be able to set/get ID as root. Any ideas if this will ever be merged in Rustdesk or we'd have to rollout our own releases?

@knro commented on GitHub (Jan 18, 2023): It would be nice to be able to set/get ID as root. Any ideas if this will ever be merged in Rustdesk or we'd have to rollout our own releases?

deekerman commented

Author

Owner

@merlink01 commented on GitHub (Jan 23, 2023):

For autologin the way anydesk does it is nice:
Load the password from stdin.

So the command is:
rustdesk.exe --connect <ID> --password
and after this:
send the password via stdin to the process followed by a \n.

On this way the password is not visible on the process list.

@merlink01 commented on GitHub (Jan 23, 2023): For autologin the way anydesk does it is nice: Load the password from stdin. So the command is: `rustdesk.exe --connect <ID> --password` and after this: send the password via stdin to the process followed by a \n. On this way the password is not visible on the process list.

deekerman commented

Author

Owner

@knro commented on GitHub (Feb 14, 2023):

Jumping in this issue to say it would be good to be able to get the current ID and password via the command line.

The use case is having a machine that's out in the field where there is not someone present to read off the ID and password or interact with the UI component (the UI would not even be launched). It would be good to dump these out on the command line when connected to said machine via SSH

like:
$ rustdesk --info

ID: 123 123 123
Password: abcdef

This is exactly our use case. We need to a use to programatically retrieve the ID. We can set password it's sad to see no way to get ID for field deployments. It's OK if this action is only limited to root, that's not the issue. @rustdesk When can we expect this important feature to be implemented? github.com/Onyx47/rustdesk@ed9e92fc2e seems like a good solution.

@knro commented on GitHub (Feb 14, 2023): > Jumping in this issue to say it would be good to be able to get the current ID and password via the command line. > > The use case is having a machine that's out in the field where there is not someone present to read off the ID and password or interact with the UI component (the UI would not even be launched). It would be good to dump these out on the command line when connected to said machine via SSH > > like: > > ``` > $ rustdesk --info > > ID: 123 123 123 > Password: abcdef > ``` This is exactly our use case. We need to a use to programatically retrieve the ID. We can set password it's sad to see no way to get ID for field deployments. It's OK if this action is only limited to root, that's not the issue. @rustdesk When can we expect this important feature to be implemented? https://github.com/Onyx47/rustdesk/commit/ed9e92fc2e46fb3272cb4d694802ac8915a45ba7 seems like a good solution.

deekerman commented