• AWS Systems Manager CloudWatch Dasbor tidak akan lagi tersedia setelah 30 April 2026. Pelanggan dapat terus menggunakan CloudWatch konsol Amazon untuk melihat, membuat, dan mengelola dasbor Amazon CloudWatch mereka, seperti yang mereka lakukan hari ini. Untuk informasi selengkapnya, lihat dokumentasi CloudWatch Dasbor Amazon.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pelajari detail teknis tentang SSM Agent

Gunakan informasi dalam topik ini untuk membantu Anda menerapkan AWS Systems Manager Agent (SSM Agent) dan memahami cara kerja agen.

SSM Agent versi 3.2.x.x perilaku kredenSIAL

SSM Agentmenyimpan satu set kredenSIAL sementara di /var/lib/amazon/ssm/credentials (untuk Linux danmacOS) atau %PROGRAMFILES%\Amazon\SSM\credentials (forWindows Server) saat instance di-onboarding menggunakan Konfigurasi Manajemen Host Default di. Quick Setup KredenSIAL sementara memiliki izin yang Anda tentukan untuk peran IAM yang Anda pilih untuk Konfigurasi Manajemen Host Default. Di Linux, hanya akun root yang dapat mengakses kredenSIAL ini. AktifWindows Server, hanya akun SYSTEM dan Administrator lokal yang dapat mengakses kredenSIAL ini.

SSM Agent prioritas kredenSIAL

Topik ini menjelaskan informasi penting tentang cara SSM Agent pemberian izin untuk melakukan tindakan pada sumber daya Anda.

Ketika SSM Agent diinstal pada mesin, itu memerlukan izin untuk berkomunikasi dengan layanan Manajer Sistem. Pada instans Amazon Elastic Compute Cloud (Amazon EC2), izin ini disediakan di profil instans yang dilampirkan ke instans. Pada mesin non-EC2, SSM Agent biasanya mendapatkan izin yang diperlukan dari file kredenSIAL bersama, terletak di /root/.aws/credentials (Linux danmacOS) atau %USERPROFILE%\.aws\credentials (Windows Server). Izin yang diperlukan ditambahkan ke file ini selama proses aktivasi hibrida. Jika node yang diaktifkan hibrida dideregistrasi, agen dapat memasuki mode hibernasi. Untuk informasi selengkapnya, lihat Memahami SSM Agent hibernasi.

Namun, dalam kasus yang jarang terjadi, mesin mungkin berakhir dengan izin yang ditambahkan ke lebih dari satu lokasi di mana SSM Agent memeriksa izin untuk menjalankan tugasnya.

Misalnya, Anda telah mengonfigurasi instance EC2 untuk dikelola oleh Manajer Sistem. Konfigurasi itu termasuk melampirkan profil instance. Tetapi kemudian Anda memutuskan untuk juga menggunakan instance itu untuk tugas pengembang atau pengguna akhir dan menginstal AWS Command Line Interface (AWS CLI) di atasnya. Instalasi ini menghasilkan izin tambahan yang ditambahkan ke file kredensial pada instans.

Saat Anda menjalankan perintah Manajer Sistem pada instance, SSM Agent mungkin mencoba menggunakan kredenSIAL yang berbeda dari yang Anda harapkan untuk digunakan, seperti dari file kredenSIAL alih-alih profil instance. Ini karena mencari SSM Agent kredenSIAL dalam urutan yang ditentukan untuk rantai penyedia kredensia default.

Rantai penyedia default mencari kredensial dalam urutan sebagai berikut:

Untuk informasi terkait, lihat topik berikut:

Melakukan konfigurasi SSM Agent untuk digunakan dengan Federal Information Processing Standard (FIPS)

Jika Anda perlu menggunakan System Manager dengan modul kriptografi yang divalidasi Federal Information Processing Standard (FIPS) 140-3, Anda dapat mengonfigurasi AWS Systems Manager Agent (SSM Agent) untuk menggunakan titik akhir FIPS di Wilayah yang didukung.

Setiap kali Anda mengubah konfigurasi, mulai ulangSSM Agent.

Anda dapat menyesuaikan fitur lain SSM Agent menggunakan prosedur yang sama. Untuk daftar terbaru dari properti konfigurasi yang tersedia dan nilai defaultnya, lihat Definisi Properti Konfigurasi di amazon-ssm-agent repositori di GitHub.

Untuk informasi selengkapnya tentang AWS dukungan untuk FIPS, lihat Federal Information Processing Standard (FIPS) 140-3.

Tentang akun ssm-user lokal

Dimulai dengan versi 2.3.50.0 dariSSM Agent, agen membuat akun pengguna lokal yang dipanggil ssm-user dan menambahkannya ke /etc/sudoers.d direktori (Linux danmacOS) atau ke grup Administrator (Windows Server). Pada versi agen sebelum 2.3.612.0, akun dibuat saat pertama kali SSM Agent dimulai atau dimulai ulang setelah instalasi. Pada versi 2.3.612.0 dan yang lebih baru, akun ssm-user dibuat saat pertama kali sesi dimulai pada sebuah instans. Ini ssm-user adalah pengguna OS default saat sesi dimulaiSession Manager. Anda dapat mengubah izin dengan memindahkan ssm-user ke grup yang kurang istimewa atau dengan mengubah file sudoers. ssm-userAkun tidak dihapus dari sistem saat SSM Agent dihapus.

AktifWindows Server, SSM Agent menangani pengaturan kata sandi baru untuk ssm-user akun saat setiap sesi dimulai. Tidak ada kata sandi yang ditetapkan untuk ssm-user pada instans yang dikelola Linux.

Dimulai dengan SSM Agent versi 2.3.612.0, ssm-user akun tidak dibuat secara otomatis pada Windows Server mesin yang digunakan sebagai pengontrol domain. Untuk menggunakan Session Manager pada pengontrol Windows Server domain, buat ssm-user akun secara manual jika belum ada, dan tetapkan izin Administrator Domain kepada pengguna.

SSM Agent dan Layanan Metadata Instans (IMDS)

Systems Manager bergantung pada metadata instans EC2 untuk berfungsi dengan benar. Systems Manager dapat mengakses metadata instans menggunakan versi 1 atau versi 2 dari Instance Metadata Service (IMDSv1 dan IMDSv2). Instans Anda harus dapat mengakses alamat IPv4 dari layanan metadata instans: 169.254.169.254. Untuk informasi selengkapnya, lihat Metadata instans dan data pengguna di Panduan Pengguna Amazon EC2.

Menjaga SSM Agent terkini

Versi terbaru dirilis setiap kali alat baru ditambahkan ke Manajer Sistem atau pembaruan dibuat untuk alat yang ada. SSM Agent Gagal menggunakan versi terbaru dari agen dapat mencegah node terkelola Anda menggunakan berbagai alat dan fitur Manajer Sistem. Untuk alasan itu, kami menyarankan Anda mengotomatiskan proses untuk tetap SSM Agent up to date pada mesin Anda. Untuk informasi, lihat Mengotomatiskan pembaruan ke SSM Agent. Berlangganan ke SSM Agent halaman Catatan Rilis GitHub untuk mendapatkan pemberitahuan tentang SSM Agent pembaruan.

Memastikan bahwa SSM Agent direktori instalasi tidak dimodifikasi, dipindahkan, atau dihapus

SSM Agentdiinstal di /var/lib/amazon/ssm/ (Linux danmacOS) dan %PROGRAMFILES%\Amazon\SSM\ (Windows Server). Direktori instalasi ini berisi file dan folder penting yang digunakan olehSSM Agent, seperti file kredenSIAL, sumber daya untuk komunikasi antar proses (IPC), dan folder orkestrasi. Tidak ada dalam direktori instalasi yang harus dimodifikasi, dipindahkan, atau dihapus. Jika tidak, SSM Agent mungkin berhenti berfungsi dengan baik.

SSM Agent pembaruan bergulir oleh Wilayah AWS

Setelah SSM Agent pembaruan tersedia di GitHub repositori, bisa memakan waktu hingga dua minggu sampai versi yang diperbarui diluncurkan ke semua Wilayah AWS pada waktu yang berbeda. Untuk alasan ini, Anda mungkin menerima kesalahan “Tidak didukung pada platform saat ini” atau “memperbarui amazon-ssm-agent ke versi yang lebih lama, harap aktifkan izinkan downgrade untuk melanjutkan” saat mencoba menerapkan versi baru di Wilayah. SSM Agent

Untuk menentukan versi yang SSM Agent tersedia untuk Anda, Anda dapat menjalankan curl perintah.

Untuk melihat versi agen yang tersedia di bucket unduhan global, jalankan perintah berikut.

curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/VERSION

Untuk melihat versi agen yang tersedia di Wilayah tertentu, jalankan perintah berikut, ganti region dengan Wilayah tempat Anda bekerja, seperti us-east-2 untuk Wilayah AS Timur (Ohio).

curl https://s3.region.amazonaws.com/amazon-ssm-region/latest/VERSION

Anda juga dapat membuka file VERSION secara langsung di peramban Anda tanpa perintah curl.

SSM Agent komunikasi dengan AWS bucket S3 yang dikelola

Selama melakukan berbagai operasi Manajer Sistem, AWS Systems Manager Agent (SSM Agent) mengakses beberapa bucket Amazon Simple Storage Service (Amazon S3). Bucket S3 ini dapat diakses publik, dan secara default, SSM Agent terhubung ke mereka menggunakan HTTP panggilan.

Namun, jika Anda menggunakan titik akhir cloud pribadi virtual (VPC) dalam operasi Manajer Sistem, Anda harus memberikan izin eksplisit dalam profil instans Amazon Elastic Compute Cloud (Amazon EC2) untuk Manajer Sistem, atau dalam peran layanan untuk mesin non-EC2 di lingkungan hibrida dan multicloud. Jenis mesin yang didukung di lingkungan hybrid dan multicloud Jika tidak, sumber daya Anda tidak dapat mengakses bucket publik ini.

Untuk memberikan akses node terkelola ke bucket ini saat menggunakan titik akhir VPC, Anda membuat kebijakan izin Amazon S3 kustom, lalu melampirkannya ke profil instans Anda (untuk instans EC2) atau peran layanan Anda (untuk node terkelola non-EC2).

Untuk informasi tentang menggunakan titik akhir cloud pribadi virtual (VPC) dalam operasi Manajer Sistem Anda, lihat Meningkatkan keamanan instans EC2 dengan menggunakan titik akhir VPC untuk Manajer Sistem.

Untuk informasi selengkapnya, lihat topik berikut:

Izin bucket yang diperlukan

Tabel berikut menjelaskan masing-masing bucket S3 yang SSM Agent mungkin perlu diakses untuk operasi Manajer Sistem.

Izin Amazon S3 diperlukan oleh SSM Agent

Contoh

Contoh berikut menggambarkan cara menyediakan akses ke bucket S3 yang diperlukan untuk operasi Systems Manager di Wilayah US East (Ohio) Region (us-east-2). Dalam kebanyakan kasus, Anda perlu memberikan izin ini secara eksplisit dalam profil instans atau peran layanan hanya saat menggunakan titik akhir VPC.

JSON

{
        "Version":"2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "s3:GetObject",
                "Resource": [
                    "arn:aws:s3:::aws-windows-downloads-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-us-east-2/*",
                    "arn:aws:s3:::aws-ssm-us-east-2/*",
                    "arn:aws:s3:::us-east-2-birdwatcher-prod/*",
                    "arn:aws:s3:::patch-baseline-snapshot-us-east-2/*",
                    "arn:aws:s3:::aws-patch-manager-us-east-2-552881074/*",
                    "arn:aws:s3:::aws-patchmanager-macos-us-east-2-552881074/*"
                ]
            }
        ]
    }

Memvalidasi mesin yang diaktifkan hibrida menggunakan sidik jari perangkat keras

Ketika mesin non-EC2 dalam lingkungan hybrid dan multicloud, SSM Agent mengumpulkan sejumlah atribut sistem (disebut sebagai hash perangkat keras) dan menggunakan atribut ini untuk menghitung sidik jari. Sidik jari adalah string buram yang diteruskan agen ke API Systems Manager tertentu. Sidik jari unik ini mengaitkan penelepon dengan node terkelola yang diaktifkan hibrida tertentu. Agen menyimpan sidik jari dan hash perangkat keras pada disk lokal di lokasi yang disebut Vault.

Agen menghitung hash perangkat keras dan sidik jari ketika mesin terdaftar untuk digunakan dengan Manajer Sistem. Kemudian, sidik jari diteruskan kembali ke layanan Systems Manager ketika agen mengirimkan perintah RegisterManagedInstance.

Kemudian, ketika mengirim perintah RequestManagedInstanceRoleToken, agen memeriksa sidik jari dan hash perangkat keras di Vault untuk memastikan bahwa atribut mesin saat ini cocok dengan hash perangkat keras yang disimpan. Jika atribut mesin saat ini cocok dengan hash perangkat keras yang disimpan di Vault, agen akan meneruskan sidik jari dari Vault ke RegisterManagedInstance, menghasilkan panggilan yang sukses.

Jika atribut mesin saat ini tidak cocok dengan hash perangkat keras yang disimpan, menghitung SSM Agent sidik jari baru, menyimpan hash dan sidik jari perangkat keras baru di Vault, dan meneruskan sidik jari baru keRequestManagedInstanceRoleToken. Ini menyebabkan RequestManagedInstanceRoleToken gagal, dan agen tidak akan dapat memperoleh token peran untuk menghubungkan ke layanan Systems Manager.

Kegagalan ini disebabkan oleh desain dan digunakan sebagai langkah verifikasi untuk mencegah beberapa node terkelola berkomunikasi dengan layanan Manajer Sistem sebagai node terkelola yang sama.

Ketika membandingkan atribut mesin saat ini untuk hash perangkat keras yang disimpan di Vault, agen menggunakan logika berikut untuk menentukan apakah hash lama dan yang baru cocok:

Batas kesamaan disimpan di Vault, sebagai bagian dari hash perangkat keras.

Batas kesamaan dapat diatur setelah instans terdaftar menggunakan perintah seperti berikut.

Pada mesin Linux:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Pada Windows Server mesin yang menggunakan PowerShell:

cd "C:\Program Files\Amazon\SSM\" `
    .\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1

SSM Agent on GitHub

Kode sumber untuk SSM Agent tersedia GitHub sehingga Anda dapat menyesuaikan agen untuk memenuhi kebutuhan Anda. Kami mendorong Anda untuk mengirim permintaan tarik untuk perubahan yang ingin Anda sertakan. Namun, Amazon Web Services tidak menyediakan dukungan untuk menjalankan salinan yang dimodifikasi dari perangkat lunak ini.

Memahami SSM Agent hibernasi

AWS Systems Manager Hibernasi Agent (SSM Agent) adalah mode operasional yang terjadi ketika agen tidak dapat mempertahankan komunikasi yang tepat dengan layanan Manajer Sistem. Selama hibernasi, agen mengurangi frekuensi komunikasinya dan memasuki keadaan siaga.

Saat SSM Agent hibernasi terjadi

SSM Agenthibernasi dapat terjadi dalam skenario berikut:

Perilaku komunikasi hibernasi

Saat SSM Agent memasuki mode hibernasi, pola komunikasinya dengan layanan Manajer Sistem berubah:

Selama hibernasi, agen terus mencoba otentikasi dan upaya koneksi pada frekuensi yang dikurangi, tetapi tidak dapat memproses perintah baru atau melaporkan informasi status terperinci sampai hibernasi diselesaikan.

Opsi konfigurasi untuk mencegah hibernasi dalam instans hibrida

Opsi konfigurasi utama untuk membantu mencegah hibernasi yang disebabkan oleh perubahan sidik jari perangkat keras adalah menyesuaikan ambang kesamaan:

Pada mesin Linux:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Pada mesin Windows Server menggunakan PowerShell:

cd "C:\Program Files\Amazon\SSM\" `
.\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1

Ambang kesamaan menentukan seberapa ketat agen membandingkan atribut mesin saat ini dengan hash perangkat keras yang disimpan:

Pencatatan dan pemantauan hibernasi

Saat SSM Agent memasuki mode hibernasi, itu membuat entri log yang dapat membantu Anda mengidentifikasi dan memecahkan masalah status hibernasi:

Pantau sumber log ini untuk mendeteksi peristiwa hibernasi lebih awal dan mengambil tindakan korektif untuk memulihkan operasi agen normal.

Pulih dari hibernasi

Untuk pulih dari hibernasi, atasi penyebab yang mendasarinya:

Setelah Anda menyelesaikan masalah yang mendasarinya, agen harus secara otomatis keluar dari mode hibernasi dan melanjutkan operasi normal pada upaya komunikasi berikutnya.