DC CORE
Central vs exposing RDP or SSH.
Publicly forwarding RDP or SSH makes the service reachable at an internet-facing address. Central’s supported outbound-agent paths let you manage devices without normally publishing those management ports.
Choose a private management path.
Scroll sideways to compare all columns →
| Decision | Central | Alternative: what to check |
|---|---|---|
| Public exposure | The agent starts the supported outbound connection; public inbound management ports are not normally needed. | A public RDP/SSH listener requires appropriate exposure controls, authentication and ongoing maintenance. |
| Target service | Use a supported agent tool or an approved private route to the service. | Native RDP or SSH must be running and appropriately configured. |
| Identity | Central permissions govern the available action; target credentials may still be required. | The service’s accounts, credentials and host identity remain central to access control. |
| Local controls | Keep endpoint security, application permissions and suitable host firewall rules. | Keep the same local controls in addition to managing the public exposure. |
When each approach fits.
If your current workflow relies on a router port-forward, first identify whether you need native RDP, native SSH or an agent-provided tool. Validate a private replacement from the actual remote location before changing the old access path, and retain appropriate recovery access.
Check Central compatibility · Review remote-access methods · Examine security boundaries
Try the workflow that matters to your team.
Choose a representative device and test the required access, permissions and session closure before rolling out. Review Central pricing and separately charged consumption. Managed operations are optional and need their own agreement.