メインコンテンツへスキップ
検索

Telnetの代わりにSSHを使い始める人が増えるにつれ、SSHデーモンがパスワードの警告、有効期限、猶予時間をどのように扱うのか、ますます混乱しているのを目の当たりにしています。混乱の原因の一部は、SSH が Telnet とログインコマンドの動作を複製するという誤った期待によるものです。このブログはその仕組みを説明する試みです。

最初に、SSH は Unix/Linux の世界から来たものであり、その世界には VOS のログインコマンドが提供するパスワードを変更するオプション付きの 7 日間の期限切れ前警告がないことを覚えておいてください。SSH デーモンのオリジナルのリリースでは、この警告/オプションも提供されていませんでした。

リリース 2.0.0.0e (ssl-205 と ssl-268 のバグ修正) から、この動作が変更されました。しかし、トンネルを設定している接続は、パスワードの変更要求がユーザに表示されないため、パスワードの変更要求でハングしてしまいます。問題は、トンネルの設定は通常疑似ターミナルを割り当てないので、プロンプトを表示する場所がないことでした。

そこで、リリース 2.0.0.0k (ssl-295) から SSH デーモンは元の動作に戻りました。外部変数がコードに追加され、サイトがそれを望むならば、 期限切れ前のパスワード変更プロンプトを有効にすることができるようになりました。これは sshd$pw_change_method 変数に 1 を設定することで行われます。

7日間の警告期間中に新しいパスワードを要求するときのSSHデーモンの動作は、Telnetで接続したときのログインの動作とは異なることに注意してください。Telnet/login では、リターンキーを押すだけでパスワード変更ステップをスキップすることができます。SSHデーモンはパスワードの変更を要求します。SSHデーモンがパスワードを変更しているかどうかで挙動が異なります。ログインコマンドにchange_password引数を追加した場合、パスワード変更ステップをスキップすることもできません。これは基本的にSSHデーモンがやっていることです。バグ ssl-279 にはこの動作の違いが記述されていますが、エンジニアリングではバグではないと判断されています。Telent/login と SSH の両方でログインした場合に気づくかもしれないもう一つのことは、Telnet/login はパスワードの有効期限が N 日間であることを報告するのに対し、SSH デーモンはパスワードの有効期限が N+1 日間であることを報告するかもしれないということです。この挙動は、最後にパスワードを変更した日の時間帯に依存します。これはバグ ssl-368 として報告されています。

上記の議論では、7日間の警告期間中の時間を扱っています。猶予期間中 (login_admin コマンドの password_grace_time で定義されている) はどうでしょうか?猶予期間中、SSH デーモンは古いパスワードを使ってログインできるようにし、Telnet/login のように新しいパスワードを入力するように要求します。しかし、SSH デーモンが表示するメッセージは少し誤解を招くようなものです。それは、あなたのパスワードがまもなく期限切れになるというものです。ssl-366という暗示が入力され、パスワードが期限切れになっていることを示すようにメッセージを変更するように要求されています。しかし、メッセージに関係なく、最終的な結果は同じです - あなたは新しいパスワードを入力しなければなりません。

考慮すべき最後の時間帯は、猶予期間の後です。この間、SSH デーモンは古いパスワードを使ってログインできるように表示され、新しいパスワードを要求しますが、新しいパスワードを入力した後に接続を終了します。Telnet/login コマンドは、古いパスワードを入力した後に接続を終了します。これは提案 ssl-367 として文書化されており、SSH デーモンは新しいパスワードを要求してはいけません。

パスワードを変更したときの Telnet/login と SSH デーモンの動作にはもう一つ違いがあります。パスワードを変更した後、SSH デーモンはセッションを切断し、新しいパスワードで再接続してログインするように要求します。

最後に、もう一つ議論すべきバグがあります。set_login_security コマンドによって表示される req_change_first_login パラメータが "yes" に設定されている場合、SSH デーモンはすべてのパスワードを ではありません。 が実際の状態に関係なく期限切れになっている場合があります。このバグである ssl-361 はリリース 2.0.0u で修正されており、 req_change_first_login パラメータが yes に設定されているモジュールは、 少なくともこのリリースに直ちにアップグレードすることが推奨されます。

sshd プロセスは接続するたびに新しいプロセスをフォークするので、SSH 接続しているすべてのユーザを強制的にシステムから外すことなく、 新しいバージョンの sshd.pm ファイルをインストールすることができます。これを行うには、以下のようにする必要があります

  1. ディレクトリを >system>openssl>sbin に変更します。
  2. 実行中の sshd.pm ファイルの名前を original_sshd.pm に変更します。
  3. 新しい sshd.pm のコピーを現在のディレクトリに移動します。
  4. Execute the command “kill (contents <etc>sshd.pid)” to stop the parent sshd process
  5. switch_to_root コマンドで root ユーザーに切り替えます。root パスワードを知っておく必要があります。
  6. 新しい sshd プロセスを開始します。sshd の起動方法がわからない場合は、module_start_up.cm をチェックしてください。

sshd$pw_change_method 変数の値を変更するだけの手順はほぼ同じです。ステップ 1, 2, 4, 5, 6 は同じですが、ステップ 3 は

3. 3. original_sshd.pm を sshd.pm にコピーします。

を追加し、実際に変数を設定するステップ3aを追加しました。

3a. コマンドを実行します。

"set_external_variable sshd$pw_change_method -in sshd.pm -type integer -to 1"

メニューを閉じる

© 2024 Stratus Technologies.