Cara Mengatasi Server Refused to Allocate PTY dan Error SSH

Mengelola VPS atau dedicated server biasanya lancar-lancar saja, sampai tiba-tiba Anda terkunci dari terminal sendiri. Jika Anda membaca ini, kemungkinan besar layar SSH Anda sedang macet, ketikan tidak terbaca, atau muncul error izin akses yang aneh, dan Anda mulai panik. Tenang! Anda tidak sendirian, dan yang lebih penting, server Anda tidak rusak total. Dalam panduan teknis ini, saya akan menunjukkan cara cepat memperbaikinya dari jarak jauh untuk mengatasi error ‘Server refused to allocate pty’ yang menjengkelkan, sehingga command line Anda bisa kembali berfungsi dalam hitungan menit

Cara Mengatasi “Server Refused to Allocate PTY” dan Terminal SSH yang Macet

Pernahkah Anda berhasil login ke VPS lewat SSH, tetapi tidak bisa mengetik satu perintah pun? Terminal membeku, teks yang Anda ketik turun berundak seperti anak tangga, dan Anda mungkin melihat serangkaian error seperti ini:

/etc/profile: line 70: /dev/null: Permission denied

Atau lebih parah lagi, klien SSH Anda menolak dengan tegas:

PTY allocation request failed on channel 0 Server refused to allocate pty

Jangan panik. Server Anda tidak mati total, dan Anda belum tentu perlu menginstal ulang OS. Ini masalah umum yang disebabkan izin akses yang hilang atau rusak pada device node sistem Linux Anda, khususnya /dev/null dan /dev/ptmx.

Karena Anda tidak bisa berinteraksi dengan server dari dalam, Anda perlu memaksakan perbaikan dari luar. Berikut panduan lengkap untuk menyelesaikannya.

Memahami Masalahnya: Mengapa Terminal Membeku?

Untuk memahami perbaikannya, Anda perlu tahu apa yang rusak. Saat Anda terhubung lewat SSH, server Linux memberi Anda Pseudo-Terminal (PTY), yaitu layar virtual yang menjembatani ketikan Anda dengan shell server.

• /dev/ptmx (Pseudo-Terminal Master Multiplexer): File ini bertugas membuat terminal virtual tersebut. Jika izin aksesnya berubah atau file ini terhapus tanpa sengaja, server tidak bisa membuat antarmuka terminal untuk Anda, sehingga muncul error “Server refused to allocate pty”.

• /dev/null (Lubang Hitam): Di sinilah skrip Linux membuang output yang tidak diinginkan. Saat login, skrip latar belakang (seperti /etc/bashrc atau /etc/profile) mencoba menulis ke /dev/null. Jika izin file ini rusak, skrip-skrip tersebut gagal terus-menerus dan menyebabkan loop permission denied yang membuat shell membeku total.

Solusinya: Menjalankan Perintah Jarak Jauh lewat SSH

Karena shell interaktif Anda rusak, kita harus melewatinya. Kita akan memakai SSH untuk mengirim perintah langsung ke server tanpa meminta antarmuka terminal.

Tutup sesi SSH Anda yang macet (misalnya PuTTY atau terminal lokal Anda). Buka Command Prompt, PowerShell, atau Terminal lokal yang baru di komputer Anda, lalu jalankan dua langkah berikut.

Langkah 1: Pulihkan Izin /dev/null

Pertama, kita perlu menghentikan kegagalan skrip latar belakang dengan membuat ulang /dev/null dalam format yang benar dan izin tulis untuk semua pengguna.

Jalankan perintah berikut dari komputer lokal Anda. (Catatan: Ganti user, YOUR_SERVER_IP, dan YOUR_PASSWORD dengan kredensial server Anda yang sebenarnya).

ssh user@YOUR_SERVER_IP "echo 'YOUR_PASSWORD' | sudo -S su -c 'rm -f /dev/null && mknod -m 0666 /dev/null c 1 3'"

Fungsinya: Kita mengirim password Anda dengan aman ke sudo -S agar perintah berjalan dengan hak akses root tanpa meminta input di layar yang rusak. Perintah ini menghapus paksa file /dev/null yang rusak dan memakai mknod untuk membuatnya kembali sebagai file character device (c 1 3) dengan izin baca/tulis terbuka (0666).

Langkah 2: Perbaiki /dev/ptmx dan Mount Terminal

Setelah skrip-skrip tidak lagi error, kita perlu memperbaiki pengalokasi terminal agar Anda bisa mengetik lagi. Jalankan perintah kedua ini dari komputer lokal Anda:

ssh user@YOUR_SERVER_IP "echo 'YOUR_PASSWORD' | sudo -S su -c 'rm -f /dev/ptmx && mknod -m 666 /dev/ptmx c 5 2 && chmod 666 /dev/ptmx && mount -t devpts devpts /dev/pts'"

Fungsinya: Mirip langkah pertama, perintah ini menghapus file /dev/ptmx yang rusak dan membangunnya kembali (c 5 2). Kita menetapkan izin 666 agar semua pengguna bisa meminta terminal. Terakhir, mount -t devpts me-mount filesystem pseudo-terminal, yaitu bagian terakhir yang dibutuhkan agar command line Anda tampil dengan benar.

Pembersihan dan Praktik Terbaik Keamanan

Tunggu beberapa detik sampai perintah selesai dijalankan. Setelah Anda kembali ke command prompt lokal, buka klien SSH dan login seperti biasa. Server Anda seharusnya sudah responsif sepenuhnya.

Langkah Keamanan Penting Setelah Perbaikan:

1. Hapus Riwayat Lokal Anda: Karena Anda memasukkan password sebagai teks biasa di command line, password itu kini tersimpan di riwayat terminal lokal Anda. Hapus riwayat bash lokal (history -c) atau segera ganti password admin server Anda.

2. Perkuat Konfigurasi SSH Anda: Kerusakan file sistem seperti ini kadang merupakan akibat serangan otomatis atau skrip yang berantakan. Periksa log server Anda untuk upaya brute-force. Jika belum, ganti port SSH default dari 22 ke port khusus, nonaktifkan autentikasi password dan beralih ke SSH Keys, serta instal Fail2Ban untuk memblokir alamat IP berbahaya secara otomatis.

Menghadapi error ‘Server refused to allocate pty’ atau ‘/dev/null permission denied’ bisa terasa seperti mimpi buruk sysadmin, apalagi saat Anda benar-benar terkunci dari shell. Namun, dengan melewati terminal interaktif dan menjalankan dua perintah SSH jarak jauh tadi, Anda bisa memulihkan device node dan mendapatkan kembali akses penuh tanpa perlu menginstal ulang OS.

Apakah panduan ini menyelamatkan server Anda dari reboot paksa? Atau Anda punya trik lain untuk menangani sesi SSH yang macet? Beri tahu saya di kolom komentar di bawah, dan jangan lupa bookmark halaman ini untuk kebutuhan administrasi sistem Anda berikutnya!