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

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

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 is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

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.

The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.

If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with 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. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also Bagian 10.2.2, “Infrastruktur Kunci Publik: easy-rsa”) by using the TrustedUserCAKeys and HostCertificate directives in /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

Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).

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

Both, public key and certificate authentication, can be used alongside each other.

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.

GOING FURTHER Magic cookies in .Xauthority

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

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.

First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via Settings → Sharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

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.