Skip to main content

Troubleshooting Node Security and Access

This guide covers security-related actions on a node — SSH keys, passwords, security groups, Recovery Mode, Accidental Protection, BitNinja, and Security Compliance. Most security issues are gated by the node's OS, state, or by an attached-service that has not yet finished provisioning.

Common Issues​

IssueWhat to do
SSH key update is not shownCheck whether the node operating system and state support SSH key updates, then see Action Availability.
Password update is not shownUse the access method supported by the node image and check the latest credential email or supported access page.
Security group changes do not affect accessCheck the security group rule, source IP range, node public IP or VPC path, operating system firewall, and service listener.
Delete or reinstall is rejectedCheck whether Accidental Protection is enabled. Disable it only if you intend to continue with the destructive action.
Recovery Mode action asks for power offPower off the node from MyAccount, then retry the Recovery Mode action.
Recovery Mode remains in progressRefresh after the node state settles. Contact support if the status does not change.
BitNinja purchase does not activate on the nodeCheck the activation email and complete the instructions on the selected node.
BitNinja termination is complete but packages remainFollow the BitNinja uninstall guidance for the operating system.
Security Compliance agent does not connectRe-run the portal-generated commands, check outbound network access from the node, and then open the Compliance Dashboard again.
Security Compliance billing should stopDisable Security Compliance from the node action menu and confirm that monitoring is stopped for that node.

Details​

SSH Key Updates​

The SSH key update action is available only when the node's operating system supports key rotation and the node is in a state that allows it. Most Linux nodes support live key updates while Running; some images and most Windows images do not show the action at all. If the action is missing, confirm the OS and state are eligible — see Security Actions for the matrix.

Password Updates​

Password updates are similar — only certain node images support an in-portal password change. If the action is not visible, use the access method supported by the image:

  • For images that mail credentials on launch, check the latest credential email for the current password.
  • For images that expose a password reset through the supported access page, follow that flow instead of the action menu.

Security Group Changes Do Not Affect Access​

When you update a security group rule and access does not change as expected, the rule is rarely the only thing in the path. Walk the full chain:

  1. Security group rule — protocol, port, and source CIDR are correct, and the group is actually attached to the node.
  2. Source IP range — your source IP is included in the rule's source CIDR (NAT or VPN can hide your real IP).
  3. Node public IP or VPC path — public traffic uses the primary public IP; private traffic uses the VPC route.
  4. Operating system firewall — iptables, firewalld, ufw, or Windows Firewall on the node itself may still be dropping traffic.
  5. Service listener — the service must be listening on the expected port and bound to an interface that receives the traffic.

Delete or Reinstall is Rejected​

The most common reason a delete or reinstall is rejected is Accidental Protection. It is enabled to prevent destructive actions from being triggered by mistake. Disable it from the node action menu only when you are sure the destructive action should proceed; the protection cannot be un-done after the destructive action runs.

Recovery Mode Action Asks for Power Off​

Recovery Mode boots the node from a rescue disk rather than its normal disk. To switch boot media safely, the node must be powered off first. Power off the node from MyAccount, then re-trigger the Recovery Mode action.

Recovery Mode Remains in Progress​

The Recovery Mode action transitions the node through intermediate states. Refresh the MyAccount page after the node state settles. If the status remains "in progress" indefinitely, contact cloud-platform@e2enetworks.com.

For the full Recovery Mode walkthrough (mounting the disk, resetting the password, freeing disk space), see Recovery Mode Troubleshooting.

BitNinja: Purchase Does Not Activate​

BitNinja is activated by the activation email sent after purchase. If the node still shows BitNinja as inactive, check the email associated with your account for the activation message and complete the activation steps on the selected node. The portal cannot complete activation on the node's behalf — it requires the activation steps to run inside the node.

BitNinja: Termination Complete but Packages Remain​

When BitNinja is terminated from the portal, monitoring and billing stop, but the BitNinja packages installed on the node remain. Follow the BitNinja uninstall guidance for your operating system to remove the remaining packages cleanly.

Security Compliance Agent Does Not Connect​

If the Security Compliance Dashboard does not see the agent after installation:

  1. Re-run the portal-generated commands on the node. The commands are unique to the node and account — copying old commands or commands from a different node will not work.
  2. Check outbound network access from the node to the Compliance backend. Egress firewalls, OS firewall rules, or a misconfigured proxy can block agent communication.
  3. Open the Compliance Dashboard again after the agent has had a minute to register.

Security Compliance: Billing Should Stop​

Compliance billing is per node and is controlled by the node-level setting. To stop billing:

  1. Open the node action menu.
  2. Disable Security Compliance.
  3. Confirm in the Compliance Dashboard that monitoring is stopped for that node.

If the dashboard continues to show the node as monitored after you disable, contact cloud-platform@e2enetworks.com.

Last updated on May 15, 2026.