Best practices for auditing SSH access
This document describes best practices for auditing SSH access
to Linux virtual machine (VM) instances.
Cloud Audit Logs let you analyze past activity and can be an important source
of information when investigating suspicious activity affecting your
Trusted Cloud resources.
The following sections contains best practices that can help you maintain a non-repudiable
audit trail:
The document focuses on practices that are either specific to Trusted Cloud by S3NS or
of particular relevance when using SSH on Trusted Cloud. The document doesn't
cover best practices for specific SSH client or server implementations.
Enable data access logs for IAP
To make sure that IAP adds an entry to the Cloud Audit Logs
whenever a user attempts to establish an SSH connection, enable data access logs for the Cloud Identity-Aware Proxy API.
Data access logs are disabled by default. Unless you have concerns about log volume,
enable data access logs for all projects that contain VM instances.
Monitor audit log entries related to SSH usage
SSH usage can impact the security of VMs and their workloads, so it's important to
keep an audit trail for both successful connection attempts and failed access attempts.
This is especially important in production environments, where SSH usage should be
considered a sensitive action.
To track SSH access and possibly to find suspicious behavior, make sure that you
monitor log entries related to SSH, including the following:
| Service |
Method |
Description |
| IAP |
AuthorizeUser |
Indicates a connection attempt through IAP TCP-forwarding.
Log entries contain details about the user's device, satisfied access levels,
and unsatisfied access levels.
|
| OS Login |
google.cloud.oslogin.dataplane.OsLoginDataPlaneService.CheckPolicy |
Indicates a login attempt. |
| OS Login |
google.cloud.oslogin.dataplane.OsLoginDataPlaneService.StartSession |
Indicates the start of a OS Login 2FA challenge |
| OS Login |
google.cloud.oslogin.dataplane.OsLoginDataPlaneService.ContinueSession |
Indicates the completion of a OS Login 2FA challenge |
| Compute Engine |
v1.compute.projects.setCommonInstanceMetadata |
If the field projectMetadataDelta contains an entry for `ssh-keys`, then
this log entry indicates that an SSH key was added, removed or modified in project metadata.
|
| Compute Engine |
v1.compute.instances.setMetadata |
If the field projectMetadataDelta contains an entry for `ssh-keys` or `sshKeys`,
then this log entry indicates that an SSH key was added, removed or modified
in instance metadata.
|
| Compute Engine |
google.ssh-serialport.v1.connect |
Indicates a connection attempt to the serial console |
| IAM |
beta.compute.instances.setIamPolicy,
v1.compute.instances.setIamPolicy
|
Indicates a change to the IAM policy of a VM instance. An IAM policy change
might affect users' ability to modify instance metadata.
|
| IAM |
SetIamPolicy |
Indicates a change to the IAM policy of a project. An IAM policy change
might affect users' ability to modify project metadata and the project's
Data Access audit logs configuration.
|
All audit log records contain a principalEmail field that identifies the principal
that initiated the activity.
To get a complete picture of activity on your VMs, configure your VMs to export
/var/log/messages and SSH server logs to Cloud Logging, for example
by using Ops Agent.
Notice that depending on the Linux distribution you use, SSH server logs might
be written to different log files (typically, /var/log/auth.log or /var/log/secure),
and that these log files aren't covered by the
default configuration used by Ops Agent.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-26 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-26 UTC."],[[["\u003cp\u003eThis document outlines best practices for auditing SSH access to Linux virtual machine (VM) instances on Google Cloud, emphasizing the importance of maintaining a non-repudiable audit trail.\u003c/p\u003e\n"],["\u003cp\u003eEnabling data access logs for the Cloud Identity-Aware Proxy API is crucial to capture all SSH connection attempts via IAP, and should be considered unless log volume is a concern.\u003c/p\u003e\n"],["\u003cp\u003eMonitoring specific audit log entries related to SSH usage, including connection attempts, is important, particularly for sensitive actions in production environments.\u003c/p\u003e\n"],["\u003cp\u003eVarious services and methods within Google Cloud generate audit logs related to SSH, such as IAP's \u003ccode\u003eAuthorizeUser\u003c/code\u003e and Compute Engine's metadata modification methods.\u003c/p\u003e\n"],["\u003cp\u003eFor a comprehensive view of VM activity, exporting \u003ccode\u003e/var/log/messages\u003c/code\u003e and SSH server logs to Cloud Logging, potentially through Ops Agent, is recommended, noting that SSH logs may vary by Linux distribution.\u003c/p\u003e\n"]]],[],null,["*** ** * ** ***\n\nThis document describes best practices for auditing SSH access\nto Linux virtual machine (VM) instances.\n\nCloud Audit Logs let you analyze past activity and can be an important source\nof information when investigating suspicious activity affecting your\nGoogle Cloud resources.\n\nThe following sections contains best practices that can help you maintain a non-repudiable\naudit trail:\n\n- [Enable data access logs for IAP](#enable-iap-access-logs)\n- [Monitor audit log entries related to SSH usage](#monitor-ssh-usage)\n\nThe document focuses on practices that are either specific to Google Cloud or\nof particular relevance when using SSH on Google Cloud. The document doesn't\ncover best practices for specific SSH client or server implementations.\n\nEnable data access logs for IAP\n\nTo make sure that IAP adds an entry to the Cloud Audit Logs\nwhenever a user attempts to establish an SSH connection, [enable data access logs](/logging/docs/audit/configure-data-access) for the **Cloud Identity-Aware Proxy API**.\nData access logs are disabled by default. Unless you have concerns about log volume,\nenable data access logs for all projects that contain VM instances.\n\nMonitor audit log entries related to SSH usage\n\nSSH usage can impact the security of VMs and their workloads, so it's important to\nkeep an audit trail for both successful connection attempts and failed access attempts.\nThis is especially important in production environments, where SSH usage should be\nconsidered a sensitive action.\n\nTo track SSH access and possibly to find suspicious behavior, make sure that you\nmonitor log entries related to SSH, including the following:\n\n| Service | Method | Description |\n|----------------|----------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| IAP | `AuthorizeUser` | Indicates a connection attempt through IAP TCP-forwarding. Log entries contain details about the user's device, satisfied access levels, and unsatisfied access levels. |\n| OS Login | `google.cloud.oslogin.dataplane.OsLoginDataPlaneService.CheckPolicy` | [Indicates a login attempt](/compute/docs/oslogin/view-audit-logs). |\n| OS Login | `google.cloud.oslogin.dataplane.OsLoginDataPlaneService.StartSession` | [Indicates the start of a OS Login 2FA challenge](/compute/docs/oslogin/view-audit-logs) |\n| OS Login | `google.cloud.oslogin.dataplane.OsLoginDataPlaneService.ContinueSession` | [Indicates the completion of a OS Login 2FA challenge](/compute/docs/oslogin/view-audit-logs) |\n| Compute Engine | `v1.compute.projects.setCommonInstanceMetadata` | If the field `projectMetadataDelta` contains an entry for \\`ssh-keys\\`, then this log entry indicates that an SSH key was added, removed or modified in project metadata. |\n| Compute Engine | `v1.compute.instances.setMetadata` | If the field `projectMetadataDelta` contains an entry for \\`ssh-keys\\` or \\`sshKeys\\`, then this log entry indicates that an SSH key was added, removed or modified in instance metadata. |\n| Compute Engine | `google.ssh-serialport.v1.connect` | Indicates a connection attempt to the serial console |\n| IAM | `beta.compute.instances.setIamPolicy`, `v1.compute.instances.setIamPolicy` | Indicates a change to the IAM policy of a VM instance. An IAM policy change might affect users' ability to modify instance metadata. |\n| IAM | `SetIamPolicy` | Indicates a change to the IAM policy of a project. An IAM policy change might affect users' ability to modify project metadata and the project's [Data Access audit logs configuration](/logging/docs/audit/configure-data-access#config-api). |\n\nAll audit log records contain a `principalEmail` field that identifies the principal\nthat initiated the activity.\n\nTo get a complete picture of activity on your VMs, configure your VMs to export\n`/var/log/messages` and SSH server logs to Cloud Logging, for example\nby using [Ops Agent](/logging/docs/agent/ops-agent).\n\nNotice that depending on the Linux distribution you use, SSH server logs might\nbe written to different log files (typically, `/var/log/auth.log` or `/var/log/secure`),\nand that these log files aren't covered by the\n[default configuration used by Ops Agent](/logging/docs/agent/ops-agent/configuration#default)."]]
