Enabling Remote Access at Scale

I’m working on my work flow to handle the production programming of my project right now and have successfully implemented the provisioning of devices for Torizon Cloud through my installation process.

At this point I am trying to determine the best path forward for allowing the remote shell access from the cloud. Is there a best practice approach for this or any reason not to enable this on all of my devices?

My other thought was to add some kind of UI that would allow the end user to enable it if I need to access their device, but I’m not certain how to accomplish that from my docker container.

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Enabling remote access at scale for your devices can be a powerful tool for managing and troubleshooting your fleet. Here are some best practices and considerations for implementing this:

Best Practices for Enabling Remote Access

  1. Security Considerations:

    • Zero-Trust Model: Torizon’s Remote Access starts from a Zero-Trust perspective, meaning the device trusts no one and decides for itself whether or not an incoming connection should be trusted. This is a significant security advantage over traditional VPN or reverse-tunneling solutions.
    • SSH Key Management: Ensure that SSH keys are managed securely. You can take all the keys that enable the security stack offline, managing these keys yourself. This means that even if Torizon’s servers are somehow compromised, your device remains secure.
  2. Automated Provisioning:

    • Pre-built in Torizon OS: Remote Access is pre-built in Torizon OS since version 6.3 and configured as a systemd service. You can automate the enabling and starting of this service during your device provisioning process.
    • Network Configuration: Ensure that your devices are connected to a network with internet access and that port 22 is not blocked or in use.
  3. User Control:

    • User Interface for Enabling Remote Access: If you prefer to give end-users control over enabling remote access, you can create a UI within your application. This UI can interact with the systemd service to start or stop the remote access service as needed.
    • Docker Container Integration: From your Docker container, you can use system commands to control the remote access service. For example, you can use systemctl start torizon-remote-access to enable it and systemctl stop torizon-remote-access to disable it.

Implementation Steps

  1. Automated Enabling During Provisioning:

    • Ensure that the remote access service is enabled and started as part of your device provisioning script.
    • Example command to enable and start the service:
      systemctl enable torizon-remote-access
      systemctl start torizon-remote-access
      
  2. Creating a UI for End-User Control:

    • Develop a simple web or local UI that allows users to enable or disable remote access.
    • Use Docker’s exec command to run system commands from within your container:
      docker exec <container_id> systemctl start torizon-remote-access
      docker exec <container_id> systemctl stop torizon-remote-access
      
  3. Security and Monitoring:

    • Regularly update and rotate SSH keys.
    • Monitor remote access sessions and implement rate limiting to prevent abuse.

Conclusion

Enabling remote access on all devices can be beneficial for maintenance and troubleshooting, but it is crucial to implement it securely. Providing an option for end-users to enable or disable remote access can add an extra layer of security and user control. By following these best practices, you can ensure a secure and efficient remote access setup for your devices.

Please, also check if these links can help you solve your problem:

Configure remote access for Docker daemon | Docker Docs.

Is there any concerns with having this enabled on all devices by default?

Greetings @dleberfinger,

To enable remote access at scale, you just need to enable the systemd service as shown here: Remote Access | Toradex Developer Center

Once this service has been enabled, you can capture this change using TorizonCore Builder. You can then create a new custom image with TorizonCore Builder that has this service enabled by default. With which you can use to production program multiple devices.

Is there any concerns with having this enabled on all devices by default?

I mean not specifically. Of course it’s another point of access to your device. That said it is properly secured and as long as your SSH keys are never leaked, then no one else should be able to remotely access your device. Also it sounds like you want this enabled on your devices anyways.

Best Regards,
Jeremias

1 Like

Thank you, Jeremias.

Happy to help clarify.