Sertifikat SSH adalah alat yang sangat ampuh . Awalnya, di pusat sertifikasi, step-ca

kami hanya menerapkan sekumpulan fungsi minimal untuk otentikasi menggunakan sertifikat pengguna dan host. Kemudian kami menambahkan templat sertifikat X.509 , dan pada Agustus tahun lalu - dan templat SSH, dalam versi 0.15.2. Terakhir, kami telah mendokumentasikan fitur ini dan siap membicarakannya.

Template untuk sertifikat SSH bekerja dengan cara yang mirip dengan template X.509: ini adalah file JSON yang ditulis dalam Go text/template

. Mereka digunakan untuk mengkonfigurasi sertifikat SSH yang dikeluarkannya step-ca

. Mari kita lihat apa saja template ini dan bagaimana Anda dapat menggunakannya.

Secara default, template sertifikat SSH kustom terlihat seperti ini:

{
	"type": {{ toJson .Type }},
	"keyId": {{ toJson .KeyID }},
	"principals": {{ toJson .Principals }},
	"extensions": {{ toJson .Extensions }},
	"criticalOptions": {{ toJson .CriticalOptions }}
}

Dan berikut adalah sertifikat SSH yang diterbitkan menggunakan pola ini:

$ step ssh inspect id_ct-cert.pub
id_ct-cert.pub:
        Type: ecdsa-sha2-nistp256-cert-v01@openssh.com user certificate
        Public key: ECDSA-CERT SHA256:iczSh1XiBBE36yfJcDidgp6fqY3qWx1RtEwFfAN9jDs
        Signing CA: ECDSA SHA256:MKwRQ/SDKk/pCJbbCk5bfhZACjSjv7uZXLyc5n4Wx6k
        Key ID: "carl@smallstep.com"
        Serial: 2831574724231262409
        Valid: from 2020-11-17T16:48:11 to 2020-11-18T08:49:11
        Principals:
                carl
                carl@smallstep.com
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Ini memungkinkan pengguna carl

(atau carl@smallstep.com

) untuk mengotentikasi ke host SSH mana pun yang mempercayai SSH CA saya. Sertifikat tersebut mencakup beberapa ekstensi dasar:

permit-x11-forwarding

: Memungkinkan penerusan X11 (dengan ssh -X

) untuk menjalankan program X11 jarak jauh pada tampilan lokal.
permit-agent-forwarding

: Mengizinkan pengalihan agen (menggunakan ssh -A

) untuk meneruskan kunci dari agen SSH lokal ke host jarak jauh (untuk informasi lebih lanjut tentang agen SSH, lihat di sini ).
permit-port-forwarding

: Memungkinkan penerusan port (tunneling) dari lokal ke port jarak jauh ( ssh -L

) atau jarak jauh ke lokal ( ssh -R

).
permit-pty

: Perpanjangan yang sangat penting. Jika Anda ingin membuka sesi interaktif di konsol, host harus mengalokasikan pty (pseudo-tty) untuk Anda. Jika tidak, tidak ada interaktivitas yang disediakan. Misalnya, untuk menguji otentikasi SSH di GitHub, seseorang dapat menjalankan ssh -T git@github.com

( -T

menonaktifkan permintaan pty).
permit-user-rc

: Jalankan file RC pribadi setelah menghubungkan (terletak ~/.ssh/rc

di host jarak jauh).

Sertifikat pengguna dan host mendukung ekstensi dan parameter penting, tetapi OpenSSH tidak menentukan ekstensi bawaan atau parameter penting apa pun untuk sertifikat host. Jadi, semua yang paling menarik terjadi dengan sertifikat pengguna, jadi dalam artikel ini kami hanya akan mempertimbangkannya.

Contoh templat sertifikat

Mari buat beberapa perubahan pada template default.

Melarang agen dan penerusan port

Jika pengguna terhubung ke host internal melalui bastion host , sebaiknya nonaktifkan penerusan port untuk alasan keamanan. Anda tidak ingin pengguna mengalihkan lalu lintas dari server produksi MySQL ke localhost mereka. Demikian pula, pengalihan agen membawa risiko keamanan . Berikut adalah template yang hanya menghapus dua ekstensi ini dari sertifikat SSH:

{
	"type": {{ toJson .Type }},
	"keyId": {{ toJson .KeyID }},
	"principals": {{ toJson .Principals }},
	"extensions": {
           "permit-x11-forwarding": "",
           "permit-pty": "",
           "permit-user-rc": ""
  },
	"criticalOptions": {{ toJson .CriticalOptions }}
}

Menyematkan direktif perintah paksa

ForceCommand

Adalah direktif konfigurasi SSHD sisi server yang menjalankan perintah alternatif pada host, bukan terminal interaktif. Tetapi dengan efek yang sama, Anda dapat menyematkannya force-command

langsung ke sertifikat - ke dalam bagian Critical Options:

. Ini dapat berguna untuk akun layanan yang hanya perlu menjalankan satu perintah, misalnya, memulai tugas di sistem jarak jauh.

Membatasi koneksi berdasarkan alamat

Untuk membatasi cakupan sertifikat, daftar alamat IP yang diizinkan (blok CIDR) dapat disematkan di dalamnya.

Berikut adalah templat sertifikat yang menggunakan source-address

, dan force-command

.

{
	"type": {{ toJson .Type }},
	"keyId": {{ toJson .KeyID }},
	"principals": {{ toJson .Principals }},
	"extensions": {{ toJson .Extensions }},
	"criticalOptions": {
		"force-command": "echo \"Hello World\"",
		"source-address": "10.20.30.0/24,1.1.1.1/32"
	}
}

Ini adalah contoh normal, tetapi di sini daftar IP diperbaiki secara kaku dan tidak berubah. Dan kami biasanya ingin menggunakan daftar alamat yang berbeda untuk pengguna yang berbeda. Mari mencoba…

Masukkan nilai yang berbeda untuk pengguna yang berbeda

Jelas, pengguna tidak dapat diberikan hak untuk mengedit kisaran alamat. Oleh karena itu, nilai dinamis harus berasal dari sumber yang dapat dipercaya.

Untuk melakukannya, step-ca

melalui penyedia OpenID Connect (OIDC), Anda dapat mengonfigurasi penyedia OAuth untuk menambahkan klaim khusus ke token yang berisi blok alamat CIRD yang ingin kami tambahkan ke sertifikat pengguna ini.

Penyedia OIDC adalah cara sempurna untuk menerbitkan sertifikat SSH ke step-ca. Dalam artikel DIY Single Sign-On untuk SSH , saya membahas cara mengonfigurasi SSH CA untuk menerbitkan sertifikat SSH jangka pendek menggunakan token ID dari penyedia OAuth tepercaya. Jika sebuah step-ca

dikonfigurasi sebagai klien OAuth tepercaya, ini akan membaca bidang email

dari token ID dan mengambil daftar kepala sertifikat SSH dari sana (misalnya, carl@smallstep.com

sertifikat untuk carl

dan akan dibuat oleh bidang carl@smallstep.com

).

Tapi OIDC memungkinkan membaca ID dan bidang lain dari token melalui template . Di sinilah keajaiban sebenarnya dimulai. Jadi, kami menambahkan bidang terpisah ke direktori pengguna di sisi penyedia identitas source_address

- dan mencerminkannya dalam token ID kami. Kemudian, melalui template SSH, Anda dapat memasukkan nilai dari token ke dalam sertifikat. Berikut templatenya:

{
	"type": {{ toJson .Type }},
	"keyId": {{ toJson .KeyID }},
	"principals": {{ toJson .Principals }},
	"extensions": {{ toJson .Extensions }},
{{ if .Token.source_address }}
	"criticalOptions": {
		"source-address": "{{ .Token.source_address }}"
	}
{{ else }}
	"criticalOptions": {{ toJson .CriticalOptions }}
{{ end }}
}

Autentikasi GitHub dengan sertifikat

Mari kita lihat contoh lain dari klaim kustom. Dengan menggunakan GitHub Enterprise Cloud atau GitHub Enterprise Server, Anda dapat mengonfigurasi GitHub untuk menggunakan sertifikat SSH. Secara khusus, GitHub akan mempercayai otoritas sertifikasi SSH Anda . Namun agar semuanya berfungsi, Anda perlu membuat sertifikat SSH terpisah untuk setiap pengguna dengan ekstensi login@github.com

yang menentukan nama pengguna di GitHub. Dengan ekstensi ini, sertifikat mengautentikasi pengguna ke GitHub Enterprise. Dan itu hebat: sertifikat yang sama memungkinkan Anda untuk terhubung ke server Anda melalui SSH dan memasukkan kode ke GitHub.

Berikut adalah template sertifikat dengan dukungan ekstensi GitHub kustom:

{
	"type": {{ toJson .Type }},
	"keyId": {{ toJson .KeyID }},
	"principals": {{ toJson .Principals }},
	"criticalOptions": {{ toJson .CriticalOptions }},
{{ if .Token.ghu }}
	"extensions": {
	  "login@github.com": {{ toJson .Token.ghu }}
	}
{{ else }}
	"extensions": {{ toJson .Extensions }}
{{ end }}
}

Untuk menggunakan template, Anda perlu menambahkan persyaratan individu ghu

("Nama Pengguna GitHub") ke token identifikasi OIDC . Mari kita lihat lebih dekat cara membuat klaim kustom ini menggunakan penyedia OAuth Anda.

Mendaftarkan aplikasi dengan penyedia identitas

Tidak semua penyedia identitas mendukung persyaratan individu, tetapi jika ya, prosesnya hampir sama. Begini cara melakukannya dengan Okta:

Tambahkan aplikasi OAuth untuk Okta dan kepercayaan itu dengan penyedia OIDC di step-ca

seperti yang dijelaskan dalam DIY SSO untuk SSH artikel .
Tambahkan bidang baru ke direktori pengguna Okta Anda (misalnya GitHub Username

)
Tambahkan persyaratan individu ke token OIDC , misalnya, dengan nama pendekghu

Sekarang kami mengisi bidang untuk pengguna uji dan memeriksa persyaratan. Okta memiliki alat pengujian token ID. Atau dapat digunakan step

untuk memvalidasi seluruh aliran OAuth:

OIDC_ENDPOINT="https://[your organization].okta.com/oauth2/default/.well-known/openid-configuration"
CLIENT_ID="[your OAuth client ID]"
CLIENT_SECRET="[your OAuth client secret]"
step oauth --oidc --provider $OIDC_ENDPOINT \
    --client-id $CLIENT_ID --client-secret $CLIENT_SECRET \
    --listen=":10000" --bare |
step crypto jwt inspect --insecure

Terakhir, step-ca

untuk menggunakan pola ini. Konfigurasi penyedia harus mengacu pada file template:

{
  "provisioners": [
    {
      "type": "OIDC",
      "name": "Okta",
      "clientID": "[your OAuth client ID]",
      "clientSecret": "[your OAuth client secret]",
      "configurationEndpoint": "https://[your organization].okta.com/oauth2/default/.well-known/openid-configuration",
      "listenAddress": ":10000",
      "options": {
        "ssh": {
            "templateFile": "templates/certs/ssh/github.tpl"
        }
      }
    },
      ...
  ]
}

Apa berikutnya

Kami telah menambahkan bagian tentang Template SSH ke dokumentasi yang menjelaskan lebih detail tentang semua parameter dan variabel.

Jika Anda memiliki pertanyaan, jangan ragu untuk bertanya .

Contoh penggunaan cerdas template SSH