.Bashrc kaynağı olmadan SSH
.bashrcSSH üzerinden bir sunucuya uzaktan oturum açarken dosyamla deneyler yapıyordum . Yanlışlıkla exit, sonraki tüm girişlerin hemen bağlantısının kesilmesine neden olan bir orada bıraktım . Etkin bir şekilde dışarıda kaldım. Kök ayrıcalıklarına sahip birinin müdahalesiyle erişimi kurtarabildim, ancak başka birinin yardımı olmadan mümkün olabilir miydi?
Ben çalışan böyle şeyler yapmaya çalıştı ssh <server> 'bash --norc --noprofile've ssh <server> 'mv .bashrc bashrc-backup'hatta zorla ile üzerine yazmak çalışıyorum scp empty-file <server>:.bashrc. Ancak, tüm bu seçenekler .bashrc, komutu çalıştırmadan önce bozuk olanı tedarik etmeye dayanıyor gibi görünüyor , bu nedenle hiçbiri işe yaramadı.
Bu tür bir durumdan çıkış yolu yok olabilir. Ama bu tasarım gereği mi? Bir sistemi kilitlemenin neden bu kadar kolay olmasının bir nedeni var mı, örneğin sadece çalıştırarak ssh <server> 'echo exit > .bashrc'? Bu tür bir hatayı azaltmanın yolları var mı?
Yanıtlar
Diğer cevapta tartışıldığı gibi, bir SSH istemcisi OpenSSH sunucusuna bağlandığında, OpenSSH sunucusu genellikle kullanıcının oturum açma kabuğunu kullanarak istemci adına bir kabuk oturumu başlatır:
- İstemci etkileşimli bir oturum talep ederse, sunucu kullanıcının oturum açma kabuğunu başlatır.
- İstemci bir komut çalıştırmayı isterse, sunucu komutu bir kabuk komutu olarak çalıştırmak için kullanıcının oturum açma kabuğunu kullanır.
- Kamu ister
scp,rsyncvegitonlar 2. kapsamına giren bu yüzden, uzaktan sistem üzerinde çalıştırılmak üzere bir komut isteyecektir ulaşım için hangi kullanım ssh.
Uzak kullanıcının kabuk başlangıç dosyalarında kabuğun çıkmasına neden olan bir şey varsa, içeri girmekte sorun yaşarsınız.
Ancak SFTP özel bir durumdur. OpenSSH sunucusu , harici bir komut başlatmadan SFTP'yi destekleyecek şekilde yapılandırılabilir. Durum buysa, sunucuya bağlanmak .bashrcve soruna neden olan dosyayı silmek, yeniden adlandırmak veya değiştirmek için sftp'yi kullanabilirsiniz .
Sunucunun sftp'yi destekleyecek şekilde nasıl yapılandırıldığına bağlıdır. Harici bir program (adlandırılmış sftp-server) başlatarak sftp oturumlarına hizmet verebilir . Bu durumda, gibi programlara girerken aynı sorunu yaşarsınız scp. Veya sunucu, sftp oturumuna "internal-sftp" adı verilen ve bir kabuk çağırmayı gerektirmeyen bir şeyle hizmet verebilir . Sadece belirli SSH sunucusunun nasıl yapılandırıldığına bağlıdır.
Bunun olmasının nedeni sshd, sunucu tarafı bileşeninin kabuğunuzu kullanarak işlemleri başlatmasıdır. Etkileşimli bir kabuk oluşturuyorsa, onu bir giriş kabuğu olarak oluşturur; aksi takdirde, -cbelirttiğiniz komutu çalıştırmak üzere etkileşimli olmayan bir kabuk oluşturmak için bağımsız değişkeni kullanır .
Belirttiğiniz tüm işlemler (belirtilen komutlar ve scp) etkileşimli olmayan işlemlerdir, bu nedenle normalde bash yüklenmez .bashrc, ancak bash tarafından sshdyine de çağırmak için çağrıldığında özel-büyük / küçük harf vardır . Zsh kullanıyorsanız, .zshenv(tüm kabuklar için çağrılan) yüklenir, ancak .zshrc(yalnızca etkileşimli kabuklar için), özellikle bir kabuk oturumu yüklemediğiniz sürece yüklenmez.
Bu durumda, bash kullanıyorsanız şansınız kalmaz. Kabuğu kullanmadan sunucu tarafında bir SSH komutunu çağırmanın herhangi bir yolu yoktur; bu scp ve sftp için bile geçerlidir. Çoğu zaman, PATHçeşitli programlar gibi şeyler ayarladığı için kabuğu kullanmak istersiniz ve karmaşık komutların makul miktarda komut dosyası yazılmasına izin verir, bu nedenle OpenSSH her zaman kullanır.
Bunun bazı güvenlik avantajları da vardır: Bir şekilde geçerli bir parolası olan ancak /usr/sbin/nologinveya kabuğu olan bir sistem hesabına giriş yapmaya çalışırsanız /bin/false, hiçbir şey yapamazsınız, muhtemelen sistem yöneticisinin istediği şey budur.
Bunu azaltmanın yolları var. Pek çok kişi, dot dosyalarından oluşan bir Git deposunu tutar ve bunları bir sistemde geliştirir, ardından bunları diğerlerine dağıtır. Örneğin, dizüstü bilgisayarımda her zaman dotfile geliştirme yapıyorum. Muhtemelen, yeni bir terminal penceresi açtığınızda hemen çıkarsa, bu sorunu biraz daha erken fark edersiniz ve bunu kendiniz düzeltmek için root erişiminiz olabilir.
Kabuk yapılandırması veya bir sudoersdeğişiklik gibi sizi kilitleyebilecek bir yapılandırmayı test etmeniz gerekirse, bir kabuğu (sırasıyla normal veya kök) açık bırakabilir ve sonra bazı testler yapabilirsiniz, böylece bir şeyi kırarsanız, hala bir geri almak için bir yol.