RHEL8(sshによる基本bashシェル)
> scp source_path remote_host:destination_path &
> fg
Password: @#$#@#myPassword'sVisibleOhNo!!!
まず、これは私のシステムですか、それとも再現できますか?ユーザーにはプロンプトが表示されず、バックグラウンドでscpを実行したときにのみ発生します(最初は理解できませんが、まだ)。これが予想される動作ですか?これは問題ではありませんか?
答え1
scp
入力した文字をエコーするシェルではなく、実行中のプログラムによって提供された設定に基づくカーネルです。 (stty
この設定を編集してください)。
と入力するとエコーは発生せず、通常の動作を復元するにはstty -echo
(盲目的に)入力する必要があります。stty echo
bashを使用すると、stty -echo &
TTYステータスが再びエコーモードに切り替わるようです。と同じかもしれませんscp
。動作はシェルによって異なりますが、Fishとzshはbashと同じ動作をするようです。
答え2
@FrédéricLoyerの回答のおかげで、より関連性の高い情報を得ることができました。次のスクリプトのいずれかを使用して、scpと同様の動作を確認できます。
> safe () (stty -echo; read password; stty echo)
> safe &
そうでなければ
> (stty -echo; read password; stty echo)
fg
最終的に根本的な問題(セキュリティなど)はscpに限定されていませんが、シェルのエコー設定間の誤った相互作用に関連しています。これはstty -echo/echo
個別に手動で有効/無効にできます。これにより、複数のホスト、SSH接続などを必要とせずに、さまざまなシステムの特定の動作を確認できます。
MacOSのzsh
> safe () (stty -echo; read password; stty echo)
> safe &
[1] 12345
>
[1] + suspended (tty output) safe
> fg
[1] + continued safe
stty: tcsetattr: Interrupted system call
im Getting The Same Issue(macOS zsh now)
>
RHELとUbuntuのBashはさらに悪いです。
> (stty -echo; read password; stty echo) &
[1] 12345
> fg
( stty -echo; read password; stty echo )
[1]+ Stopped ( stty -echo; read password; stty echo )
> fg
( stty -echo; read password; stty echo )
VisiblePassword!!!
>
最初のfgの後は完全に反応しなくなります。 ctrl + zとは異なるfgを実行する必要があります。