GET | List an SSH key by [id]

Description

Access the complete record of one SSH key in PAM Core, using the API v2 canonical model. The response returns the full SSHKeyV2 structure, including the associated devices, the session settings, and the key renewal settings.

An inactive SSH key returns 200 with ssh_key.active set to false. It is not treated as missing.

Prerequisites

• Authorization with read permission to PAM Core, granted by the administrator in A2A. For more information, access How to manage authorizations in A2A.
• A valid OAuth 2.0 access token. For more information, access How to authenticate an application in A2A.

Request

GET /api/v2/pam/ssh-keys/{id}

Path parameters

Query parameters

Sensitive fields: never returned

ssh_key.private_key and ssh_key.password are classified as secret. They are never included in the response, and they cannot be requested through fields. The response reports only whether each one is configured, through secret.has_private_key and secret.has_password.

Example requests

GET {{url}}/api/v2/pam/ssh-keys/2267

With field projection:

GET {{url}}/api/v2/pam/ssh-keys/2267?fields=ssh_key.key_name,ssh_key.active,secret.has_private_key

Response

HTTP/1.1 200 OK

Example response body: full canonical

{
    "data": {
        "id": "2267",
        "ssh_key": {
            "key_name": "key_segura",
            "username": "key_segura",
            "active": true,
            "public_key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...",
            "ssh_key_algorithm": "rsa",
            "credential_tags": ["prod", "ci-cd"],
            "ssh_key_owner": {
                "name": "John Doe"
            },
            "last_used_at": "2026-08-29T12:34:56Z",
            "device_tags": ["prod", "database"]
        },
        "secret": {
            "has_private_key": true,
            "has_password": false,
            "type": "ssh-key"
        },
        "main_device": {
            "id": "159",
            "hostname": "dev",
            "management_ip": "10.10.10.6"
        },
        "devices": [
            {
                "id": "159",
                "hostname": "dev",
                "product": "Oracle Linux VM",
                "device_type": "Server",
                "site": "SP-DC1",
                "domain_name": "CORP"
            }
        ],
        "session": {
            "use_own_credential": false,
            "authentication_credential": {
                "id": "88",
                "username": "auth-user"
            },
            "authentication_device": {
                "id": "159",
                "hostname": "dev"
            },
            "automation_macros": [
                {
                    "id": "5",
                    "name": "ERP Access",
                    "connectivity": "SSH"
                }
            ],
            "restrict_remote_app_only": true
        },
        "key_renewal": {
            "automatic_change_enabled": true,
            "set_password_on_renewal": true,
            "use_key_itself_to_connect": false,
            "authentication_credential": {
                "id": "90",
                "username": "renew-user"
            }
        }
    },
    "meta": {
        "links": {
            "self": "/api/v2/pam/ssh-keys/2267"
        },
        "actions": {
            "activate": "/api/v2/pam/ssh-keys/2267/activate",
            "deactivate": "/api/v2/pam/ssh-keys/2267/deactivate",
            "rotate": "/api/v2/pam/ssh-keys/2267/rotate"
        }
    }
}

The specification lists five actions, but checkout does not ship in this version and the status of checkin is unresolved. Confirm which keys the build actually returns.

Example response body: with field projection

{
    "data": {
        "id": "2267",
        "ssh_key": {
            "key_name": "key_segura",
            "active": true
        },
        "secret": {
            "has_private_key": true
        }
    },
    "meta": {
        "links": {
            "self": "/api/v2/pam/ssh-keys/2267?fields=ssh_key.key_name,ssh_key.active,secret.has_private_key"
        }
    }
}

Projection preserves the nested structure. Requested fields are returned in their canonical position, not flattened.

Response body fields

Every response includes the X-Request-Id header. Provide this value when you contact the Segura® support team about a specific request.

Errors

API v2 returns a structured code in the response body, alongside a human-readable message.

Example error response

422 a secret value was requested through fields:

{
    "code": "api.fields.invalid",
    "message": "Field 'secret.private_key' is not valid for this resource.",
    "details": null
}

The specification and acceptance criterion AC-01 both require 403 with api.fields.sensitive.not.allowed. The 4.2.13 build returns the 422 shown. This document records the observed behavior.

For authentication error messages and the 403 versus 404 policy, access API v2 - Conventions and shared behaviors.

Related documents

• API v2 - Conventions and shared behaviors
• GET | List all SSH keys
• POST | Rotate SSH key
• How to manage authorizations in A2A