Create Credentials for Users to use the auto-mc instance

[robinschweitz]

Reason for this Issue:

I'm thinking about using auto-mcs to automate the deployment of servers for my friends. At the moment I use ansible. It allows me to create the server on my hypervisor and setup a mc server. With auto-mcs im hoping to make it so that I create the vm and setup auto-mcs on that. This way, I can just give my friends the entire auto-mcs instance. I want it to be as easy for them to use. My problem is that the pairing of the auto-mcs api with the auto-mcs client that my friends need to use is a really manual setup.

It would be great if there was an option to define logins that I can share. So instead of going to the server and doing the pairing, I can just share them the credentials. Another option would be to have an actual Webservice that runs on the auto-mcs instance. That way, they don't even need the auto-mcs software themselves. I know this is a lot, but these are some things I would really appreciate. If that is something you think is a nice addition let me know, I would also be more than happy to help with coding :)

[robinschweitz]

Btw, just want to add that this project is awesome :D

[macarooni-man]

Hi @robinschweitz I appreciate the feedback!

I take security pretty seriously, and I believe that passwords are both cumbersome and insecure when compared to token-based authentication. Due to that aspect, I built Telepath specifically around token-based authentication and as such, adding a password sharing feature would not meet my expectations for security or convenience. I'm curious though from your perspective, what makes the pairing inconvenient? Is it that you have to be on the server to pair it? You only have to pair once per device, unless the authorization is revoked from the server!

Also, yeah we don't currently have plans to support a web interface due to using the Kivy framework. It is possible to use remote desktop, or setup the Linux build with noVNC/fake a desktop environment, or just use xRDP/VNC. It took me 2 years alone to build the UI, and I don't wish to do that again anytime soon, but, we are looking for ways to move away from Kivy. Telepath was the first step to that, as we separated the core functionality of the software from the interface. Let me know if you have any questions/input

[robinschweitz]

Hi @macarooni-man I understand that token-based authentication is better in terms of security and I respect the decision to value the security aspects of your product. The inconvenience comes from sharing the servers with friends. In a world where a person manages all the auto-mc instances themselves, the token-based authentication with the pairing is absolutely fine. But I want to be able to easily share the instance without any interaction of my own besides running my playbooks. Since I want to give my friends access to the auto-mcs instances they go through this setup process with me ( launch the app, I tell them where to go, I go to the server and start the pairing, they input the ip adress and click connect, I tell them the code to enter) It's by no means a big problem it's just a minor inconvenience. I was hoping to just share them credentials once and not do that process with them. I was also thinking about setting up remote desktops for them, but that's also not that elegant in my opinion.

[robinschweitz]

I was also wondering if you have a documentation about the API Endpoints ?

[macarooni-man]

Hi @robinschweitz,

I believe that our current implementation is the best balance of security and convenience, seeing as after you pair the first time you don't have to touch it for consecutive logins. The problem I see with implementing the passwords is for the exact use case you mentioned, you can't leak a randomly generated token, but you can leak a password. At that point, I have to think of the least common denominator in terms of security, and in the case of someone getting your password, they potentially have access to the entirety of Python, via amscript, on your machine remotely.

The end user is unable to see their own token, but they are able to reset it by deleting ~/.auto-mcs/Tools/telepath/telepath-secrets. For sharing the token, I implemented a custom RSA authentication (you can see it in action with Wireshark) to prevent the token from getting leaked, decrypted, or shared. With passwords, the user has the potential to bypass all the security mechanisms, as it's the weakest link in the chain who you share it with that could inadvertently ruin your entire system. I also don't want to make it an optional feature because I feel as though people would choose to use a more insecure method of authentication for the sake of familiarity, and I believe that would reflect on the reputation of auto-mcs as a whole.

Sorry for the rant, I genuinely do appreciate the suggestions and I'm not opposed to adding them, but, I need to find a way to implement a system like that in a way that doesn't undermine the current security mechanisms. I feel like giving you some of the philosophy behind that might give you some insight as to why I did the things I did, and maybe we can come up with a better solution in the future based on that!

For your case, however, I believe the best approach would be to use our Docker image, port forward 8080 and 7001, and share the ttyd password you set with your friends. That way, they can login to the headless terminal through a web browser and initiate the pair request themselves. You can find instructions on how to do that here!

As for the API documentation, it's disabled by default in production, though, if you do the following:

1. Clone the source from the repo
2. Build a Python 3.9 virtual environment
3. Activate the venv and pip install -r ./build-tools/reqs-{your-os}.txt
4. Launch python3 ./source/wrapper.py -s
5. Access the docs from http://localhost:7001/redoc#/

Please let me know if you need clarification on anything I've mentioned, I know it's a lot!

[robinschweitz]

Hi @robinschweitz,

I believe that our current implementation is the best balance of security and convenience, seeing as after you pair the first time you don't have to touch it for consecutive logins. The problem I see with implementing the passwords is for the exact use case you mentioned, you can't leak a randomly generated token, but you can leak a password. At that point, I have to think of the least common denominator in terms of security, and in the case of someone getting your password, they potentially have access to the entirety of Python, via amscript, on your machine remotely.

The end user is unable to see their own token, but they are able to reset it by deleting ~/.auto-mcs/Tools/telepath/telepath-secrets. For sharing the token, I implemented a custom RSA authentication (you can see it in action with Wireshark) to prevent the token from getting leaked, decrypted, or shared. With passwords, the user has the potential to bypass all the security mechanisms, as it's the weakest link in the chain who you share it with that could inadvertently ruin your entire system. I also don't want to make it an optional feature because I feel as though people would choose to use a more insecure method of authentication for the sake of familiarity, and I believe that would reflect on the reputation of auto-mcs as a whole.

Sorry for the rant, I genuinely do appreciate the suggestions and I'm not opposed to adding them, but, I need to find a way to implement a system like that in a way that doesn't undermine the current security mechanisms. I feel like giving you some of the philosophy behind that might give you some insight as to why I did the things I did, and maybe we can come up with a better solution in the future based on that!

No need to apologize. As is said before, I totally understand the benefit of the token based approach and I respect your decision. Thanks for giving me an inside in your decision-making and way of thinking. I appreciate you taking your time to answer me.

For your case, however, I believe the best approach would be to use our Docker image, port forward 8080 and 7001, and share the ttyd password you set with your friends. That way, they can login to the headless terminal through a web browser and initiate the pair request themselves. You can find instructions on how to do that here!

I will take a look at it.

As for the API documentation, it's disabled by default in production, though, if you do the following:

1. Clone the source from the repo
2. Build a Python 3.9 virtual environment
3. Activate the venv and pip install -r ./build-tools/reqs-{your-os}.txt
4. Launch python3 ./source/wrapper.py -s
5. Access the docs from http://localhost:7001/redoc#/

Please let me know if you need clarification on anything I've mentioned, I know it's a lot!

Thank you, that helps me to use and understand the API better.

[robinschweitz]

I took a look at the docker setup and for my use case this works great. I put a nginx before it to be able to use https with Let's Encrypt to secure the traffic to the 8080 tty.

I also looked more at the API, and I was wondering why you decided to make it http instead of https? This makes it less secure and because of this the Authentication Bearer that is used for the API Request can be read.

[macarooni-man]

I took a look at the docker setup and for my use case this works great. I put a nginx before it to be able to use https with Let's Encrypt to secure the traffic to the 8080 tty.

Glad to hear it's working for you!

I also looked more at the API, and I was wondering why you decided to make it http instead of https? This makes it less secure and because of this the Authentication Bearer that is used for the API Request can be read.

HTTP is faster, and most people who will use this don't have the capacity to set up SSL/TLS. It's still possible! The token can be read, but it can't be reused. For example, if you try to replay a request from another machine with Postman/Insomnia Telepath fingerprints the original host that the token was generated for, and it will recognize that someone is trying to session replay, delete the token & log the attack, and the original host will re-authenticate with a new token. You can see this process in Wireshark. If for whatever reason this is bypassed (I'm not sure how you'd do that without compromising the client anyway), the token expires after 30 minutes.

Like I mentioned previously, I basically implemented TLS in HTTP but just for authentication. There's an endpoint to request a public key, and the client encrypts their token with it and sends it back, afterwards the key pair is discarded as well.

[robinschweitz]

Ah, I see. That is actually pretty cool. I will still setup SSL/TLS since it gives me an extra layer of security.

[macarooni-man]

Closing for now, likely not going to be implemented as of this time.