Akses Awal dan Administrasi Remote

Instalasi Ubuntu Server 26.04 LTS sudah selesai di bab sebelumnya. Pertanyaan berikutnya sederhana: bagaimana cara kita mengakses server ini setiap hari? Server bukan laptop yang selalu ada di depan mata. Server biasanya duduk di rak data center, di cloud provider, atau di mesin virtual yang jauh dari meja kerja kita. Oleh karena itu, kita perlu jalur akses remote yang aman dan efisien sebelum masuk ke pembahasan konfigurasi lainnya.

Bab ini membahas tiga hal besar: login pertama ke server, SSH sebagai pintu utama administrasi, dan manajemen sesi remote agar pekerjaan kita tetap efisien walau koneksi terputus. Kita tutup dengan pembahasan console akses sebagai jalur darurat ketika SSH bermasalah.

3.1 Login Pertama ke Server

Begitu proses instalasi selesai dan server reboot, layar login berbasis teks akan menyambut kita. Di sinilah kita memakai akun yang kita buat saat instalasi lewat Subiquity di Chapter 2. Untuk mesin virtual, login pertama ini biasanya dilakukan lewat console bawaan hypervisor (VirtualBox, KVM, atau console VM dari cloud provider). Untuk server fisik, kita login lewat monitor dan keyboard yang tersambung langsung, atau lewat console jarak jauh semacam IPMI/iDRAC/iLO jika hardware pendukungnya tersedia.

Login pertama ini sifatnya sementara. Tujuan kita adalah mengambil informasi dasar dan memastikan server siap diakses lewat SSH, supaya sesi console tidak perlu dipakai lagi untuk pekerjaan sehari-hari.

Langkah Praktik

1. Login dengan username dan password yang dibuat saat instalasi.
2. Cek hostname server untuk memastikan konfigurasi awal sudah benar.

   hostnamectl

3. Cek alamat IP yang didapat server, karena inilah alamat yang nanti dipakai untuk SSH dari komputer kita.

   ip a

   Perhatikan interface utama (biasanya enp0s3, eth0, atau nama serupa) dan catat alamat IPv4-nya.
4. Perbarui daftar package dan sistem sebelum melangkah lebih jauh. Ini kebiasaan wajib setiap kali server baru pertama kali dinyalakan.

   sudo apt update
   sudo apt upgrade -y

5. Pastikan openssh-server sudah terpasang. Jika kita mencentang opsi "Install OpenSSH server" saat instalasi Subiquity, paket ini seharusnya sudah ada.

   dpkg -l | grep openssh-server

   Jika belum muncul, pasang secara manual.

   sudo apt install openssh-server -y

Verifikasi dan Troubleshooting

• Output hostnamectl harus menampilkan hostname yang sesuai dengan yang kita tentukan saat instalasi. Hostname kosong atau masih bernama localhost menandakan konfigurasi awal belum sepenuhnya berhasil.
• Jika ip a tidak menampilkan alamat IPv4 pada interface utama, server kemungkinan belum mendapat alamat dari DHCP, atau adapter jaringan virtual belum terhubung dengan benar. Cek pengaturan network adapter di hypervisor (untuk VM) sebelum melangkah lebih jauh.
• Pastikan baris hasil dpkg -l | grep openssh-server diawali kode status ii. Kode ini menandakan paket sudah terpasang penuh. Jika tidak ada baris yang muncul sama sekali, paket openssh-server memang belum terpasang dan perlu dipasang manual seperti langkah di atas.

Setelah alamat IP dan status SSH dipastikan, kita bisa menutup sesi console dan lanjut mengakses server lewat SSH dari komputer kita sendiri. Console tetap berguna sebagai jalur darurat, dan kita akan bahas secara lebih detail di bagian akhir bab ini.

3.2 SSH sebagai Pintu Utama Administrasi

Bayangkan server sebagai gedung kantor. Console akses yang kita pakai barusan itu seperti pintu belakang yang hanya bisa dibuka jika kita berdiri tepat di depannya. SSH adalah pintu utama, satu-satunya jalur yang dipakai untuk masuk dan keluar setiap hari, baik oleh kita sebagai Sysadmin maupun oleh Developer yang butuh deploy aplikasi. Karena statusnya sebagai pintu utama, SSH juga menjadi target nomor satu bagi Attacker yang mencoba masuk lewat brute force atau celah konfigurasi yang longgar.

SSH (Secure Shell) adalah protokol yang memungkinkan kita mengakses shell server dari jarak jauh melalui koneksi terenkripsi. Di sisi server, protokol ini dijalankan oleh daemon bernama sshd, yang dikelola lewat unit systemd bernama ssh.

Langkah Praktik: Menyalakan dan Memeriksa Layanan SSH

1. Aktifkan layanan SSH agar otomatis berjalan saat boot.

   sudo systemctl enable ssh

2. Periksa status layanan.

   sudo systemctl status ssh

   Jika layanan belum jalan, jalankan secara manual.

   sudo systemctl start ssh

3. Di Ubuntu Server 26.04, SSH memakai socket activation secara default. Artinya, unit ssh.socket yang mengontrol port berapa SSH mendengarkan koneksi masuk, bukan langsung sshd itu sendiri. Periksa statusnya.

   systemctl status ssh.socket

   Jika statusnya active (listening), berarti socket activation sedang aktif. Detail ini penting nanti saat kita mengganti port SSH.

Dari komputer kita, coba login ke server memakai alamat IP yang sudah dicatat sebelumnya.

ssh username@alamat_ip_server

3.2.1 Konfigurasi sshd_config

Konfigurasi utama SSH server tersimpan di /etc/ssh/sshd_config. Daripada langsung mengubah file ini, kebiasaan yang lebih aman dan lebih rapi adalah menaruh perubahan kita di direktori /etc/ssh/sshd_config.d/. File di dalam direktori ini dimuat lebih dulu sebelum sshd_config utama, sehingga kita bisa memisahkan pengaturan hardening kita sendiri dari konfigurasi bawaan sistem tanpa harus mengedit file aslinya.

Buat file konfigurasi baru untuk keperluan hardening.

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Nama file diawali angka 00- supaya file ini dibaca paling awal dibanding file lain di direktori yang sama. Sebelum menerapkan perubahan apa pun, selalu validasi sintaks konfigurasi terlebih dahulu.

sudo sshd -t

Jika tidak ada output yang tampil, berarti konfigurasi valid dan aman untuk diterapkan.

3.2.2 Autentikasi Berbasis Key vs Password

Password mudah ditebak lewat brute force, apalagi jika password yang dipakai lemah. Autentikasi berbasis key pair jauh lebih aman karena memakai sepasang kunci kriptografi: private key yang kita simpan rahasia di komputer sendiri, dan public key yang kita taruh di server.

Langkah Praktik

1. Di komputer kita (bukan di server), buat key pair baru. Algoritma ed25519 menjadi pilihan standar karena ringkas, cepat, dan aman.

   ssh-keygen -t ed25519 -C "[email protected]"

   Tekan Enter untuk memakai lokasi default, lalu isi passphrase untuk mengamankan private key kita. Passphrase ini opsional, tetapi sangat disarankan.
2. Salin public key ke server.

   ssh-copy-id username@alamat_ip_server

   Perintah ini akan meminta password server untuk terakhir kalinya, lalu menaruh isi public key kita ke ~/.ssh/authorized_keys di server.
3. Uji login tanpa password.

   ssh username@alamat_ip_server

   Jika berhasil masuk tanpa diminta password server (hanya passphrase key jika kita mengisinya), autentikasi berbasis key sudah berjalan.

3.2.3 Menonaktifkan Root Login dan Password Login

Setelah login berbasis key terbukti berjalan, kita bisa menutup dua celah paling umum: login root langsung lewat SSH, dan autentikasi berbasis password. Tambahkan baris berikut ke /etc/ssh/sshd_config.d/00-hardening.conf yang sudah kita buat.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

PermitRootLogin no memaksa siapa pun yang butuh akses administratif untuk login sebagai user biasa lalu naik privilege lewat sudo, bukan login langsung sebagai root. PasswordAuthentication no menutup jalur login memakai password, sehingga hanya key yang terdaftar di authorized_keys yang bisa dipakai masuk.

Sebelum restart layanan, validasi terlebih dahulu.

sudo sshd -t

Jangan pernah menutup sesi SSH yang sedang aktif sebelum memverifikasi konfigurasi baru berhasil. Buka jendela terminal baru untuk mencoba login, dan biarkan sesi lama tetap terbuka sebagai jalur cadangan jika ada kesalahan konfigurasi.

sudo systemctl restart ssh

Coba login dari terminal baru. Jika berhasil masuk memakai key dan percobaan login sebagai root ditolak, konfigurasi sudah berjalan sesuai rencana.

3.2.4 Port Kustom dan Pertimbangan Keamanan

Mengganti port default SSH dari 22 ke port lain bukan pengganti hardening di atas, tetapi bisa mengurangi jumlah percobaan login otomatis dari bot yang menyisir port 22 di internet. Ini murni soal mengurangi kebisingan log, bukan langkah keamanan utama.

Karena Ubuntu Server 26.04 memakai socket activation untuk SSH, mengubah baris Port di sshd_config saja tidak cukup. Unit ssh.socket tetap akan mendengarkan di port 22 selama override socket belum dibuat. Berikut langkah yang benar.

Langkah Praktik

1. Buat override untuk unit ssh.socket.

   sudo systemctl edit ssh.socket

2. Isi editor yang terbuka dengan konfigurasi berikut, ganti 2222 sesuai port pilihan kita.

   [Socket]
   ListenStream=
   ListenStream=0.0.0.0:2222
   ListenStream=[::]:2222

   Baris ListenStream= kosong di awal berfungsi menghapus pengaturan port 22 bawaan sebelum menambahkan port baru.
3. Muat ulang konfigurasi systemd dan restart socket.

   sudo systemctl daemon-reload
   sudo systemctl restart ssh.socket

4. Izinkan port baru di firewall sebelum memutus koneksi lama.

   sudo ufw allow 2222/tcp comment 'SSH custom port'

5. Uji koneksi dari port baru.

   ssh -p 2222 username@alamat_ip_server

6. Setelah port baru terbukti berjalan, baru hapus aturan firewall untuk port 22 jika memang tidak dipakai lagi.

   sudo ufw delete allow 22/tcp

Verifikasi dan Troubleshooting

• Cek port yang sedang didengarkan SSH.

  sudo ss -tlnp | grep ssh

• Cek konfigurasi efektif yang sedang berjalan di sshd.

  sudo sshd -T | grep -E "^(port|passwordauthentication|permitrootlogin)"

• Connection refused biasanya berarti layanan ssh atau ssh.socket belum aktif, atau firewall memblokir port yang dituju.
• Permission denied (publickey) biasanya berarti public key belum ada di authorized_keys server, atau permission folder .ssh terlalu longgar. Pastikan permission-nya benar.

  chmod 700 ~/.ssh
  chmod 600 ~/.ssh/authorized_keys

• Jika terlanjur terkunci akibat kesalahan konfigurasi, jangan panik. Bagian 3.4 di bawah membahas jalur darurat lewat console akses.

3.3 Manajemen Sesi Remote

Koneksi SSH mudah terputus, entah karena WiFi goyah, laptop kita masuk mode sleep, atau koneksi internet kantor terputus sesaat. Jika kita sedang menjalankan proses panjang seperti instalasi paket besar atau migrasi database, proses itu ikut terhenti begitu koneksi SSH terputus. Di sinilah terminal multiplexer berperan.

3.3.1 tmux/screen untuk Sesi Persisten

tmux dan screen adalah tool yang membuat sesi terminal kita tetap berjalan di server meskipun koneksi SSH terputus. Sesi ini bisa kita tinggalkan (detach) lalu sambungkan kembali (reattach) kapan saja, bahkan dari komputer yang berbeda.

Langkah Praktik: tmux

1. Pasang tmux jika belum tersedia.

   sudo apt install tmux -y

2. Buat sesi baru dengan nama tertentu, supaya mudah dikenali nanti.

   tmux new -s deploy

3. Jalankan proses seperti biasa di dalam sesi ini.
4. Untuk keluar tanpa menghentikan sesi, tekan Ctrl+b lalu d.
5. Jika koneksi SSH terputus atau kita sengaja detach, sesi tetap berjalan di server. Untuk melihat daftar sesi yang aktif:

   tmux ls

6. Sambungkan kembali ke sesi yang sama.

   tmux attach -t deploy

7. Untuk mengakhiri sesi sepenuhnya, bukan sekadar detach, ketik exit di dalam sesi tersebut, atau hentikan dari luar sesi.

   tmux kill-session -t deploy

Di lapangan, memberi nama sesi yang jelas seperti deploy, backup-db, atau migrasi-app sangat membantu ketika ada banyak sesi tmux berjalan bersamaan di satu server. Nama generik seperti angka default dari tmux gampang membingungkan saat kita perlu reattach cepat di tengah insiden.

screen punya konsep serupa dan masih banyak dipakai di server lama.

sudo apt install screen -y
screen -S deploy

Detach dari sesi screen memakai Ctrl+a lalu d, dan reattach memakai screen -r deploy. Untuk mengakhiri sesi screen sepenuhnya, ketik exit di dalam sesi, atau jalankan screen -X -S deploy quit dari luar sesi.

3.3.2 Transfer File: scp, sftp, rsync

Selain menjalankan perintah, pekerjaan Sysadmin sehari-hari juga sering melibatkan pemindahan file antara komputer kita dan server, misalnya mengunggah file konfigurasi atau mengunduh hasil backup.

scp cocok untuk transfer file tunggal yang cepat dan sederhana.

scp laporan.txt username@alamat_ip_server:/home/username/

sftp membuka sesi interaktif mirip FTP tetapi berjalan di atas SSH, cocok jika kita perlu menjelajah struktur folder server sebelum memutuskan file mana yang perlu diunggah atau diunduh.

sftp username@alamat_ip_server

Di dalam sesi sftp, kita bisa memakai perintah seperti ls, cd, get nama_file untuk mengunduh, dan put nama_file untuk mengunggah.

rsync menjadi pilihan terbaik untuk sinkronisasi folder besar atau backup rutin, karena hanya mengirim bagian file yang berubah, bukan seluruh file dari awal.

rsync -avz -e ssh /path/lokal/ username@alamat_ip_server:/path/tujuan/

Opsi -a menjaga atribut file seperti permission dan timestamp, -v menampilkan detail proses, dan -z mengompresi data selama transfer.

Verifikasi dan Troubleshooting

• Jika tmux attach -t deploy menampilkan pesan no server running on ..., sesi itu sudah tidak ada, biasanya karena server sempat reboot atau sesi memang sudah dihentikan sebelumnya. Semua proses yang berjalan di dalamnya ikut berhenti.
• Proses di dalam sesi tmux/screen bisa berhenti sendiri walau sesinya tetap hidup, misalnya karena aplikasi di dalamnya crash. Cek log aplikasi yang bersangkutan, jangan asumsikan sesi yang aktif berarti prosesnya juga masih berjalan normal.
• scp atau rsync yang gagal dengan pesan Permission denied biasanya berarti user yang kita pakai tidak punya izin tulis di folder tujuan. Pastikan path tujuan memang bisa diakses oleh user tersebut.
• Jika rsync gagal dengan pesan command not found, paket rsync belum terpasang di sisi server. Pasang terlebih dahulu.

  sudo apt install rsync -y

3.4 Console Akses Sebagai Fallback

Bagaimana jika SSH sampai tidak bisa diakses sama sekali, misalnya karena kesalahan konfigurasi sshd_config.d yang menutup semua jalur masuk? Di sinilah console akses kembali berguna, bukan sebagai jalur harian, melainkan sebagai jalur darurat.

Untuk mesin virtual, kita bisa masuk lewat console bawaan hypervisor seperti VirtualBox atau virt-manager untuk KVM. Untuk server di cloud, sebagian besar provider menyediakan web console atau serial console lewat dashboard mereka, yang tetap bisa diakses walau SSH mati total.

Lewat console ini, kita bisa masuk sebagai user biasa (atau lewat mode recovery jika perlu), lalu memperbaiki file konfigurasi yang bermasalah.

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Setelah perbaikan, validasi ulang dan restart layanan SSH seperti biasa sebelum mencoba login remote lagi.

sudo sshd -t
sudo systemctl restart ssh

Kebiasaan menguji setiap perubahan konfigurasi SSH di sesi terpisah sebelum menutup sesi lama, seperti yang kita lakukan di bagian 3.2.3, adalah cara paling efektif mencegah kita sampai membutuhkan jalur darurat ini. Namun, jika situasi terlanjur terjadi, sekarang kita tahu jalan keluarnya.