Manage SSH Keys with Resource Manager

Manage SSH keys, authorization, and SSH agent workflow in Resource Manager so deployment targets are reachable before publish.

Introduction

Use this tour when the hosting workflow is blocked less by server creation and more by access. The goal is to connect Resource Manager’s SSH key resources, authorization flow, and agent actions so the infrastructure path is reachable before publish or maintenance work begins.

Keep key management inside the Resource Manager workflow

Prepare local agent state before you need remote access

Authorize keys on the right servers before delivery work starts

SSH keys are part of the resource story

SSH keys are not just a local machine concern. In Resource Manager they sit alongside provider and server resources because access control is part of the same deployment path as the infrastructure itself.

Prepare the local key and agent state

The Add New Key, Start SSH Agent, Stop SSH Agent, and Add To SSH Agent actions are about making sure the local side of the deployment path is ready. If the key is not available to the agent when it should be, later server actions and deployment work become fragile or manual.

Create or register the key you plan to use

Make sure the SSH agent is running when the workflow needs it

Add the correct key to the agent before remote access depends on it

Authorize and revoke keys at the server edge

The Authorize SSH Key and Revoke SSH Key actions are the provider or server-side side of the same access story. They control whether the server trusts the key you prepared locally, which is why SSH key work belongs inside the operational Resource Manager flow rather than outside it.

Local key readiness alone is not enough

The server still needs the right key authorized

Revoke access deliberately when the operational need is gone

Do this before publish and maintenance, not during

The main practical rule is sequencing. Resolve SSH access before the first serious publish, first server maintenance task, or first troubleshooting session. That keeps deployment work focused on the app and infrastructure state instead of collapsing into avoidable access fixes.

Access problems should be solved before delivery work starts

SSH key readiness reduces risky last-minute fixes

A reachable server path makes publish and maintenance calmer

Next steps

Return to the Resource Manager hub when you are ready for the next panel subject. That keeps the Resource Manager access path sequential and avoids bouncing through unrelated follow-up tours.

Return to the broader cloud-server lifecycle

Open provider setup and target handoff for infrastructure planning

Move to Publish Manager once access and targets are ready