sudo
を設定しました パスワードなしで実行しますが、 ssh'sudo Foo'
を実行しようとすると 、まだエラーメッセージ sudoが表示されます:申し訳ありませんが、sudoを実行するにはttyが必要です
。
なぜこれが発生し、どうすれば回避できますか?
承認された回答:
これはおそらく、 / etc / sudoers
が原因です。 ファイル(またはそれに含まれるファイル)には次のものがあります:
Defaults requiretty
…これにより、 sudo
TTYが必要です。 Red Hatシステム(RHEL、Fedora…)は、デフォルトの sudoers
でTTYを必要とすることが知られています。 ファイル。これは実際のセキュリティ上の利点を提供せず、安全に削除できます。
Red Hatはこの問題を認識しており、将来のリリースで削除される予定です。
サーバーの構成を変更することができない場合は、その構成ミスの回避策として、 -t
を使用できます。 または-tt
ssh
のオプション これはリモート側に疑似端末を生成しますが、いくつかの副作用があることに注意してください。
-tt
インタラクティブな使用を目的としています。ローカル端末をraw
に配置します リモート端末と対話するためのモード。つまり、 ssh
I / Oは端末との間ではないため、副作用が発生します。たとえば、すべての入力がエコーバックされ、特殊な端末文字( ^?
、 ^ C
、 ^ U
)特別な処理が発生します。出力時に、 LF
sはCRLF
に変換されます s…(このバイナリファイルが変更される理由に対するこの回答を参照してください。 詳細については。
影響を最小限に抑えるために、次のように呼び出すことができます:
ssh -tt host 'stty raw -echo; sudo ...' < <(cat)
<<(猫)コード>
raw
でのローカル端末(存在する場合)の設定を回避します モード。そして、 stty raw -echo
を使用しています リモート端末の回線規律をパススルーとして設定します(事実上、 -tt
のない疑似端末の代わりに使用されるパイプのように動作します。 、ただし、それはそのコマンドが実行された後にのみ適用されるため、それが発生するまで入力用の何かの送信を遅らせる必要があります。
リモートコマンドの出力は端末に送信されるため、 TCP_NODELAY
以降、そのバッファリング(多くのアプリケーションではラインベースになります)と帯域幅効率に影響を与えることに注意してください。 オンになっています。 -tt
も使用 、 ssh
IPQoSをlowdelay
に設定します スループット
とは対照的に 。次の方法で両方を回避できます:
ssh -o IPQoS=throughput -tt host 'stty raw -echo; sudo cmd | cat' < <(cat)
また、リモートコマンドがそのstdinでファイルの終わりを検出できず、リモートコマンドのstdoutとstderrが単一のストリームにマージされることを意味することに注意してください。
関連:Debian – Debian 9 Stretchでのログイン時にユーザーとパスワードを削除しますか?ですから、結局のところ、あまり良い回避策ではありません。
リモートホスト上に疑似端末を生成する方法がある場合( expected
など) 、 zsh
、 socat
、 perl
のIO::Pty
…)、それを使用して、 sudo
を接続するための疑似端末を作成することをお勧めします。 to(ただし、I / O用ではありません)、および ssh
を使用します -t
なし 。
たとえば、 expect
:
ssh host 'expect -c "spawn -noecho sh -c {
exec sudo cmd >&4 2>&5 <&6 4>&- 5>&- 6<&-}
exit [lindex [wait] 3]" 4>&1 5>&2 6<&0'
またはscript
(ここでは、 util-linux
からの実装を想定しています ):
ssh host 'SHELL=/bin/sh script -qec "
sudo cmd <&3 >&4 2>&5 3<&- 4>&- 5>&-
" /dev/null 3<&0 4>&1 5>&2'
((両方の場合)リモートユーザーのログインシェルがBourneに似ていると仮定します。)