SSH tanpa sumber .bashrc
Saya sedang bereksperimen dengan .bashrcfile saya saat masuk dari jarak jauh ke server melalui SSH. Saya secara tidak sengaja meninggalkannya exitdi sana yang menyebabkan semua proses masuk berikutnya segera terputus. Saya secara efektif dikunci. Saya dapat memulihkan akses dengan intervensi dari seseorang dengan hak akses root, tetapi apakah itu mungkin tanpa bantuan dari orang lain?
Saya mencoba melakukan hal-hal seperti berlari ssh <server> 'bash --norc --noprofile'dan ssh <server> 'mv .bashrc bashrc-backup', dan bahkan mencoba menimpanya secara paksa scp empty-file <server>:.bashrc. Namun, semua opsi ini tampaknya mengandalkan sumber yang rusak .bashrcterlebih dahulu sebelum menjalankan perintah, jadi tidak ada yang berfungsi.
Mungkin saja tidak ada jalan keluar dari situasi seperti ini. Tapi apakah itu memang sengaja? Adakah alasan mengapa begitu mudah untuk mengunci diri sendiri dari suatu sistem, misalnya hanya dengan menjalankan ssh <server> 'echo exit > .bashrc'? Adakah cara untuk mengurangi kesalahan semacam ini?
Jawaban
Seperti yang dibahas dalam jawaban lain, ketika klien SSH terhubung ke server OpenSSH, server OpenSSH umumnya akan memulai sesi shell atas nama klien, menggunakan shell login pengguna:
- Jika klien meminta sesi interaktif, server akan meluncurkan shell login pengguna.
- Jika klien meminta untuk menjalankan perintah, server akan menggunakan shell login pengguna untuk menjalankan perintah sebagai perintah shell.
- Utilitas seperti
scp,,rsyncdangityang menggunakan ssh untuk transportasi akan meminta perintah untuk dijalankan pada sistem jarak jauh, sehingga mereka termasuk dalam # 2.
Jika Anda memiliki sesuatu di file startup shell pengguna jarak jauh yang menyebabkan shell keluar, maka Anda akan kesulitan untuk masuk.
Namun SFTP adalah kasus khusus. Server OpenSSH dapat dikonfigurasi untuk mendukung SFTP tanpa meluncurkan perintah eksternal. Jika itu masalahnya, maka Anda dapat menggunakan sftp untuk terhubung ke server dan menghapus, mengganti nama, atau mengubah .bashrcfile yang menyebabkan masalah.
Itu tergantung pada bagaimana server dikonfigurasi untuk mendukung sftp. Itu dapat melayani sesi sftp dengan meluncurkan program eksternal (bernama sftp-server). Dalam hal ini Anda akan memiliki masalah yang sama seperti yang Anda alami dengan program sejenis scp. Atau, server dapat melayani sesi sftp dengan sesuatu yang disebut "internal-sftp" , yang tidak memerlukan pemanggilan shell. Itu hanya tergantung pada bagaimana server SSH tertentu dikonfigurasi.
Alasan ini terjadi adalah karena sshd, komponen sisi server, menjalankan proses menggunakan shell Anda. Jika ia menelurkan shell interaktif, ia menelurkannya sebagai shell login; jika tidak, ia menggunakan -cargumen untuk menelurkan shell non-interaktif untuk menjalankan perintah yang Anda tentukan.
Semua operasi yang Anda tentukan (perintah tertentu dan scp) adalah operasi non-interaktif, jadi biasanya bash tidak akan dimuat .bashrc, tetapi bash memiliki casing khusus untuk saat dipanggil oleh sshdsehingga tetap memanggilnya. Jika Anda menggunakan zsh, maka .zshenv(yang dipanggil untuk semua shell) akan dimuat, tetapi .zshrc(yang hanya untuk shell interaktif) tidak akan dimuat kecuali Anda secara khusus memuat sesi shell.
Dalam hal ini, jika Anda menggunakan bash, Anda kurang beruntung. Tidak ada cara untuk menjalankan perintah SSH di sisi server tanpa menggunakan shell; ini berlaku bahkan untuk scp dan sftp. Sebagian besar waktu, Anda ingin menggunakan shell karena itu mengatur hal-hal seperti PATHuntuk berbagai program, dan itu memungkinkan sejumlah skrip perintah kompleks yang wajar, jadi OpenSSH selalu menggunakannya.
Ini juga memiliki beberapa keuntungan keamanan: jika Anda mencoba masuk ke akun sistem yang entah bagaimana memiliki kata sandi yang valid tetapi memiliki cangkang /usr/sbin/nologinatau /bin/false, maka Anda tidak dapat melakukan apa pun, yang mungkin dimaksudkan oleh administrator sistem.
Ada cara untuk menguranginya. Banyak orang menyimpan repositori Git dari dotfile mereka dan mengembangkannya di satu sistem, lalu menerapkannya ke sistem lain. Misalnya, saya selalu melakukan pengembangan dotfile di laptop saya. Agaknya Anda akan melihat masalah ini sedikit lebih cepat jika setiap kali Anda membuka jendela terminal baru, jendela itu langsung keluar, dan Anda mungkin memiliki akses root untuk memperbaikinya sendiri.
Jika Anda perlu menguji konfigurasi yang mungkin mengunci Anda, seperti konfigurasi shell atau sudoersperubahan, Anda dapat membiarkan satu shell (normal atau root, masing-masing) terbuka dan kemudian melakukan beberapa pengujian, jadi jika Anda merusak sesuatu, Anda masih memiliki cara untuk membatalkannya.