9.2. Log Masuk Jarak Jauh

Sangat penting bagi administrator untuk dapat menyambung ke suatu komputer dari jarak jauh. Server, dikurung dalam kamar mereka sendiri, jarang dilengkapi dengan papan ketik dan monitor permanen — tetapi mereka terhubung ke jaringan.

9.2.1. Login Jarak Jauh Aman: SSH

Protokol SSH (Secure SHell) dirancang dengan keamanan dan kehandalan. Koneksi yang menggunakan SSH aman: mitra diotentikasi dan semua pertukaran data dienkripsi.

KOSAKATA Otentikasi, enkripsi

Ketika Anda perlu memberikan klien kemampuan untuk melakukan atau memicu tindakan pada server, keamanan penting. Anda harus memastikan identitas dari klien; ini adalah otentikasi. Identitas ini biasanya terdiri dari kata sandi atau frasa sandi yang harus dirahasiakan, atau klien lain jadi bisa mendapatkan kata sandi tersebut. Ini adalah tujuan dari enkripsi, yang merupakan bentuk enkoding yang memungkinkan dua sistem untuk mengkomunikasikan informasi rahasia pada saluran umum sekaligus melindungi dari dapat dibaca oleh orang lain.

Otentikasi dan enkripsi sering disebut bersama, baik karena mereka sering digunakan bersama-sama, dan karena mereka biasanya diimplementasikan dengan konsep-konsep matematika yang serupa.

SSH juga menawarkan dua layanan transfer berkas. SCP adalah alat baris perintah yang dapat digunakan seperti cp, kecuali bahwa sebarang path ke mesin lain diawali dengan nama mesin, diikuti oleh titik dua.

$ scp berkas mesin:/tmp/

sftp adalah perintah yang interaktif, mirip dengan ftp. Dalam satu sesi, sftp dapat mentransfer beberapa berkas, dan mungkin untuk memanipulasi berkas remote dengannya (menghapus, mengubah nama, mengubah hak akses, dll).

Debian menggunakan OpenSSH, sebuah SSH versi gratis yang dikelola oleh proyek OpenBSD (sistem operasi bebas berbasis pada kernel BSD, berfokus pada keamanan) dan fork dari perangkat lunak SSH asli yang dikembangkan oleh perusahaan SSH Communication Corp, dari Finlandia. Perusahaan ini awalnya mengembangkan SSH sebagai perangkat lunak bebas, tetapi akhirnya memutuskan untuk melanjutkan perkembangan di bawah lisensi tak bebas. Proyek OpenBSD kemudian menciptakan OpenSSH untuk mempertahankan versi gratis dari SSH.

KEMBALI KE DASAR Fork

"Fork", dalam bidang perangkat lunak, berarti sebuah proyek baru yang dimulai sebagai klon dari proyek yang sudah ada, dan akan bersaing dengannya. Dari sana, kedua perangkat lunak biasanya cepat akan menyimpang dalam hal perkembangan baru. Fork ini sering merupakan akibat dari perselisihan dalam tim pengembangan.

Pilihan untuk melakukan fork atas sebuah proyek adalah akibat langsung dari sifat perangkat lunak bebas; fork merupakan kejadian yang sehat saat itu memungkinkan keberlanjutan proyek sebagai perangkat lunak bebas (misalnya dalam kasus perubahan lisensi). Sebuah fork yang timbul dari perselisihan teknis atau pribadi sering membuang-buang sumber daya manusia; resolusi lain akan lebih baik. Merger dua proyek yang sebelumnya mengalami fork bukan tidak pernah terjadi.

OpenSSH dipecah menjadi dua paket: bagian klien dalam paket openssh-client, dan server dalam paket openssh-server. Paket meta ssh bergantung pada kedua bagian dan memfasilitasi instalasi keduanya (apt install ssh), sedangkan task-ssh-server, sering dipilih selama instalasi awal, tergantung pada paket server saja.

9.2.1.1. Otentikasi Berbasis Kunci

Setiap kali seseorang log masuk melalui SSH, server remote meminta password untuk mengotentikasi pengguna. Ini bisa menjadi bermasalah jika Anda ingin mengotomatisasi sambungan, atau jika Anda menggunakan alat yang membutuhkan koneksi sering melalui SSH. Inilah sebabnya mengapa SSH menawarkan sistem otentikasi berbasis kunci.

Pengguna menghasilkan pasangan kunci pada komputer klien dengan ssh-keygen -t rsa; kunci publik yang dihasilkan disimpan di ~/.ssh/id_rsa.pub, sedangkan kunci privat yang sesuai disimpan di ~/.ssh/id_rsa. Pengguna kemudian dapat menggunakan ssh-copy-id server untuk menambahkan kunci publik mereka ke berkas ~/.ssh/authorized_keys di server, atau, jika akses SSH belum diaktifkan, mereka harus meminta administrator untuk menambahkan kunci mereka secara manual.

Jika kunci pribadi tidak dilindungi dengan "frasa sandi" pada saat pembuatannya, semua login berikutnya di server akan berfungsi tanpa kata sandi. Jika tidak, kunci pribadi harus didekripsi setiap kali dengan memasukkan frasa sandi. Untungnya ssh-agent memungkinkan kita untuk menyimpan kunci pribadi dalam memori untuk tidak perlu memasukkan kembali kata sandi secara teratur. Untuk ini, Anda cukup menggunakan ssh-add (sekali per sesi kerja) asalkan sesi tersebut sudah dikaitkan dengan contoh fungsional ssh-agent. Debian mengaktifkannya secara baku dalam sesi grafis, tetapi ini dapat dinonaktifkan dengan mengubah /etc/X11/Xsession.options dan mengomentari use-ssh-agent. Untuk sesi konsol, Anda dapat memulai agen secara manual dengan eval $(ssh-agent).

KEAMANAN Perlindungan kunci privat

Barangsiapa memiliki kunci privat tersebut dapat login di akun yang dikonfigurasi. Inilah sebabnya mengapa akses ke kunci privat dilindungi oleh "frasa sandi". Seseorang yang memperoleh salinan berkas kunci pribvat (misalnya, ~/.ssh/id_rsa) masih harus tahu frasa ini agar dapat menggunakannya. Perlindungan tambahan ini tidak anti tembus, dan jika Anda berpikir bahwa berkas ini telah dikompromikan, paling baik untuk menonaktifkan kunci tersebut pada komputer tempat itu telah diinstal (dengan menghapus dari berkas authorized_keys) dan menggantikannya dengan kunci baru yang dibuat.

KULTUR Cacat OpenSSL dalam Debian Etch

Pustaka OpenSSL, sebagaimana awalnya disediakan di Debian Etch, memiliki masalah yang serius dalam pembangkit angka acak (RNG). Memang, pengelola Debian telah membuat perubahan sehingga aplikasi yang menggunakan itu tidak lagi menghasilkan peringatan ketika dianalisis oleh alat pengujian memori seperti valgrind. Sayangnya, perubahan ini juga berarti bahwa RNG hanya mempekerjakan salah satu sumber entropi sesuai dengan nomor proses (PID) yang 32.000 kemungkinan nilainya tidak menawarkan cukup keacakan.

→ https://www.debian.org/security/2008/dsa-1571

Secara khusus, setiap kali OpenSSL digunakan untuk menghasilkan sebuah kunci, itu selalu menghasilkan kunci dalam kumpulan ratusan ribu kunci yang dikenal (32.000 dikalikan dengan sejumlah kecil panjang kunci). Ini mempengaruhi kunci SSH, kunci SSL, dan sertifikat X.509 yang digunakan oleh banyak aplikasi, seperti misalnya OpenVPN. Seorang cracker hanya perlu mencoba semua kunci untuk mendapatkan akses yang tidak sah. Untuk mengurangi dampak dari masalah, SSH daemon diubah untuk menolak bermasalah kunci yang tercantum dalam paket openssh-blacklist dan openssh-blacklist-extra. Selain itu, perintah ssh-vulnkey memungkinkan identifikasi kunci yang mungkin terkompromikan dalam sistem.

Analisis lebih mendalam terhadap kejadian ini mengungkap bahwa itu adalah hasil dari beberapa masalah (kecil), baik dalam proyek OpenSSL dan dengan para pengelola paket Debian. Sebuah perpustakaan yang banyak digunakan seperti OpenSSL harus — tanpa modifikasi — tidak menghasilkan peringatan saat diuji oleh valgrind. Selain itu, kode (terutama bagian RNG yang sensitif) harus memuat komentar yang lebih baik untuk mencegah kesalahan tersebut. Di sisi Debian, pengelola ingin memvalidasi modifikasi dengan pengembang OpenSSL, tetapi hanya menjelaskan modifikasi tanpa memberikan patch yang sesuai untuk ditinjau dan gagal untuk menyebutkan perannya dalam Debian. Akhirnya, pilihan-pilihan perawatan sub-optimal: perubahan yang dibuat ke kode asli tidak didokumentasikan jelas; semua modifikasi secara efektif tersimpan dalam repositori Subversion, tapi mereka akhirnya semua digabung ke dalam satu patch selama penciptaan sumber paket.

Sulit dalam kondisi seperti ini untuk menemukan tindakan korektif demi mencegah insiden tersebut dari berulang. Pelajaran yang bisa dipetik di sini adalah bahwa setiap perbedaan yang diperkenalkan Debian ke perangkat lunak hulu harus dijustifikasi, didokumentasikan, diserahkan kepada proyek hulu bila mungkin, dan dipublikasikan secara luas. Dari perspektif inilah format paket sumber baru ("3.0 (quilt)") dan layanan web sumber Debian dikembangkan.

→ https://sources.debian.net

9.2.1.2. Otentikasi Berbasis Sertifikat

Kunci SSH tidak bisa hanya dilindungi oleh kata sandi (atau tidak). Fitur yang sering tidak dikenal adalah bahwa mereka juga dapat ditandatangani melalui sertifikat, baik host maupun kunci klien. Pendekatan ini hadir dengan beberapa keunggulan. Alih-alih memelihara berkas authorized_keys per pengguna seperti yang dijelaskan di bagian sebelumnya, server SSH dapat dikonfigurasi untuk mempercayai semua kunci klien yang ditandatangani oleh sertifikat yang sama (lihat juga Bagian 10.2.2, “Infrastruktur Kunci Publik: easy-rsa”) dengan menggunakan direktif TrustedUserCAKeys dan HostCertificate di /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Sebaliknya klien juga dapat dikonfigurasi untuk mempercayai kunci host yang ditandatangani oleh otoritas yang sama, sehingga lebih mudah untuk memelihara berkas known_hosts (bahkan di seluruh sistem melalui /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Keduanya, otentikasi sertifikat dan kunci publik, dapat digunakan bersama satu sama lain.

9.2.1.3. Menggunakan Aplikasi-aplikasi X11 Jarak Jauh

Protokol SSH memungkinkan penerusan data grafis (sesi "X11", dari nama sistem grafis yang paling terkenal di Unix); server kemudian mempertahankan saluran khusus untuk data tersebut. Secara khusus, program grafis yang dijalankan dari jarak jauh dapat ditampilkan pada layar lokal server XFree86, dan seluruh sesi (masukan dan tampilan) akan aman. Karena fitur ini memungkinkan aplikasi remote untuk mengganggu sistem lokal, ini dinonaktifkan secara default. Anda dapat mengaktifkannya dengan menetapkan X11Forwarding yes di berkas konfigurasi server (/etc/ssh/sshd_config). Akhirnya, pengguna juga harus memintanya dengan menambahkan opsi -X untuk baris perintah ssh.

LEBIH LANJUT Magic cookies dalam .Xauthority

Ketika pengguna terhubung melalui SSH dan memulai sesi X11 jarak jauh, apa yang disebut magic cookie dibuat dan disimpan dalam berkas .Xauthority di direktori home pengguna yang memulai koneksi. Cookie ini digunakan oleh xauth untuk mengotentikasi pengguna selama sesi X. Jika pengguna meniru pengguna lain di sistem, misalnya menggunakan su atau sudo, maka cookie tidak disalin secara otomatis ke pengguna target dan server X akan menolak untuk memulai aplikasi grafis di bawah konteks pengguna target. Anda harus menyalin magic cookie ke direktori home pengguna target (dengan mengekspor dan mengimpor ulang cookie melalui xauth) untuk memungkinkan pengguna lain memulai program grafis juga selama sesi X.

9.2.1.4. Menciptakan Tunnel Terenkripsi dengan Penerusan Port

Opsi -R dan -L memungkinkan ssh untuk menciptakan "terowongan terenkripsi" antara dua mesin, secara aman meneruskan port TCP lokal (lihat sidebar KEMBALI KE DASAR TCP/UDP) ke mesin remote atau sebaliknya.

KOSAKATA Tunnel

Internet, dan kebanyakan LAN yang terhubung, beroperasi dalam mode paket dan tidak dalam modus yang terhubung, berarti bahwa paket yang diterbitkan dari satu komputer ke yang lain akan berhenti di beberapa router perantara untuk menemukan jalan ke tujuan. Anda masih dapat mensimulasikan operasi yang terhubung dimana stream dibungkus dalam paket-paket IP normal. Paket ini mengikuti rute biasa mereka, tapi stream ini direkonstruksi tidak berubah di tujuan. Kami menyebutnya "tunnel", analog dengan terowongan jalan tempat kendaraan langsung berjalan dari pintu masuk (masukan) ke tempat keluar (keluaran) tanpa menemui persimpangan apapun, dibandingkan dengan jalur pada permukaan yang akan melibatkan persimpangan dan mengubah arah.

Anda dapat menggunakan kesempatan ini untuk menambahkan enkripsi ke tunnel: stream yang mengalir melaluinya kemudian tidak dikenali dari luar, tapi dikembalikan ke dalam bentuk terdekripsi di pintu keluar tunnel.

ssh -L 8000:server:25 perantara menjalin suatu sesi SSH dengan host perantara dan mendengarkan port lokal 8000 (lihat Gambar 9.3, “Penerusan suatu port lokal dengan SSH”). Untuk sebarang koneksi yang terjalin pada port ini, ssh akan memulai koneksi dari komputer perantara ke port 25 pada server, dan akan mengikat kedua koneksi bersama-sama.

ssh -R 8000:server:25 perantara juga menjalin sesi SSH ke komputer perantara, tetapi pada mesin ini ssh mendengarkan port 8000 (lihat Gambar 9.4, “Penerusan suatu port jauh dengan SSH”). Sebarang koneksi yang dijalin pada port ini akan menyebabkan ssh membuka koneksi dari mesin lokal ke port 25 server dan mengikat kedua koneksi bersama-sama.

Dalam kedua kasus, sambungan dibuat ke port 25 pada host server, melewati tunnel SSH yang dijalin antara mesin lokal dan mesin perantara. Dalam kasus pertama, pintu masuk ke tunnel adalah port lokal 8000, dan data bergerak menuju mesin perantara sebelum diarahkan ke server pada jaringan "publik". Dalam kedua kasus, masukan dan keluaran di tunnel dibalik; pintu masuk adalah port 8000 pada mesin perantara, keluaran adalah pada host lokal, dan data diarahkan ke server. Dalam prakteknya, server ini biasanya mesin lokal atau perantara. Dengan cara itu SSH mengamankan koneksi dari satu ujung ke yang lain.

Gambar 9.3. Penerusan suatu port lokal dengan SSH

Gambar 9.4. Penerusan suatu port jauh dengan SSH

9.2.2. Memakai Desktop Grafis Jarak Jauh

VNC (Virtual Network Computing) memungkinkan akses remote ke desktop grafis.

Alat ini banyak digunakan untuk bantuan teknis; administrator dapat melihat kesalahan yang dihadapi pengguna, dan menunjukkan kepada mereka tindakan yang benar tanpa harus berdiri di samping mereka.

Pertama, pengguna harus mengotorisasi berbagi sesi mereka. Lingkungan desktop grafis GNOME mencakup opsi itu melalui Pengaturan → Berbagi (bertentangan dengan versi Debian sebelumnya, di mana pengguna harus memasang dan menjalankan vino). Agar ini berfungsi network-manager harus mengelola jaringan yang digunakan (misalnya mengaktifkan mode dikelola untuk perangkat yang ditangani oleh ifupdown di /etc/NetworkManager/NetworkManager.conf). KDE Plasma masih membutuhkan penggunaan krfb untuk memungkinkan berbagi sesi yang ada melalui VNC. Untuk lingkungan desktop grafis lainnya, x11vnc atau tightvncserver perintah (dari paket Debian dengan nama yang sama) atau tigervncserver (tigervnc-standalone-server) melayani tujuan yang sama dan menyediakan paket virtual vnc-server; Anda dapat membuat salah satu dari mereka tersedia untuk pengguna dengan menu eksplisit atau entri desktop.

Ketika sesi grafis dibuat tersedia oleh VNC, administrator harus menyambung ke sana dengan klien VNC. GNOME memiliki vinagre dan remmina untuk itu, sementara KDE menyertakan krdc (pada menu di K → Internet → Klien Remote Desktop). Ada klien VNC lainnya yang menggunakan baris perintah, seperti xtightvncviewer dalam paket Debian dengan nama yang sama atau xtigervncviewer dari tigervnc-viewer. Setelah terhubung, administrator dapat melihat apa yang terjadi, bekerja pada mesin dari jarak jauh, dan menunjukkan ke pengguna bagaimana untuk melanjutkan.

KEAMANAN VNC di atas SSH

Jika Anda ingin terhubung oleh VNC, dan Anda tidak ingin data Anda dikirim dalam bentuk teks polos pada jaringan, mungkin untuk membungkus data dalam tunnel SSH (lihat Bagian 9.2.1.4, “Menciptakan Tunnel Terenkripsi dengan Penerusan Port”). Anda hanya perlu tahu bahwa VNC menggunakan port 5900 secara default untuk layar pertama (disebut "localhost:0"), 5901 untuk kedua (disebut "localhost:1"), dll.

Perintah ssh -L localhost:5901:localhost:5900 -N -T mesin menciptakan sebuah tunnel antara port lokal 5901 di antarmuka localhost dan port 5900 host mesin. "localhost" pertama membatasi SSH untuk mendengarkan hanya pada antarmuka tersebut di komputer lokal. "localhost" kedua menunjukkan antarmuka pada mesin remote yang akan menerima lalu lintas jaringan masuk "localhost:5901". Dengan demikian vncviewer localhost:1 akan menghubungkan klien VNC ke layar remote, meskipun Anda menunjukkan nama dari mesin lokal.

Ketika sesi VNC ditutup, ingatlah untuk menutup tunnel juga dengan menghentikan sesi SSH yang sesuai.