.bashrcを調達せずにSSH

Sep 14 2020

.bashrcSSH経由でサーバーにリモートログインしているときにファイルを試していました。私はうっかりexitそこに残してしまい、その後のすべてのログインがすぐに切断されました。私は事実上締め出されました。root権限を持つ人の介入でアクセスを回復できましたが、他の人の助けがなくても可能でしたか？

実行ssh <server> 'bash --norc --noprofile'やなどを実行ssh <server> 'mv .bashrc bashrc-backup'してみましたが、強制的にscp empty-file <server>:.bashrc。で上書きしようとしました。ただし、これらのオプションはすべて.bashrc、コマンドを実行する前に最初に壊れたものを調達することに依存しているように見えるため、いずれも機能しませんでした。

このような状況から抜け出す方法がないのも事実かもしれません。しかし、それは仕様によるものですか？実行するだけで、システムをロックアウトするのがとても簡単な理由はありssh <server> 'echo exit > .bashrc'ますか？この種の間違いを軽減する方法はありますか？

回答

2 Kenster Sep 14 2020 at 08:43

他の回答で説明したように、SSHクライアントがOpenSSHサーバーに接続すると、OpenSSHサーバーは通常、ユーザーのログインシェルを使用して、クライアントに代わってシェルセッションを開始します。

クライアントが対話型セッションを要求すると、サーバーはユーザーのログインシェルを起動します。
クライアントがコマンドの実行を要求した場合、サーバーはユーザーのログインシェルを使用して、コマンドをシェルコマンドとして実行します。
などのユーティリティscp、rsyncおよびgitその使用の輸送のためにssh彼らは＃2に該当して、リモートシステム上で実行するコマンドを要求します。

リモートユーザーのシェル起動ファイルにシェルを終了させる何かがある場合は、問題が発生します。

ただし、SFTPは特殊なケースです。OpenSSHサーバーは、外部コマンドを起動せずにSFTPをサポートするように構成できます。場合はそれが事実だ、あなたは、サーバーに接続して、削除、名前変更、または変更するためにSFTPを使用することができるだろう.bashrc、問題の原因となっているファイルを。

これは、サーバーがsftpをサポートするように構成されている方法によって異なります。（という名前のsftp-server）外部プログラムを起動することにより、sftpセッションを処理できます。この場合、のようなプログラムで発生するのと同じ問題が発生しますscp。または、サーバーは「internal-sftp」と呼ばれるものによってsftpセッションを処理できます。これは、シェルを呼び出す必要がありません。特定のSSHサーバーがどのように構成されているかによって異なります。

bk2204 Sep 14 2020 at 03:07

これが発生する理由sshdは、サーバー側コンポーネントがシェルを使用してプロセスを呼び出すためです。インタラクティブシェルを生成している場合は、ログインシェルとして生成します。それ以外の場合は、-c引数を使用して非対話型シェルを生成し、指定したコマンドを実行します。

指定したすべての操作（指定したコマンドとscp）は非対話型の操作であるため、通常はbashは読み込まれません.bashrcが、bashはによって呼び出されたときに特別な大文字と小文字が区別されるsshdため、とにかく呼び出されます。zshを使用している場合、.zshenv（すべてのシェルに対して呼び出される）がロードされますが、.zshrc（インタラクティブシェルに対してのみ）シェルセッションを特にロードしない限り、ロードされません。

この場合、bashを使用していると、運が悪くなります。シェルを使用せずにサーバー側でSSHコマンドを呼び出す方法はありません。これは、scpおよびsftpにも当てはまります。ほとんどの場合、シェルPATHはさまざまなプログラムなどをセットアップし、複雑なコマンドの適度な量のスクリプトを実行できるため、シェルを使用する必要があります。そのため、OpenSSHは常にシェルを使用します。

これには、セキュリティ上の利点もいくつかあります。有効なパスワードを持っているが、/usr/sbin/nologinまたはのシェルを持つシステムアカウントにログインしようとすると、/bin/false何もできなくなります。これは、おそらくシステム管理者が意図したことです。

これを軽減する方法があります。多くの人は、ドットファイルのGitリポジトリを保持し、1つのシステムで開発してから、他のシステムにデプロイします。たとえば、私は常にラップトップでドットファイルの開発を行っています。おそらく、新しいターミナルウィンドウを開いたときにすぐに終了し、自分で修正するためのルートアクセス権を持っている場合は、この問題に少し早く気付くでしょう。

シェル構成やsudoers変更など、ロックアウトする可能性のある構成をテストする必要がある場合は、1つのシェル（それぞれ通常またはルート）を開いたままにしてからテストを行うことができるため、何かを壊した場合でも、それを元に戻す方法。