Apple: SSH dan FileVault

• Saat FileVault diaktifkan, volume data berada dalam keadaan terkunci selama proses boot macOS
• Berkas konfigurasi OpenSSH disimpan di volume data sehingga selama terkunci, metode autentikasi yang ada maupun akses shell tidak dapat digunakan
• Jika Remote Login (SSH) diaktifkan, volume data dapat dibuka dari jaringan jarak jauh melalui autentikasi kata sandi
• Cara ini bukan berarti sesi SSH langsung diizinkan; setelah dibuka, koneksi SSH akan terputus sementara
• Akses SSH baru tersedia setelah volume data di-mount dan layanan yang diperlukan selesai dijalankan

---

Gambaran umum integrasi SSH dan FileVault di Apple

• Pada macOS dengan FileVault diaktifkan, volume data terkunci sehingga volume tersebut tidak dapat diakses bahkan setelah proses boot dimulai
• Karena semua berkas konfigurasi sistem dan per akun milik OpenSSH disimpan di dalam volume data, saat volume data terkunci, metode autentikasi yang biasanya dikonfigurasi maupun akses shell umumnya dinonaktifkan

Membuka kunci dari jarak jauh dengan Remote Login (SSH)

• Setelah boot, meskipun volume data masih terkunci, jika Remote Login (login SSH) diaktifkan, sistem tetap mengizinkan percobaan autentikasi kata sandi melalui jaringan
• Pengguna dapat memakai SSH untuk membuka volume yang dikunci oleh FileVault dari jarak jauh melalui autentikasi kata sandi

Batasan dan proses pembukaan kunci

• Fitur ini memungkinkan kunci volume data dibuka, tetapi bukan berarti sesi SSH langsung terhubung
• Segera setelah volume data dibuka kuncinya, macOS akan menyelesaikan proses mount volume dan menjalankan layanan pendukung yang bergantung padanya, sehingga koneksi SSH sempat terputus untuk sementara
• Setelah prosedur tersebut selesai, SSH dan layanan aktif lainnya dapat digunakan secara normal

Diperkenalkan di macOS 26 Tahoe

• Fitur pembukaan kunci volume data dari jarak jauh melalui SSH pertama kali diperkenalkan di macOS 26 Tahoe

[GN⁺]

Komentar Hacker News

• Saat FileVault diaktifkan, volume data akan terkunci dan tidak bisa diakses selama proses boot maupun setelah boot sampai autentikasi dilakukan dengan kata sandi akun. OpenSSH untuk macOS menyimpan baik file konfigurasi sistem maupun per-akun di volume data. Karena itu, selama FileVault masih aktif, metode autentikasi yang biasanya disetel maupun akses shell umumnya tidak bisa digunakan. Namun jika Remote Login diaktifkan, autentikasi kata sandi melalui SSH tetap dimungkinkan bahkan dalam kondisi ini. Dengan begitu, kunci volume data bisa dibuka dari jarak jauh lewat jaringan. Hanya saja sesi SSH tidak langsung berlanjut; setelah volume dibuka lewat SSH, koneksi akan terputus sebentar sementara macOS menyelesaikan mounting volume dan me-restart layanan, lalu setelah itu SSH (dan layanan lain) bisa digunakan seperti biasa. Perubahan yang sangat disambut baik

• Jadi penasaran apakah ini berarti kini server Mac mini yang sepenuhnya remote bisa dijalankan tanpa perlu menyambungkan keyboard fisik setelah reboot otomatis akibat listrik padam. Perubahan yang benar-benar keren

  • Setelah dites langsung, dipastikan berfungsi dengan sempurna
    1. Aktifkan General > Sharing > Remote Management
    2. Saat terhubung via SSH setelah reboot, muncul pesan "Sistem ini terkunci. Gunakan nama akun dan kata sandi untuk membukanya. Setelah dibuka, koneksi normal akan tersedia"
    3. Jika autentikasi via SSH berhasil, koneksi SSH diputus dan muncul pesan "Sistem berhasil dibuka. Sekarang Anda bisa melakukan autentikasi normal melalui SSH"
    4. Saat terhubung lagi via SSH, sistem bisa diakses dengan normal
  • Perintah berikut juga bisa digunakan

    sudo fdesetup authrestart -delayminutes -1
    

    Metode ini memungkinkan login otomatis satu kali pada reboot berikutnya dengan akun yang dipilih. Praktis karena tidak perlu memasukkan kata sandi, tetapi ada risiko keamanan. Dalam situasi tertentu mungkin masih bisa diterima
  • Benar-benar penasaran, kenapa memilih macOS sebagai OS server. Saya juga merasa hardware Mac mini sangat menarik dan pernah mempertimbangkannya. Tapi saya ragu untuk menjalankan Linux alih-alih macOS
  • Dulu pernah ada pengalaman harus benar-benar mencabut server dari rak, membersihkan debu, lalu memasang monitor/keyboard untuk login dan membuka kunci gara-gara rekan kerja tak sengaja mengaktifkan FileVault di mesin CI. Sekarang karena unlock via SSH sudah memungkinkan, kalau kejadian seperti itu terulang lagi bisa langsung dibereskan dari jarak jauh
  • Sangat paham repotnya Mac remote dengan FileVault aktif yang harus login fisik dulu agar bisa online lagi setelah listrik padam. Penasaran apakah setelah reboot sekarang juga memungkinkan akses remote penuh lewat GUI. Sedang mempertimbangkan membeli Mac mini untuk homelab, dan sampai terpikir apakah tetap perlu perangkat remote seperti KVM jika dibutuhkan

• Ingin menekankan bahwa perubahan ini sangat besar untuk lingkungan Mac nonpribadi seperti di perusahaan. Value for money dan kualitas Mac Mini cukup layak untuk keperluan otomasi, dan di perusahaan pun adopsinya sebenarnya sedang bertahap ditingkatkan kalau bukan karena masalah ini. Isu FileVault adalah salah satu faktor utama yang menghambat

  • Saya tertarik menggunakan Mac sebagai server umum. Penasaran apakah ada pengaturan atau cara tambahan agar lebih mudah dikelola sebagai server, dan apakah dipakai untuk workload khusus Mac atau juga menjalankan workload Linux berbasis container

• Senang melihat macOS 26 Tahoe menambahkan fitur unlock volume data lewat SSH. Setelah upgrade Tahoe baru-baru ini, saya sempat heran karena koneksi SSH tiba-tiba bisa dilakukan, dan sekarang tahu bahwa ini penyebabnya. Biasanya saya tidak mematikan Mac, tetapi kadang saat perlu mengaksesnya dari jarak jauh saya lupa bahwa sehari sebelumnya ada update besar yang terpasang dan jadi panik. Perubahan kali ini mengurangi kekhawatiran itu

• Jadi menduga ini berarti FileVault sekarang tidak lagi diterapkan pada volume sistem. Karena volume sistem bersifat read-only, isinya tetap, dan sama di semua macOS. Logika bahwa sistem bisa boot penuh sampai jaringan aktif lalu baru meminta dekripsi volume data juga terasa masuk akal. Jika FileVault memang sengaja melewati enkripsi volume sistem, menurut saya itu perubahan yang sangat rasional. Juga disebut bahwa dengan teknologi overlay, sering kali terlihat seperti menulis ke partisi sistem padahal sebenarnya data ditulis ke volume data

  • Informasi seperti kata sandi WiFi juga disimpan di volume data, jadi jaringan tidak selalu tersedia

• Perubahan yang menarik, tetapi penasaran apakah isu "race condition" yang terjadi di sesi grafis juga akan berlaku pada SSH, misalnya saat shell disimpan di volume data. Contohnya, saat restart dan memilih memulihkan aplikasi, pernah ada situasi di mana aplikasi terbuka lebih dulu sebelum semua volume ter-mount sehingga eksekusi shell gagal. Ini sering terjadi kalau shell diinstal dengan Nix. Tampaknya masalah yang sama juga cukup mungkin terjadi pada SSH. Penasaran apakah isu seperti ini sudah diselesaikan di level sistem

  • Dalam proses unlock via SSH, koneksi ditutup tepat setelah volume data berhasil dibuka. Setelah mounting volume selesai, koneksi berikutnya barulah menjalankan shell, jadi masalah seperti ini tidak terjadi. Saat memakai Nix store, ada pengalaman mengatasinya dengan shim menggunakan wait4path. Cukup pasang shim itu sebelumnya di path yang sudah diketahui pada volume data lalu jadikan sebagai login shell
  • Apple memblokir masalah ini dari akarnya dengan menghentikan semua proses setelah perangkat dibuka ("userspace reboot")
  • Sepertinya reconnect akan menyelesaikan sebagian besar masalah. Khususnya di SSH, mekanisme retry jaringan biasanya memang sudah ada, jadi bukan isu besar
  • Kasus ini tampaknya bisa diatasi dengan utilitas wait4path yang sudah lama tersedia di OS

• Menurut saya ini perubahan yang sangat disambut baik. Saya sendiri mematikan FileVault karena fitur ini belum ada

• Sedang bereksperimen dengan Full Disk Encryption di Omarchy (konfigurasi Arch yang punya arah kuat), sambil mempertimbangkan apakah bisa dipakai sebagai VM utama. Saat bekerja langsung secara fisik, saya bisa mengakses desktop berakselerasi GPU dan semua pekerjaan komputasi jangka panjang. Namun jika selama beberapa minggu saya berada jauh dari lokasi lalu mesin reboot, fakta bahwa kata sandi disk harus dimasukkan secara fisik membuat saya ragu untuk mencobanya. Sistem ini berjalan di ProxMox, tetapi karena pengaturan seperti USB passthrough, akses lewat penampil VNC standar tidak memungkinkan. Penasaran apakah Omarchy akan mencoba unlock jarak jauh seperti macOS

  • Di Linux, sejak lama hal seperti ini bisa diwujudkan dengan menaruh dropbear di initramfs untuk fitur unlock jarak jauh

• Rasanya pasti ada jalur eksploitasi kerentanan di suatu tempat

  • Di luar risiko keamanan umum dari SSH berbasis kata sandi, saya tidak langsung melihat tambahan risiko tertentu. Kalau khawatir, menurut saya cukup taruh saja di balik firewall seperti Wireguard. Sebelumnya server Mac harus mematikan FileVault, jadi dibanding itu ini terasa jauh lebih baik
  • Berdasarkan pengalaman dengan isu keamanan seperti Blastdoor, saya selalu cenderung berhati-hati terhadap perubahan seperti ini

• Saya punya Mac mini yang dulu saya urungkan untuk homelab karena fitur ini tidak ada, tetapi sekarang semuanya terasa berbeda