この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
すべての VM での VPC-DI のインストールが正常に完了したら、アクティブな制御機能（CF）VM を使用して StarOS パラメータのセットを設定する必要があります。その後で、 インスタンス内の VM が再起動されるたびにアクセスされる、アクティブな CF 上の設定ファイルに VPC-DI これらの設定を保存します。スタンバイ CF およびすべてのサービス機能（SF）VM は、この設定ファイルをアクティブ CF から読み取ります。
CUPS を搭載した UGP の場合は、USP VM にログインして StarOS の一連のパラメータを設定する必要があります。これらの設定は設定ファイルに保存され、VM が再起動されるたびに、CPF VNFC VM に送信されます。
この章では、アクティブな CF コンソールポートに接続し、最初のローカルコンテキスト管理設定を作成する手順について説明します。
クイック セットアップ ウィザードは、次の 3 つのパートで構成されています。
コンテキストレベルのセキュリティ管理者とホスト名の設定
アウトオブバンド（OOB）管理用のイーサネット インターフェイスの設定
Telnet、セキュアシェル（SSH）、または File Transfer Protocol（FTP）を介したリモート CLI アクセスのためのシステム設定
次の図表は、ウィザードの実行ロジックを追加情報と注意事項とともに示すフロー図です。
| 項目 | タスク | 説明/注意事項 |
|---|---|---|
|
1 |
ウィザードを開始または終了します。 |
Enter × プロンプトで no と入力すると、コマンドライン インターフェイス（CLI）が自動的に表示されます。次も項に進みます。StarOS CLI を使用した初期設定 CLI を使用してシステムの初期設定を行う手順については、に進みます。 |
|
Enter setup コマンドプロンプトで setup と入力して、ウィザードを再起動します。 |
||
|
2 |
リリース 19.2 以降の場合、 tech-support のパスワードを設定します。 |
tech-support のパスワードは、cli test-commands にアクセスするために使用されます。 |
|
システムの管理ユーザー名/パスワードおよびホスト名を設定します。 |
ウィザードを使用して設定されたデフォルトの管理ユーザーの名前は admin です。 admin. |
|
|
管理ユーザーの名前は、大文字と小文字を区別した 1 ～ 32 文字の英数字の文字列です。 |
||
|
管理ユーザーのパスワードは、大文字と小文字を区別した 1 ～ 63 文字の英数字の文字列です。 リリース 21.0 以降では、パスワードとして 127 文字入力できます。 |
||
|
NULL 以外の有効なホスト名を設定します。ホスト名は、大文字と小文字が区別される 1 ～ 63 文字の英数字文字列です。 |
||
|
3 |
システムに対して、単一のアウトオブバンド管理インターフェイスを設定します。 |
管理 LAN 上のトラフィックは、ユーザーデータおよび制御シグナリングと同じメディアを介して転送されません。 |
|
セキュリティ上の理由から、管理機能をユーザーデータと制御シグナリングから分離したネットワーク上で維持することを推奨します。 |
||
|
インターフェイスの IP アドレス、サブネットマスク、およびゲートウェイを設定します。 |
||
|
4 |
システムにアクセスするためのリモートアクセスプロトコルを有効にします。 |
セキュアシェル（SSH）は、デフォルトで TCP ポート番号 22 を使用します（有効になっている場合）。 SSH V1 や V2 がサポートされています。 セキュリティを最大限にするには、SSH v2 のみを使用してください。 |
|
5 |
システムとの間でファイルをコピーするためのファイル転送プロトコルを有効にします。 |
SSH が有効になっている場合は、SSH ファイル転送プロトコル（SFTP）サーバー機能を有効にすることもできます。 デフォルトでは、Telnet は TCP ポート番号 23 を使用します（有効になっている場合）。 デフォルトでは、SSH File Transfer Protocol（FTP）は TCP ポート番号 21 を使用します（有効になっている場合）。 |
|
6 |
前のプロンプトの設定の確認や変更を行います。 |
|
|
7 |
入力に基づいてウィザードによって作成されたスクリプトの設定を確認します。 |
次の例では、作成されたスクリプトのサンプルが表示されています。変数はイタリック体で表示されます（variable）。variableを押します）。 |
|
8 |
設定ファイルをシステムに適用します。 |
適用されると、パラメータ設定は、フラッシュメモリに保存されている system.cfg ファイルに自動的に保存されます。 |
EXEC モードの コマンドを実行すると、次のようにセットアップスクリプトが表示されます。 setup コマンドを使用します。
[local]host_name# setup
1. Do you wish to continue with the Quick Setup Wizard[yes/no]: yes
2. Enable basic configuration[yes/no]: yes
3. Change chassis key value[yes/no]: yes
4. New chassis key value: chassis_key
5. Create new tech-support password[yes/no]: yes
6. New tech-support password: new_password
7. local context administrator username[admin]: context_admin_username
8. local context administrator password: context_admin_password
9. confirm local context administrator password: context_admin_password
10. hostname[asr5500]: hostname
シャーシキーは、Cisco Elastic Services Controller（ESC）がシステムの展開に使用されていない場合にのみ、クイック セットアップ スクリプトを使用して設定できます。展開に ESC を使用するカスタムシャーシキーを設定するには、ESC で目的のシャーシキーを指定する必要があります。詳細については、次を参照してください。 OpenStack での ESC を使用した VPC-DI のオンボーディングを参照してください。
初期設定は次のように構成されています。
コンテキストレベルのセキュリティ管理者とホスト名の設定
vNIC でのイーサネット インターフェイスの設定
設定 VPC-DI instance for remote CLI access via SSHを介したリモート CLI アクセスのための インスタンスの設定
この項では、CLI を使用してこれらのタスクを実行するための手順を説明します。
|
ステップ 1 |
ハイパーバイザを介して、アクティブな CF VM のコンソールポートにログインします。 |
||
|
ステップ 2 |
CLI プロンプトで、次のように入力します。 |
||
|
ステップ 3 |
次のコマンドを入力してコンテキスト構成モードを開始します。 |
||
|
ステップ 4 |
コンテキストレベルのセキュリティ管理者を インスタンスに設定するには、 VPC-DI 次のコマンドを入力します。
|
||
|
ステップ 5 |
プロンプトで次のコマンドを入力して、コンテキストの構成モードを終了します。 |
||
|
ステップ 6 |
次のコマンドを入力して、 VPC-DI インスタンスがネットワーク上で認識されるホスト名を設定します。 |
||
|
ステップ 7 |
vNIC 上のネットワーク インターフェイスを次のように設定します。 |
この項では、セキュリティ管理者がユーザーアカウントを制御できるようにするセキュリティ機能の一部について説明します。
セキュリティ管理者は同時対話型 CLI セッションの数を制限できます。同時対話型セッションの数を制限すると、システム全体のリソースの消費量が削減されます。また、ユーザーがすでに使用されている機密ユーザー情報にアクセスする可能性を防ぎます。
ほとんどの特権アカウントでは、複数の同時ログインは必要ありません。 （注） |
21.9 以降のリリースでは、1 つの CLI セッションでの複数のチャネルはサポートされていません。 |
重要 |
すべての特権アカウントには、セッションの最大数を設定することを推奨します。 |
StarOS は次の 3 つのログイン認証方式をサポートしています。
TACACS+ サーバーユーザーの最大セッション数の設定の詳細については 「動作」を参照してください。ローカルユーザーのユーザーと AAA コンテキストユーザーの最大セッション数の設定の詳細については 「Configuring Context-Level Administrative Users」を参照してください。と呼ばれます。
各認証方式は、3 つの認証方式のそれぞれが同じユーザー名を使用できるため、個別に設定する必要があります。
セキュリティ管理者は、特定のユーザーアカウントの自動ログアウトを設定できます。対話型 CLI セッションが使用可能な時間を分単位で制限すると、システム全体のリソースの消費量が削減されます。また、アイドル状態のままになっている端末ウィンドウで、ユーザーがユーザーアカウントにアクセスする可能性を防ぐこともできます。この項で説明されているすべての認証方式は、アイドル セッション タイムアウトの手法と絶対セッションタイムアウトの手法の両方をサポートしています。
ほとんどの特権アカウントは、無期限のログインタイムアウトの制限を必要としません。
重要 |
すべての特権アカウントには、セッションタイムアウトを設定することを推奨します。 |
The idle timeout and session timeout fields in the show tacacs summary と show tacacs session id コマンドのアイドルタイムアウトおよびセッションタイムアウトのフィールドを使用すると、管理者は特定のアカウントの自動ログアウトを設定できます。
セッションのタイムアウト（Session Timeout）：セキュリティ管理者は、セッションが自動的に切断される前に、ユーザーがセッションにログオンできる最大時間を分単位で指定できます。
アイドル タイムアウト ：セキュリティ管理者は、セッションが自動的に切断される前に、セッションがアイドル状態を維持できる最大時間を分単位で指定できます。
重要 |
セッションタイムアウトとアイドルタイムアウトのフィールドは排他的ではありません。両方が指定されている場合は、低いセッションタイムアウトが常に最初に到達するため、アイドルタイムアウトは常にセッションタイムアウトよりも低くする必要があります。 |
対話型 CLI セッションを使用できる最大時間を分単位で設定する方法の詳細については、『CLI Reference』の idle-sessions threshold コマンドと clear tacacs sessions CLI コマンド、および CLI リファレンス と『Statistics and Counter Reference』の show tacacs summary と show tacacs session id を を参照してください。を参照してください。
リモートアクセス用にシステムを設定します。管理ユーザーは、管理ネットワークを介してリモートの場所からインスタンスにアクセスできます。
Telnet
セキュア シェル（SSH）
File Transfer Protocol（FTP）（セキュアまたは非セキュア）
Trivial File Transfer Protocol（TFTP）
（注） |
2 つの同時 telnet セッションがあり、1 人の管理者が他の管理者がログに記録するコンテキストを削除した場合は、削除されたコンテキストの管理者が自動的に local コンテキストに退出させられることはありません。削除されたコンテキストは CLI プロンプトに引き続き表示されますが、コンテキスト固有のコマンドによってエラーが生成されます。 |
（注） |
セキュリティを最大限にするには、SSH v2 を使用します。 |
（注） |
FTP および telnet はサポートされていません。 |
|
ステップ 1 |
次のコマンドを入力してコンテキスト構成モードを開始します。 |
||||
|
ステップ 2 |
必要に応じて、Telnet アクセスを許可するようにシステムを設定します。 |
||||
|
ステップ 3 |
必要に応じて、SSH アクセスを許可するようにシステムを設定します。
|
||||
|
ステップ 4 |
必要に応じて、次のコマンドを入力して、FTP アクセスを許可するようにシステムを設定します。 |
||||
|
ステップ 5 |
次のコマンドを入力して、構成モードを終了します。 |
||||
|
ステップ 6 |
次のコマンドを入力して、設定を確認します。 |
||||
|
ステップ 7 |
次のコマンドを入力して、IP ルートの設定を確認します。 |
||||
|
ステップ 8 |
次のコマンドを入力して、インターフェイス バインディングを確認します。 |
||||
|
ステップ 9 |
「設定の確認と保存」の章の説明に従って、 設定の確認と保存 設定を保存します。 |
SSHv2 RSA は、StarOS でサポートされる SSH の唯一のバージョンです。SSHv2 DSA は、StarOS CLI 内に隠されています。
重要 |
以前のリリースでサポートされていたキーワードが後続のリリースでは隠されている可能性があります。StarOS は、以前のリリースで作成された既存のスクリプトと構成ファイル内の隠されたキーワードを引き続き解析します。ただし、新しいスクリプトや構成ファイルで使用するために、コマンドシンタックスに隠されたキーワードは表示されなくなりました。疑問符（?）を入力しても、ヘルプテキストの一部として隠しキーワードは表示されません。削除されたキーワードは、解析時にエラーメッセージを生成します。 |
SSH プロトコルのバージョン 1 は、セキュリティの脆弱性が原因で廃止されました。次に、 v1-rsa キーワードは、コンテキスト構成モードの ssh コマンドのために削除されました。 ssh コマンドを削除しないでください。SSHv1-RSA キーを使用するスクリプトまたは設定を実行すると、エラーメッセージが返され、イベントログが生成されます。次に、エラーメッセージの出力例を示します。
CLI print failure Failure: SSH V1 contains multiple structural vulnerabilities and is no longer considered secure. Therefore we don't support v1-rsa SSH key any longer, please generate a new v2-rsa key to replace this old one. If the system boots from a configuration that contains the v1-rsa キーを含む設定からシステムが起動する場合、SSH を介してログインするときに起動の失敗が予想されます。回避策は、コンソールポートを介してログインし、新しい ssh v2-rsa キーを再生成し、サーバー sshd を設定することです。その後、ssh を介してログインできるようになります。
次に、 コンテキスト構成モードの ssh コマンドでは、v2-dsa キーワード が隠されるようになりました。 ssh command
次に、 v1-rsa キーワードは、Exec モードの show ssh key CLI コマンドから削除されました。 show ssh key CLI コマンドを使用して、手動で設定する必要があります。
SSH キーベースの認証では、誰に対しても表示が許可されている「公開」キーと、所有者のみが表示を許可されている別の「秘密」キーの、2 つのキーを使用します。キーペアを作成し、ログインするデバイスに秘密キーを安全に保存して、ログインするシステム（）にVPC-DI公開キーを保存します。
SSH ホストキーは、指定された StarOS コンテキスト内で生成されます。コンテキストは、ユーザーインターフェイスに関連付けられています。
コンテキストに関連付けられている sshd サーバーにアクセスするための承認されたキーを持つ管理ユーザー名を設定または削除します。
グローバル構成モードの ssh key-size CLI コマンドは、すべてのコンテキストの SSH キー生成のキーサイズを設定します（RSA ホストキーのみ）。
|
ステップ 1 |
グローバル構成モードを開始します。 |
|
ステップ 2 |
SSH キーのビットサイズを指定します。 |
SSH キーは、最後のキー生成以降に設定可能な時間間隔が経過した後にのみ生成できます。次に、 ssh key-gen wait-time コマンドは、この待機時間を秒単位で指定します。デフォルトの間隔は 300 秒（5 分）です。
|
ステップ 1 |
コンテキスト構成モードを開始します。 |
|
ステップ 2 |
待機時間間隔を指定します。 注：
|
SSH 構成モードの ciphers 暗号 CLI コマンドは、SSH 対称暗号化のために、sshd の暗号優先順位リストを設定します。そのコンテキストの暗号オプションが変更されます。
|
ステップ 1 |
SSH 構成モードを開始します。 |
|
ステップ 2 |
必要な暗号化アルゴリズムを指定します。
The default string for 通常のビルドにおけるアルゴリズム のデフォルトの文字列は次のとおりです。 信頼できるビルドにおける アルゴリズム のデフォルトの文字列は次のとおりです。 |
|
ステップ 3 |
SSH 構成モードを終了します。 |
|
該当製品または機能エリア |
すべて |
|
該当プラットフォーム |
|
|
機能のデフォルト |
無効：設定が必要 |
|
このリリースでの関連する変更点 |
N/A |
|
関連資料 |
|
重要 |
リリース 21.2 および N5.1 よりも前に導入された機能の改訂履歴の詳細は示していません。 |
|
改訂の詳細 |
リリース |
|---|---|
|
最初の導入。 |
21.13 |
MAC アルゴリズム設定機能を使用すると、内部 SSHD サーバーの MAC アルゴリズムの優先順位を設定または変更することができます。
この機能をサポートする、新しい CLI MACs CLI コマンドが SSH モード設定に導入されました。
ここでは、MAC アルゴリズムの設定方法を説明します。
MAC アルゴリズムの優先順位を指定するには、次の設定を使用します。
configure
context context_name
server sshd
macs algorithms
end default macs NOTES（
アルゴリズム：1 ～ 511 文字の英数字文字列を参照します。この文字列は、次のリストで示す優先順位（左から右）のコンマ区切りの変数（スペースなし）の 1 つの文字列として使用するアルゴリズムを指定します。
HMAC = ハッシュベースのメッセージ認証コード
SHA2 = セキュア ハッシュ アルゴリズム 2
SHA1 = セキュア ハッシュ アルゴリズム 1
ETM = Encrypt-Then-MAC
UMAC = ユニバーサルハッシュに基づくメッセージ認証コード
次に、通常のビルドのヘルプ文字列とアルゴリズムのリストを示します。
hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-512,
hmac-sha2-256,hmac-sha1,umac-128-etm@openssh.com,umac-128@openssh.com,umac-64-etm@openssh.com,umac-64@openssh.com次に、信頼できるビルドのヘルプ文字列とアルゴリズムのリストを示します。
hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-512,
hmac-sha2-256,hmac-sha1デフォルト値の文字列は次のとおりです。
hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-512,
hmac-sha2-256,hmac-sha1MAC アルゴリズムの優先順位を設定するには、次の CLI コマンドを使用します。このコマンドは、SSH 構成モードで設定します。
configure
context context_name
server sshd
macs algorithms
end default macs NOTES（
アルゴリズム：1 ～ 511 文字の英数字文字列を参照します。この文字列は、次のリストで示す優先順位（左から右）のコンマ区切りの変数（スペースなし）の 1 つの文字列として使用するアルゴリズムを指定します。
HMAC = ハッシュベースのメッセージ認証コード
SHA2 = セキュア ハッシュ アルゴリズム 2
SHA1 = セキュア ハッシュ アルゴリズム 1
ETM = Encrypt-Then-MAC
UMAC = ユニバーサルハッシュに基づくメッセージ認証コード
次に、通常のビルドのヘルプ文字列とアルゴリズムのリストを示します。
hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-512,
hmac-sha2-256,hmac-sha1,umac-128-etm@openssh.com,umac-128@openssh.com,umac-64-etm@openssh.com,umac-64@openssh.com次に、信頼できるビルドのヘルプ文字列とアルゴリズムのリストを示します。
hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-512,
hmac-sha2-256,hmac-sha1デフォルト値の文字列は次のとおりです。
hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-512,
hmac-sha2-256,hmac-sha1次に、 ssh generate コマンドは、SSH サーバーによって使用される公開キーまたは秘密キーのペアを生成します。次に、 keyword concealed within the ssh generate CLI コマンド内に隠されている v2-dsa キーワード。 CLI コマンドを使用して、手動で設定する必要があります。SSH キーを生成するために使用できる唯一のキーワードは、 v2-rsa です。と呼ばれます。
重要 |
生成されたキーペアは、コマンドが再度発行されるまで使用中のままになります。 |
|
ステップ 1 |
コンテキスト構成モードを開始します。 |
|
ステップ 2 |
SSH キーペアを生成します。 |
次に、 ssh key コマンドは、システムで使用される公開キーと秘密キーのペアを設定します。次に、 v2-dsa キーワードは、ssh key コマンドでは隠されています。 ssh key コマンドを削除しないでください。
|
SSH キーペアのパラメータを指定します。
|
ユーザーが、SSH 認証キーペアを持つ特定のホストから StarOS コンテキストにアクセスすることを許可する必要があります。
SSH 構成モードの authorized-key コマンドは、指定されたホストからのコンテキストへのユーザーアクセスを許可します。
|
ステップ 1 |
SSH 構成モードに移動します。 |
|
ステップ 2 |
Specify administrative user access via the authorized-key コマンドを使用して管理ユーザーアクセスを指定します。 コマンドを削除しないでください。
|
管理者は、StarOS CLI への SSH アクセスを、許可されたユーザーの「ホワイトリスト」に制限できます。サービスへのアクセスは、正当なニーズを持つユーザーにのみ制限される場合があります。明示的に許可されたユーザーのみが、SSH を介してホストに接続できます。ユーザー名には、必要に応じて特定の送信元 IP アドレスを含めることができます。
AllowUsers リストは、スペースで区切られたユーザー名パターンで構成されます。パターンで「USER」という形式を使用すると、そのユーザーに対してログインが制限されます。パターンが「USER@IP_ADDRESS'」形式の場合、ユーザーと IP アドレスは個別にチェックされ、指定した IP アドレスからのユーザーへのログインを制限します。
デフォルトでは、任意のユーザーによる無制限のアクセスを許可します。
次に、 allowusers add コマンドを使用すると、管理者は StarOS CLI にログインできるユーザーのリストを作成できます。
|
ステップ 1 |
コンテキスト構成モードを開始します。 |
||
|
ステップ 2 |
SSH 構成モードに移動します。 |
||
|
ステップ 3 |
SSH ユーザーリストを設定します。 user_list は、スペースで区切られたユーザー名のパターンのリストを、1 ～ 999 文字の英数字の文字列として指定します。パターンで「USER」という形式を使用すると、そのユーザーに対してログインが制限されます。 パターンが「USER@IP_ADDRESS」形式の場合は、ユーザー名と IP アドレスが個別にチェックされ、その特定の IP アドレスからユーザーへのログインが制限されます。 パターンが「USER@<context>@IP_ADDRESS」形式の場合は、ユーザー名、StarOS コンテキスト、および IP アドレスが個別にチェックされ、その特定の IP アドレスから特定のコンテキストに関連付けられているユーザーへのログインを制限します。
詳細については、『Command Line Interface Reference』の 「SSH Configuration Mode Commands」 の章を参照してください。 Command Line Interface Referenceと呼ばれます。 |
||
|
ステップ 4 |
SSH 構成モードを終了します。 |
ユーザーは、ローカルコンテキスト（VPN）インターフェイスを介してローカルコンテキストのユーザー名と、ローカルコンテキストで設定されている許可済みのキーを使用してログインしようとします。
ユーザーは、ローカル以外のコンテキスト インターフェイスを介してローカル以外のコンテキストのユーザー名と、ローカル以外のコンテキストで設定されている許可済みのキーを使用してログインしようとします。
ユーザーは、ローカル以外のコンテキスト インターフェイスを介してローカルコンテキストのユーザー名と、ローカルコンテキストで設定されている許可済みのキーを使用してログインしようとします。
ユーザーは、ローカル コンテキスト インターフェイスを介してローカル以外のコンテキストのユーザー名と、ローカル以外のコンテキストで設定されている許可済みのキーを使用してログインしようとします。
現在のシステム設定に基づいて認証が失敗すると、ログインが阻止され、エラーメッセージが生成されます。
StarOS では、ユーザー ID が異なるユーザーが同じ公開 SSH キーを使用して、許可されていないコンテキストへログインすることは許可されていません。ユーザーの認証では、許可済みキーとユーザーアカウントの組み合わせが考慮されます。
重要 |
StarOS リリース 21.0 以降では、ユーザーがローカル以外のコンテキストからログインした場合、そのユーザーは /flash ディレクトリにアクセスできません。 |
StarOS が SSH クライアントから切断されると、デフォルトの動作によって CLI または SFTP セッションは約 45 秒（デフォルトのパラメータを使用）で終了します。SSH 構成モードの CLI コマンドを使用すると、このデフォルトの SSHD 切断動作を無効にしたり、変更したりできます。
重要 |
セキュリティを強化するため、シスコでは、少なくとも lient-alive-countmax を 2、client-alive-interval を 5 にすることを推奨します。セッションのログアウト値が小さいと、ssh セッションのログアウトが不定期にログアウトする可能性があります。セキュリティとユーザーの使いやすさとのバランスが取れるように値を調整します。 |
次に、 client-active-countmax コマンドは、sshd なしで送信される client-alive メッセージの数を、SSH クライアントからのメッセージを受信しないように設定します（デフォルトは 3）。client-alive メッセージの送信中にこのしきい値に達すると、sshd は SSH クライアントを切断してセッションを終了します。
次に、 client-alive-interval コマンドは、タイムアウト間隔を秒単位で設定します（デフォルトは 15）。その後、SSH クライアントからデータを受信しなかった場合、sshd は暗号化されたチャネルを介してメッセージを送信し、クライアントからの応答を要求します。メッセージが送信される回数は、client-alive-countmax パラメータによって決定されます。sshd が SSH クライアントの切断を解除するまでのおおよその時間は、client-alive-countmax X client-alive-interval となります。
クライアントまたはサーバーがいつ接続が非アクティブになったかを認識しているかどうかに依存している場合、client-alive メカニズムは重要です。
重要 |
client-alive メッセージは暗号化チャネルを介して送信されるため、スプーフィングできません。 |
重要 |
これらのパラメータは、SSH プロトコルバージョン 2 のみに適用されます。 |
|
ステップ 1 |
コンテキスト構成モードを開始します。 |
|
ステップ 2 |
SSH 構成モードに移動します。 |
|
ステップ 3 |
ClientAliveCountmax パラメータを 2 に設定します。 |
|
ステップ 4 |
ClientAliveInterval パラメータを 5 秒に設定します。 |
|
ステップ 5 |
SSH 構成モードを終了します。 |
SSHD 設定のチャレンジレスポンス認証オプションは、キーボードインタラクティブ認証方式を有効にするために使用されます。この認証方式は、特定のケースで役に立ちます。たとえば、TACACS サーバがシステムにログインするユーザーとの対話を必要とする場合などです。
|
ステップ 1 |
コンテキスト構成モードを開始します。 |
|
ステップ 2 |
SSH 構成モードに移動します。 |
|
ステップ 3 |
チャレンジレスポンス認証を設定します。 SSHD チャレンジレスポンス認証を指定し、レガシーの PGW、SGW、または SAEGW に対してのみ有効にします。詳細については、 『Command Line Interface Reference』の「SSHD Configuration Mode Commands」 の章を参照してください。 Command Line Interface Referenceと呼ばれます。 |
|
ステップ 4 |
SSH 構成モードを終了します。 |
チャレンジレスポンス認証オプションは、リリース 21.28 以降でのみサポートされます。
チャレンジレスポンス認証の有効化は、特定の特殊なケースでのみ推奨されます。たとえば、TACACS サーバがユーザーに特定のプロンプトを表示することを選択した場合などです。特別な理由がない限り、チャレンジレスポンス認証は有効にしないでください。このオプションを有効にする前に、シスコの担当者にお問い合わせください。
明示的に制限されていなくても、レガシーの PGW、SGW、SAEGW 以外の製品についてはチャレンジレスポンス認証を有効にしないことを強くお勧めします。
キーボードインタラクティブ認証方式を使用するには、SSH ログインに使用される IP アドレスを所有するコンテキストで、チャレンジレスポンス認証を有効にする必要があります。
チャレンジレスポンス認証は、コンソールを介した SSH ログインには影響しません。
チャレンジレスポンス認証は SSHD オプションであり、Telnet や FTP のログインには影響しません。
ユーザー応答のサイズは 128 バイト未満である必要があります。
重要 |
TACACS と組み合わせて使用されるチャレンジレスポンス認証も想定しており、これも特殊なケースになります。TACACS サーバは、[AUTHEN-REPLY Server Message] フィールドで最大 511 文字を送信でき、その文字はログインしようとしているエンドユーザーに渡されます。[Server Message] フィールドの長さが 512 バイト以上の場合、[ERROR: Enter any key to continue.] というエラーメッセージがユーザーに表示され、TACACS 認証は想定どおりに失敗します。 |
チャレンジレスポンス認証が有効になっている場合、ユーザーにはプロンプトへの応答のために 60 秒が与えられます。
StarOS は、StarOS ゲートウェイから外部サーバーへの SSH/SFTP アクセスの公開キーの認証をサポートしています。この機能を設定するには、SSH クライアントキーのペアを生成し、クライアント公開キーを外部サーバーにプッシュします。
（注） |
デフォルトでは、StarOS は外部サーバーへの username-password の認証のみをサポートしています。 |
SSH クライアント構成モードの ciphers CLI コマンドは、外部サーバーにログインするときに暗号優先順位リストを設定します。
|
ステップ 1 |
SSH クライアント構成モードを開始します。 |
|
ステップ 2 |
必要な暗号化アルゴリズムを指定します。
通常のビルドにおけるアルゴリズム のデフォルトの文字列は次のとおりです。 信頼できるビルドにおける アルゴリズム のデフォルトの文字列は次のとおりです。 |
|
ステップ 3 |
SSH クライアント構成モードを終了します。 |
SSH クライアント構成モードの preferredauthentications CLI コマンドは、適切な認証方式を設定します。
|
ステップ 1 |
SSH クライアント構成モードを開始します。 |
|
ステップ 2 |
優先認証方式の指定
|
|
ステップ 3 |
SSH クライアント構成モードを終了します。 |
SSH クライアント構成モードでコマンドを使用し、秘密キーを指定して、SSH クライアントキーペアを生成します。
|
ステップ 1 |
SSH クライアント構成モードを開始します。 |
|
ステップ 2 |
SSH クライアントキーのペアを生成します。 type v2-rsa は SSH クライアントキーのタイプを指定します。サポートされている SSH クライアントキーのタイプは、 v2-rsa のみです。と呼ばれます。 key-size は SSH クライアントのキーサイズを指定します。サポートされているキーサイズは、2048、3072、4096、5120、6144、7168、および 9216 です。 |
|
ステップ 3 |
SSH クライアントキーが生成されていることを確認します。 |
|
ステップ 4 |
SSH クライアント構成モードを終了します。 |
このサーバーへの SSH/SFTP アクセスをサポートするには、SSH クライアント公開キーを外部サーバーにプッシュする必要があります。
|
ステップ 1 |
Exec モードで、 push ssh-key コマンドを実行します。 コマンドを削除しないでください。 host_name は、DNS ルックアップを介して解決される必要がある論理ホスト名を使用してリモートサーバーを指定します。これは、1 ～ 127 文字の英数字文字列で表されます。 host_ip_address は、IPv4 ドット付き 10 進表記または IPv6 コロン区切り 16 進表記で表されます。 user username は、外部サーバーで有効なユーザー名を 1 ～ 79 文字の英数字の文字列として指定します。 context context_name は、有効なコンテキスト名を指定します。コンテキスト名はオプションです。指定されていない場合は、現在のコンテキストが処理に使用されます。 |
|
ステップ 2 |
他の外部サーバーでの SSH/SFTP アクセスをサポートするには、ステップ 1 を繰り返します。 |
|
ステップ 3 |
外部サーバーへの SSH クライアントのログインをテストします。 |
SSH キーは、NETCONF プロトコルと ConfD エンジンが Cisco Network Service Orchestrator（NSO）をサポートするために有効になる前に必要になります。
参照先 NETCONF および ConfD NETCONF を有効にする方法の詳細については、このガイドの付録の「NETCONF と ConfD」を参照してください。
必要に応じて、vNIC 管理インターフェイスに 2 番目の IP アドレスを設定できます。
| コマンドまたはアクション | 目的 | |
|---|---|---|
|
ステップ 1 |
プロンプトで次のコマンドを入力して、構成モードを開始します。 |
|
|
ステップ 2 |
コンテキスト構成モードを開始するには、次のように入力します。 |
|
|
ステップ 3 |
次のコマンドを使用して、インターフェイスのスロット番号とポート番号を入力します。 |
|
|
ステップ 4 |
次のコマンドを入力して、セカンダリ IP アドレスとサブネットマスクを入力します。 |
|
|
ステップ 5 |
次のコマンドを入力して、構成モードを終了します。 |
|
|
ステップ 6 |
次のコマンドを入力して、インターフェイスの IP アドレスを確認します。 |
|
|
ステップ 7 |
に進みます。 インターフェイスとポートの設定の確認と保存を参照してください。 |
|
該当製品または機能エリア |
すべて |
|
該当プラットフォーム |
|
|
機能のデフォルト |
有効、常時オン |
|
このリリースでの関連する変更点 |
N/A |
|
関連資料 |
|
重要 |
リリース 21.2 および N5.1 よりも前に導入された機能の改訂履歴の詳細は示していません。 |
|
改訂の詳細 |
リリース |
|---|---|
|
このリリースでは、暗号と MAC のアルゴリズム値は、OpenSSH から CiscoSSH へのアップグレードと移行に基づいて変更されています。 |
21.16 |
|
最初の導入。 |
21.2 よりも前 |
Cisco ASR 5500 および VPC 製品のセキュリティ対策として、暗号および MAC アルゴリズム値は、Cisco SSH バージョンへの Open SSH のアップグレードと移行をサポートするように変更されています。
以前の動作：21.16 よりも前のリリースでは、 default コマンドと コマンドのアルゴリズム値は cipher と macs 次のようになっていました。
暗号化方式
21.15（通常ビルドのみ）
blowfish-cbc,3des-cbc,aes128-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com MAC
21.15（信頼できるビルドのみ）
信頼できるビルドのアルゴリズムの値を algorithm 次のようにリセットします。
hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-512,
hmac-sha2-256,hmac-sha1 KEX アルゴリズム
21.15
通常のビルドと信頼できるビルドで使用可能なアルゴリズム：
diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 新しい動作：このリリースでは、 default コマンド cipher と macs コマンドのアルゴリズム値は次のとおりです。
暗号化方式
リリース 21.16 以降：Post OpenSSH から CiscoSSH へのアップグレードと移行
通常のビルドのデフォルトのアルゴリズムは次のとおりです。
aes256-ctr,aes192-ctr,aes128-ctr,aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com 通常のビルドで使用可能なアルゴリズムは次のとおりです。
aes256-ctr,aes192-ctr,aes128-ctr,aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc 信頼できるビルドでデフォルトのアルゴリズムと使用可能なアルゴリズム：
aes256-ctr,aes192-ctr,aes128-ctr （注） |
信頼できるビルドのデフォルトの暗号と設定可能な暗号に変更はありません。 |
MAC
リリース 21.16 以降：Post OpenSSH から CiscoSSH へのアップグレードと移行
通常のビルドでデフォルトのアルゴリズムと使用可能なアルゴリズム：
hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-512,
hmac-sha2-256,hmac-sha1 信頼できるビルドでデフォルトのアルゴリズム：
hmac-sha2-512,hmac-sha2-256,hmac-sha1 信頼できるビルドで使用可能なアルゴリズム：
hmac-sha2-512,hmac-sha2-256,hmac-sha1 （注） |
hmac-sha2-512-etm@openssh.com、hmac-sha2-256-etm@openssh.com、hmac-sha1-etm@openssh.com は信頼できるビルドから削除されます。 |
KEX アルゴリズム
リリース 21.16 以降：Post OpenSSH から CiscoSSH へのアップグレードと移行
通常のビルドと信頼できるビルドで使用可能なアルゴリズム：
diffie-hellman-group14-sha1 （注） |
KEX アルゴリズムは、StarOS では設定できません。したがって、CLI の変更はありません。 |
リソース割り当ての問題を回避するには、システム内で使用されるすべての VM が同じサイズの CPU と同じサイズのメモリを持つことが重要です。すべてのインターフェイスでパフォーマンスのバランスを取るために、サービスポートと DI ポートが同じスループット能力を備えていることを確認してください。
すべてのカードまたは特定のカードのハードウェア設定を確認するには、 show cloud hardware [card_number} コマンドを使用します。 コマンドを削除しないでください。次に、カード 1（CF）でのこのコマンドの出力例を示します。
[local]s1# show cloud hardware 1
Card 1:
CPU Nodes : 1
CPU Cores/Threads : 8
Memory : 16384M (qvpc-di-medium)
Hugepage size : 2048kB
cpeth0 :
Driver : virtio_net
loeth0 :
Driver : virtio_net
次に、カード 3（SF）でのこのコマンドの出力例を示します。
[local]s1# show cloud hardware 1
Card 3:
CPU Nodes : 1
CPU Cores/Threads : 8
Memory : 16384M (qvpc-di-medium)
Hugepage size : 2048kB
cpeth0 :
Driver : vmxnet3
port3_10 :
Driver : vmxnet3
port3_11 :
Driver : vmxnet3
基本となる VM ハードウェアの最適な設定を表示するには、 を使用します。 show hardware optimum と呼ばれます。現在の VM 設定を最適な設定と比較するには、 コマンドを使用します。 show cloud hardware test コマンドを削除しないでください。最適に設定されていないパラメータは、次の出力例に示すように、アスタリスク付きでフラグが立てられます。この例では、CPU コア/スレッドおよびメモリが最適に設定されていません。
[local]s1# show cloud hardware test 1
Card 1:
CPU Nodes : 1
* CPU Cores/Threads : 8 Optimum value is 4
* Memory : 8192M (qvpc-di-medium) Optimum value is 16384
Hugepage size : 2048kB
cpeth0 :
Driver : virtio_net
loeth0 :
Driver : virtio_net
設定ディスクまたはローカルフラッシュ上の設定ファイルを表示するには、 show cloud configuration card_number コマンドを使用します。 コマンドを削除しないでください。フラッシュメモリ上のロケーション パラメータ ファイルは、インストール時に定義されます。また、ディスク構成は通常、オーケストレーションによって作成され、カードに接続されます。次に、カード 1 でのこのコマンドの出力例を示します。
[local]s1# show cloud configuration 1
Card 1:
Config Disk Params:
-------------------------
No config disk available
Local Params:
-------------------------
CARDSLOT=1
CARDTYPE=0x40010100
CPUID=0
すべてのカードまたは特定のカードの IFTASK 設定を表示するには、 コマンドを使用します。 show cloud hardware iftask コマンドを削除しないでください。デフォルトでは、コアは PMD と VNPU の両方に使用されるように設定されています。次に、カード 4 でのこのコマンドの出力例を示します。
[local]mySystem# show cloud hardware iftask 4
Card 4:
Total number of cores on VM: 24
Number of cores for PMD only: 0
Number of cores for VNPU only: 0
Number of cores for PMD and VNPU: 3
Number of cores for MCDMA: 4
Hugepage size: 2048 kB
Total hugepages: 16480256 kB
NPUSHM hugepages: 0 kB
CPU flags: avx sse sse2 ssse3 sse4_1 sse4_2
Poll CPU's: 1 2 3 4 5 6 7
KNI reschedule interval: 5 us
フィードバック