Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

リモートアクセスの概要

お客様(ネットワーク管理者)は、DHCP、Finger、FTP、rlogin、SSH、Telnetサービスなどのサービスを利用してルーター、スイッチ、セキュリティデバイスにリモートでアクセスできます。このトピックでは、Telnet、SSH、FTP、Fingerサービスを使用してリモートアクセスを設定する方法を説明します。

システム サービスの概要

セキュリティ上の理由から、ルーターへのリモート アクセスはデフォルトで無効になっています。リモート システム上のユーザーがルーターにアクセスできるように、ルーターを明示的に構成する必要があります。ユーザーは、DHCP、finger、FTP、rlogin、SSH、および Telnet サービスを使って、リモート システムからルーターにアクセスできます。また、Junos XML プロトコルのクライアント アプリケーションでは、SSL(Secure Sockets Layer)や Junos XML プロトコル固有のクリアテキスト サービスを含む他のサービスを利用できます。

注:

システム リソースを保護するため、サービスが受け入れる同時接続数や、シングル ユーザーが所有するプロセスの数を制限できます。どちらかの制限を超えた場合、接続試行は失敗します。

ルーターまたはスイッチへのリモート アクセス用の Telnet サービスの設定

ルーターまたはスイッチがアクセス サービスとして Telnet を承認するように設定するには、 階[edit system services]層レベルに ステートtelnetメントを含めます。

デフォルトでは、ルーターまたはスイッチがサポートする 1 分あたりの同時 Telnet セッションと接続試行の数は制限されています。

オプションとして、デフォルトを変更するため、以下のステートメントのいずれかまたは両方を含めることができます。

  • connection-limit limit—プロトコルあたりの同時接続の最大数(IPV4 と IPv6)。範囲は 1~250 です。デフォルトは75です。接続制限を設定する場合、プロトコルごとの telnet セッションの数には制限が適用されます(IPv4 と IPv6)。例えば、接続制限が 10 の場合、10 個の IPv6 telnet セッションと 10 個の IPv4 telnet セッションが許可されます。

  • rate-limit limit—1分あたりに許容される最大接続試行数(1~250)。デフォルトは 150 です。レート制限を設定する場合、プロトコルごとの接続試行の数に制限が適用されます(IPv4とIPv6)。例えば、レート制限が 10 の場合、1 分あたりの 10 回の IPv6 telnet セッション接続試行と 10 回の IPv4 telnet セッション接続試行が許可されます。

Junos-FIPSソフトウェアを実行するデバイスに telnetステートメントを含めることはできません。コモンクライテリア環境ではTelnetを使用しないことをお勧めします。

ルーターまたはスイッチへのリモート アクセス用の FTP サービスの設定

アクセスサポートとしてFTPを承認するようデバイスを設定するには、[edit system services]階層レベルで ftpステートメントを含めます。

デフォルトでは、ルーターまたはスイッチがサポートする 1 分あたりの同時 FTP セッションと接続試行の数は制限されています。次のステートメントのいずれか、または両方を含めることで、デフォルトを変更できます。

  • connection-limit limit—プロトコルあたりの同時接続の最大数(IPV4 と IPv6)。範囲は1~250の値です。デフォルトは75です。接続回数制限を設定すると、制限はプロトコル当たりのセッションの数に該当されます (IPv4 と IPv6)。例えば、接続制限が 10 であれば、10 の IPv6 FTP セッションと 10 の IPv4 FTP セッションが許可されます。

  • rate-limit limit— 1分あたりの承認される最大接続試行数(1~250の値)。デフォルトは 150 です。レート制限を設定する場合、プロトコルごとの接続試行の数に制限が適用されます(IPv4とIPv6)。例えば、レート制限が 10 であれば、10 の IPv6 FTP セッション接続試行と 10 の IPv4 FTP セッション接続試行が許可されます。

パッシブFTPを使用して、パッシブFTPサービスのみを受け入れるデバイスにアクセスできます。FTP を使用するすべてのコマンドとステートメントも、パッシブ FTP を受け入れます。[edit system services]階層レベルでftpステートメントを含め、アクティブFTPまたはパッシブFTPを使用します。

パッシブ FTP セッションを開始するには、標準の FTP 形式(ftp://destination)で、(ftpの代わりに)pasvftpを使用します。たとえば、以下のように表示されます。

Junos-FIPS ソフトウェアを実行するルーターまたはスイッチに 、ftpステートメントを含めることはできません。「共通基準」環境では、FTP サービスを使用しないことをお勧めします。

ルーターへのリモートアクセス用のフィンガーサービスを設定する

利用可能なサポートとしてフィンガーを承認するようアプリケーションを設定するには、 [edit system services] 階層レベルで finger ステートメントを含めます。

デフォルトでは、ルーターは 1 分あたりの同時フィンガーセッションと接続試行の回数制限をサポートします。オプションとして、デフォルトを変更するため、以下のステートメントのいずれかまたは両方を含めることができます。

  • connection-limit limit—プロトコルあたりの同時接続の最大数(IPv4 と IPv6)。範囲は1~250の値です。デフォルトは75です。接続回数制限を設定すると、制限はプロトコル当たりのセッションの数に該当されます (IPv4 と IPv6)。例えば、接続制限が 10 の場合、10 回の IPv6 クリアテキストサービスセッションと 10 回の IPv4 クリアテキストサービスセッションが許可されます。

  • rate-limit limit— 1分あたりの承認される最大接続試行数(1~250の値)。デフォルトは 150 です。レート制限を設定する場合、プロトコルごとの接続試行の数に制限が適用されます(IPv4とIPv6)。例えば、レート制限が 10 の場合、1 分あたり 10 回の IPv6 セッション接続試行と 10 回の IPv4 セッション接続試行が許可されます。

Junos-FIPS ソフトウェアを実行するルーターに finger ステートメントを含めることはできません。コモン クライテリア環境ではフィンガーサービスを使用しないことをお勧めします。

ルーターまたはスイッチへのリモートアクセス用にSSHサービスを構成する

アクセスサービスとしてSSHを承認するようルーターまたはスイッチを構成するには、ssh ステートメントを [edit system services] 階層レベルで記述します。

デフォルトでは、ルーターまたはスイッチがサポートする1分あたりの同時SSHセッションと接続試行の数は制限されています。デフォルトを変更する場合は、以下のステートメントを使用します。

  • connection-limit limit—プロトコルあたりの同時接続の最大数(IPv4 と IPv6)。範囲は1~250の値です。デフォルトは75です。接続制限を構成する場合、プロトコルごとのSSHセッションの数にこの制限が適用されます(IPv4とIPv6)。例えば、接続制限が10であれば、10のIPv6 SSHセッションと10のIPv4 SSHセッションが許可されます。

  • max-sessions-per-connection number - 1つのSSH接続で許可されるSSHセッションの最大数を指定するには、このステートメントを含めます。これにより、1つのSSH接続内でトンネルされるクローンセッションの数を制限できます。デフォルト値は10です。

  • rate-limit limit— 1分あたりの承認される最大接続試行数(1~250の値)。デフォルトは 150 です。レート制限を設定する場合、プロトコルごとの接続試行の数に制限が適用されます(IPv4とIPv6)。たとえば、レートが10に制限されている場合、1分間に10回までのIPv6 SSHセッション接続試行と、1分間に10回までのIPv4 SSHセッション接続試行が許容されます。

  • data-limit - セッションキーを再ネゴシエーションするまでのデータ制限(バイト)

  • time-limit - セッションキーを再ネゴシエーションするまでの時間制限(分)

Junos OSリリース19.4R1とJunos OSリリース17.4R3以降、no-password-authentication および no-challenge-response オプションを [edit system services ssh] 階層レベルで使用することで、SSHログインパスワードまたはチャレンジ-レスポンス認証のいずれかを無効にできるようになりました。

デフォルトでは、ユーザーはJunos OSをSSH経由で実行しているルーターに対して、CLIセッションを経由するSSHトンネルを作成できます。このタイプのトンネルを使用すると、ファイアウォールフィルターやアクセス制御リストをバイパスして、TCPトラフィックを転送できます。ファイアウォールフィルターやアクセス制御リストをバイパスすることで、このタイプのトンネルは、ルーターを超えたリソースへのアクセスを可能にします。ユーザーがSSH経由でルーターへのSSHトンネルを作成できないようにするには、no-tcp-forwarding オプションを使用します。

その他の構成設定については、以下のトピックを参照してください。

SSH経由でルートログインを構成する

デフォルトでは、パスワードを必要としない認証方法の場合、ユーザーはSSH経由で root としてルーターまたはスイッチにログインできます。SSHを通してユーザーアクセスを制御するには、root-login ステートメントを [edit systems services ssh] 階層レベルで記述します。

allow - ユーザーがルーターやスイッチにSSH経由でrootとしてログインすることを許可します。

deny - ユーザーがSSH経由でルーターまたはスイッチにrootとしてログインできないようにします。

denypassword - 認証方法(例:RSA)がパスワードを必要としない場合、ユーザーがSSH経由でルーターまたはスイッチにrootとしてログインすることを許可します。

デフォルトは deny-password です。

受信SFTP接続を構成する

SSHファイル転送プロトコル(SFTP)は、任意の信頼できるデータストリーム上でファイルアクセス、ファイル転送、ファイル管理を提供するネットワークプロトコルです。Junos OSリリース19.1R1以降、受信SFTP接続は、デフォルトでグローバルに無効化されるようになりました。必要に応じ、sftp-server ステートメントを [edit system services ssh] 階層レベルで構成することで、受信SFTP接続をグローバルに有効にできます。Junos OS リリース 19.1R1 以前までは、受信SFTP接続はデフォルトでグローバルに有効になっていました。

注:

デフォルトでは、受信SFTP接続のみが無効になっています。例えば、デバイスAとB(デバイスAでは19.1R1が動作)がある場合、デフォルトではBからAへSFTPで接続することはできません。ただし、デバイスAで sftp-server を構成すれば、デバイスBからデバイスAへSFTPで接続できます。

受信SFTP接続はデフォルトで無効になっています。受信SFTP接続を有効にするには:

  1. sftp-server ステートメントを [edit system services ssh] 階層レベルで構成します。
  2. 設定をコミットします。

    sftp-server ステートメントは現在アクティブです。したがって、受信SFTP接続は有効になっています。

SSHプロトコルのバージョンを構成する

デフォルトでは、SSHプロトコルのバージョン2のみが有効になっています。

SSHプロトコルのバージョン2を使用するようにルーターまたはスイッチを構成するには、protocol-version ステートメントを記述し、v2[edit system services ssh] 階層レベルで指定します。

FIPSモードのシステムは、常にSSHプロトコルバージョン v2 を使用します。

クライアントアライブメカニズムを構成する

クライアントアライブメカニズムは、クライアントまたはサーバーが、接続がいつ非アクティブになったかを知ることに依存している場合に有効です。これは、標準のキープ アライブ メカニズムとは異なり、クライアントアライブメッセージは暗号化されたチャネルを通して送信されます。クライアントアライブメカニズムは、デフォルトでは有効になっていません。有効にするには、client-alive-count-max および client-alive-interval ステートメントを構成します。このオプションは、SSHプロトコルバージョン2にのみ適用されます。

以下の例では、応答しないSSHクライアントは、約100秒(20 × 5)後に切断されます。

SSHフィンガープリントハッシュアルゴリズムを設定する

SSH サーバーがキーフィンガープリントを表示する際に使用するハッシュアルゴリズムを設定するには、fingerprint-hash ステートメントを含め、[edit system services ssh]階層レベルで md5 または sha2-256 を指定します。

md5 ハッシュ アルゴリズムは、FIPS モードのシステムでは使用できません。

SSH証明書ベースの認証の概要

Junos OSおよびJunos OS Evolvedリリース22.4R1以降、ユーザーとホストのSSH証明書ベースの認証を設定できるようになりました。この機能により、カギのフィンガープリントで検証することなく、ユーザーと信頼できるホストに対してパスワードレスのSSHアクセスを確立できます。

SSH証明書ベースの認証の利点

  • SSH証明書ベースの認証により、ユーザーがパスワードを覚えて入力する必要がなくなり、ログインプロセスが合理化されます。

  • 従来のパスワードベースのアプローチと比較して、SSH証明書はより強力なセキュリティを提供します。推測したり解読したりするパスワードがないため、侵害する方が困難です。

  • SSH証明書は、認証キーの管理を簡素化します。管理者は、ユーザーとホストごとに個別の鍵を管理する代わりに、集中認証局から証明書を発行および取り消すことができます。

署名キーの生成

署名キーは、SSH 証明書ベースの認証で使用される特殊な暗号化キーです。SSH証明書ベースの認証を設定するための最初のステップは、署名キーを生成することです。どの Linux/FreeBSD システムでも署名鍵を生成できます。SSH 証明書ベースの認証用の署名キーを生成するには、次の手順に従います。

  1. 次のコマンドを実行します。ssh-keygen -f <filename_ca>. これにより、 <filename_ca> という名前の秘密キーと、 <filename_ca.pub> という名前の対応する公開キーが作成されます。

  2. ジュニパーデバイスにログインし、次のコマンドを実行してSSHの信頼できるユーザー認証機関(CA)キーファイルを設定します。set system services ssh trusted-user-ca-key-file <path-to-public-key> そして、設定をコミットします。

  3. 各ユーザーは、次の CLI コマンドを使用して、独自のユーザー キーを生成できます。ssh-keygen -t <rsa|ecdsa|ed25519>.

  4. ユーザーが作成した公開キーを、ユーザー証明書 <filename_ca><filename_ca.pub>があるコンピューターにコピーします。

  5. <filename_ca.pub> ファイルでユーザー公開キーに署名します。

設定

SSH証明書ベースの認証を設定するには、次のCLI設定ステートメントを使用します。

  • [system services ssh trusted-user-ca-key-file filename]— SSH証明書の公開カギが含まれる/etc/ssh/sshd_configにあるTrustedUserCAKeyファイルを設定します。

  • [system services ssh host-certificate-file filename]—署名された証明書が含まれる/etc/ssh/sshd_configにあるHostCertificateファイルを設定します。

  • [system services ssh authorized-principals-file filename]/var/etcにあるAuthorizedPrincipalsファイルを設定します。このファイルには名前の一覧が含まれており、認証で承認されるにはその中の1つが証明書に記載されている必要があります。

  • [system services ssh authorized-principals-command program-path]AuthorizedPrincipalsファイルに含まれる、許可される証明書プリンシパルの一覧の生成に使用するプログラムを指定します。

telnet コマンド

CLI コマtelnetンドを使用して、リモート デバイスへの Telnet セッションを開くことができます。

注:

SRX100、SRX210、SRX220、SRX240、SRX300、SRX320、SRX340、SRX345、およびSRX1500 デバイスでは、下表に同時 Telnet セッションの最大数が示されています。プラットフォームのサポートは、インストールされた Junos OS のリリースによって異なります。

SRX100

SRX210SRX220

SRX240

SRX300SRX320SRX340

SRX345

SRX1500

3

3

5

3

5

5

Telnet セッションを出て Telnet コマンド プロンプトに戻るには、Ctrl-] 押します。

Telnet セッションを出て、CLI コマンド プロンプトに戻るには、 を入力しますquit

表 1: CLI telnet コマンド オプション

オプション

説明

8bit

8 ビット データ パスを使用します。

bypass-routing

ルーティング テーブルをバイパスし、直接接続されたインターフェースのホストへのみ Telnet セッションを開きます。ホストが直接接続されたインターフェイスではない場合、エラー メッセージが返されます。

host

指定されたホスト名または IP アドレスへの Telnet セッションを開きます。

inet

IPv4 宛先への Telnet セッションを強制します。

interface source-interface

指定されたインターフェースのホストへの Telnet セッションを開きます。このオプションが含まれていない場合、すべてのインターフェースが使用されます。

no-resolve

記号名の表示を抑制します。

port port

ホスト上のポート番号またはサービス名を指定します。

routing-instance routing-instance-name

Telnet セッションに指定されたルーティング インスタンスを使用します。

source address

Telnet セッションに指定された送信元アドレスを使用します。

sshコマンド

CLI sshコマンドを使用して、セキュアシェル(SSH)プログラムを使用し、リモートデバイスへの接続を開けることができます。

注:

SRX100、SRX210、SRX220、SRX240、SRX300、SRX320、SRX340、SRX345、および SRX1500 デバイスでは、同時 SSH セッションの最大数は次の表に示されています。プラットフォームのサポートは、インストールされた Junos OS のリリースによって異なります。

SRX100

SRX210SRX220

SRX240

SRX300SRX320SRX340

SRX345

SRX1500

3

3

5

3

5

5

表 2 で、ssh コマンドのオプションについて説明します。

表 2: CLI ssh コマンド オプション

オプション

説明

bypass-routing

ルーティングテーブルをバイパスして、SSH接続を直接接続されたインターフェースのホストのみに開きます。ホストが直接接続されたインターフェイスではない場合、エラー メッセージが返されます。

host

SSH 接続を、指定されたホスト名または IP アドレスへ開きます。

inet

IPv4 の宛先への SSH 接続を強制します。

interface source-interface

SSH接続を、指定されたインターフェース上のホストに開きます。このオプションが含まれていない場合、すべてのインターフェースが使用されます。

routing-instance routing-instance-name

SSH接続に指定されたルーティングインスタンスを使用します。

source address

SSH接続に、指定された送信元アドレスを使用します。

v1

SSH を強制して、接続にバージョン 1 を使用します。

v2

SSHを強制して、接続にバージョン2を使用します。

データを安全にコピーするためのSSH Knownホストキーを設定する

セキュアシェル(SSH)は、暗号アルゴリズムを使用し、安全なデータ送信を確実に行うホスト、サーバー、セッションキーシステムを生成します。設定アーカイブやイベントログなどのデータのバックグラウンド転送向けのFTPの代替として、SSHホストキーを設定し、安全なコピー(SCP)をサポートできます。SCP向けSSHサポートを設定するには、以下のタスクを完了する必要があります。

  • ルーティングエンジン設定階層にホスト名とホストキー情報を入れ、SSHの既知のホストを指定します。

  • SCP URLを設定して、データを受信するホストを指定します。この属性を設定すると、SCPサーバーからSSHホストキー情報を自動的に取得します。

  • ホストキーが本物であるかどうかを検証します。

  • 安全な接続を受け入れます。接続を受け入れることで、ローカルホストキーデータベースにホストキー情報が自動的に保存されます。設定階層にホストキー情報を保存することで、安全なハンドシェイクを自動化し、SCPを使用してのバックグラウンドデータ転送が可能になります。

データの安全なコピーのためのSSHホストキーを設定するタスクは、以下の通りです。

SSH既知のホストを設定する

SSHの既知のホストを設定するには、hostステートメントを含め、[edit security ssh-known-hosts]階層レベルで信頼できるサーバー向けにホスト名とホストキーオプションを指定します。

ホストキーは、以下のいずれかです。

  • dsa-key key—SSHバージョン2向けBase64エンコード済みデジタル署名アルゴリズム(DSA)キー。

  • ecdsa-sha2-nistp256-key key—Base64エンコード済みECDSA-SHA2-NIST256キー。

  • ecdsa-sha2-nistp384-key key—Base64エンコード済みECDSA-SHA2-NIST384キー。

  • ecdsa-sha2-nistp521-key key—Base64エンコード済みECDSA-SHA2-NIST521キー。

  • ed25519-key key—Base64エンコード済みED25519キー。

  • rsa-key key—SSHバージョン1およびSSHバージョン2向けの暗号化とデジタル署名をサポートするBase64エンコード済み公開キーアルゴリズム。

  • rsa1-key key—SSHバージョン1向けの暗号化とデジタル署名をサポートするBase64エンコード済みRSAパブリックキーアルゴリズム。

SCPファイル転送のためのサポートを設定する

バックグラウンドSCPファイル転送をサポートする既知のホストを設定するには、階[edit system archival configuration]層レベルでステートarchive-sitesメントを含めます。

注:

IPv6ホストアドレスを使用したJunos OSステートメント内のURLを指定する場合、URL全体を引用符("")で囲み、IPv6ホストアドレスを括弧([ ])で囲みます。例えば、“scp://username<:password>@[host]<:port>/url-path”;

ステートarchive-sitesメントをSCP URLに向けるように設定すると、自動ホストキー取得がトリガーされます。この時点で、Junos OSは SCPホストに接続し、SSHパブリックキーを取得し、ホストキーメッセージダイジェストまたはフィンガープリントをコンソールへの出力として表示して、サーバーへの接続を終了します。

ホストキーが純正であることを確認するには、このフィンガープリントを、信頼できる送信元を使って同じホストから取得するフィンガープリントと比較します。フィンガープリントが同一である場合は、プロンプトでyesと入力して、ホストキーを受け入れます。次に、ホストキー情報がルーティングエンジン設定に保存され、SCPを使ってバックグラウンドデータ転送をサポートします。

SSHホストキー情報を更新する

通常、階[edit system]層でステートarchival configuration archive-sitesメントを使用してSCP向けのURL属性を設定すると、SSHホストキー情報が自動的に取得されます。ただし、ホストキーデータベースを手動で更新する必要がある場合は、以下の方法のいずれかを使用します。

ホストキー情報を手動で取得する

SSHパブリックホストキー情報を手動で取得するには、階[edit security ssh-known-hosts]層レベルでfetch-from-serverオプションを設定します。SSHパブリックキーを取得するホストを指定する必要があります。

ファイルからホストキー情報をインポートする

ファイルからSSHホストキー情報を手動でインポknown_hostsートするには、階[edit security ssh-known-hosts]層レベルでload-key-fileオプションを含めます。ホストキー情報をインポートするファイルへのパスを指定する必要があります。

レガシー暗号化をサポートする SSH サービスの設定

の SSH サーバーは OpenSSH 7 に基づいてJunos OSおり、デフォルトは、よりセキュアな暗号方式と鍵交換アルゴリズムのセットになります。OpenSSH 7 は、一部のレガシー暗号化を省略します。

注:

デバイス内のレガシー暗号化がサポートされていないため、Junos Space デバイスの発見が失敗します。この問題を回避するには、デバイスが 3des-cbcまたは blowfish-cbc暗号方式、あるいはその両方、および dh-group1-sha1鍵交換方法をサポートするよう設定します。この問題は、FreeBSD がアップグレードされた Junos OS を実行するデバイスに影響しません。

注:

これらの拡張の詳細については、OpenSSH 7 ドキュメント(https://www.openssh.com/)を参照してください。

Junos OSデフォルトでは、 は以下の暗号方式のセットをサポートしています。

  • chacha20-poly1305@openssh.com

  • aes128-ctr

  • aes192-ctr

  • aes256-ctr

  • aes128-gcm@openssh.com

  • aes256-gcm@openssh.com

ではJunos OS、以下の暗号方式はデフォルトではサポートされていませんが、デバイスがサポートするように設定できます。これらは、セキュリティが最も強いものから最も弱いものまで多岐にわたります。

  • aes256-cbc

  • aes192-cbc

  • aes128-cbc

  • 3des-cbc

Junos OSデフォルトでは、 は以下の鍵交換方法のセットをサポートしています。

  • curve25519-sha256

  • ecdh-sha2-nistp256

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp521

  • group-exchange-sha2

  • dh-group14-sha1

では、以下の鍵交換方法はデフォルトではサポートされていませんがJunos OS、デバイスがサポートするように設定できます。

  • group-exchange-sha1

  • dh-group1-sha1

SSH サービスがレガシー暗号化をサポートするように設定するには:

注:

暗号方式、鍵交換方法、またはMAC(メッセージ認証コード)の順序付きセットを設定することで、新しく定義されたセットがサーバー コマンドとクライアント コマンドの両方に適用されます。デフォルトの変更は、SCP(セキュア コピー プロトコル)を使用する場合、file copyコマンドに影響を与えます。

  1. コマset system services ssh ciphers [ cipher 1 cipher 2 ... ]ンドを使用して、暗号方式のサポートを追加します。使用された最後のオプションに含まれるように設定リストの最後に暗号方式を追加することをお勧めします。以下の例では、 arcfourおよび 暗blowfish-cbc号方式がデフォルト セットに追加されます。
  2. コマset system services ssh key-exchange [ method 1 method 2 ... ]ンドを使用して、鍵交換方法のサポートを追加します。使用された最後のオプションに含まれるように設定リストの最後に鍵交換方法を追加することをお勧めします。以下の例では、 dh-group1-sha1鍵交換方法がデフォルト セットに追加されます。
  3. 設定をコミットします。

アウトバウンド SSH サービスを設定する

Junos OSを実行中のデバイスを設定して、クライアント管理アプリケーションとの TCP/IP 接続を開始できます。デバイスがファイアウォールなどの理由で、管理アプリケーションがジュニパーネットワークスデバイスに接続できない場合があります。この場合、ジュニパーネットワークスデバイスでoutbound-sshを設定できます。outbound-ssh設定は、サーバーからクライアント、管理アプリケーションへのリバースSSH接続を開始します。このアウトバウンドSSH接続は、デバイスから設定が削除された後のみ切断されます。

注:

アウトバウンドSSHに開始コマンドはありません。アウトバウンド SSH を設定してコミットすると、デバイスはコミットされた設定に基づいてアウトバウンド SSH 接続を開始します。デバイスは、成功するまでこの接続を繰り返し試みます。デバイスとクライアント管理アプリケーション間の接続が切断された場合、デバイスは成功するまで新しいアウトバウンド SSH 接続の作成を再試行します。この接続は、設定からアウトバウンド SSH スタンザが削除されるまで維持されます。

アウトバウンド SSH 接続のデバイスを設定するには、 階[edit system services]層レベルに ステートoutbound-sshメントを含めます。

[edit system services outbound-ssh]

次のトピックでは、アウトバウンドSSHサービスを設定する作業について説明します。

アウトバウンド SSH クライアントに公開 SSH ホストキーを送信する

ルーターまたはスイッチがアウトバウンド SSH 接続を確立するたびに、まず管理クライアントに開始シーケンスを送信します。このシーケンスでは、管理クライアントに対するルーターまたはスイッチを識別します。この送信内では、device-idの値です。

ルーターまたはスイッチのデバイスIDを設定するには、 階[edit system services outbound-ssh client client-id]層レベルに ステートdevice-idメントを含めます。

secretが設定されていない場合の開始シーケンス:

SSH接続の起動中に、クライアントはデバイスの公開SSHホストキーを使用してデバイスのIDを認証します。そのため、クライアントが SSH シーケンスを開始する前に、クライアントにはデバイスの公開 SSH キーが必要になります。ステートsecretメントを設定すると、デバイスはアウトバウンド SSH 接続開始シーケンスの一部として公開 SSH キーに渡します。

ステートsecretメントが設定され、デバイスがアウトバウンド SSH 接続を確立すると、デバイスは ステートsecretメントの一部から派生するデバイス ID、公開 SSH キー、および SHA1 ハッシュを伝達します。ステートsecretメントの値は、デバイスと管理クライアント間で共有されます。クライアントは、公開キーが ステートdevice-idメントによって識別されるデバイスから派生するかどうかを判断するために受信している公開 SSH ホストキーを認証する共有シークレットを使用します。

secret ステートメントを使用した公開SSHホストキーの送信はオプションです。公開キーは、手動でクライアントシステムに送信およびインストールできます。

注:

secret ステートメントを含めると、デバイスはクライアントとの接続を確立するたびに、公開SSHホストキーを送信します。その後は、クライアントがそのデバイスに対する SSH キーがすでにある場合、SSH ホストキーで何をするかを決定するのはクライアント次第です。SSHホストキーのクライアントのコピーを新しいキーと置換することが推奨されます。ホストキーはさまざまな理由で変化する可能性があります。接続が確立するたびにキーを置換することにより、クライアントのキーは常に最新のものとなります。

デバイスがクライアントに接続した時点で、ルーターまたはスイッチの公開 SSH ホストキーを送信するには、 階[edit system services outbound-ssh client client-id]層レベルに ステートsecretメントを含めます。

secret属性が設定された時点で、次のメッセージがデバイスによって送信されます:

アウトバウンド SSH 接続のキープアライブメッセージを設定する

クライアントアプリケーションにルーターまたはスイッチの公開 SSH ホストキーが設定されたら、TCP/IP 接続が作成されたときと同様に SSH シーケンスを開始できます。クライアントは、そのシーケンスの一部として、ルーターまたはスイッチの公開ホスト SSH キーのコピーを使用してデバイスを認証できます。デバイスは、Junos OS(RSA/DSA 公開文字列またはパスワード認証)でサポートされるメカニズムを通してクライアントユーザーを認証します。

デバイスが SSH プロトコルキープアライブメッセージをクライアントアプリケーションに送信できるようにするには、 階[edit system services outbound-ssh client client-id]層レベルで ステートkeep-aliveメントを設定します。

新しいアウトバウンド SSH 接続を設定する

切断されると、デバイスが新しいアウトバウンド SSH 接続を開始し始めます。接続デバイスがドロップされた後でサーバーに再接続する方法を指定するには、 階[edit system services outbound-ssh client client-id]層レベルに ステートreconnect-strategyメントを含めます。

また、再試行回数を指定して、再接続が停止されるまでの時間を設定することもできます。「アウトバウンド SSH 接続のキープアライブメッセージを設定する」を参照してください。

アウトバウンド SSH クライアントを設定して、利用可能なサービスとして NETCONF を承認する

利用可能なサポートとしてNETCONFを承認するようアプリケーションを設定するには、 階[edit system services outbound-ssh client client-id]層レベルで ステートservices netconfメントを含めます。

アウトバウンドSSHクライアントを設定する

このアウトバウンド SSH 接続で利用可能なクライアントを設定するには、 階[edit system services outbound-ssh client client-id]層レベルで個別のアドレスステートメントをリストします。

注:

アウトバウンドSSH接続は、IPv4およびIPv6アドレスフォーマットをサポートしています。

アウトバウンド SSH クライアントにルーティングインスタンスを設定する

管理ルーティングインスタンスを使用するには、まず コマset system management-instanceンドを使って ルーmgmt_junosティングインスタンスを有効にします。

他のルーティングインスタンスを使用するには、[edit routing-instances] 階層でルーティングインスタンスをまず設定します。

ルーティングインスタンスを指定しない場合、デバイスはデフォルトのルーティングテーブルを使ってアウトバウンド SSH 接続を確立します。

指定されたTCPポートでのNETCONF-over-SSH接続の設定

Junos OSファイアウォールを設定せずに、指定されたTCPポートに受信NETCONF接続を制限することができます。NETCONF-over-SSH接続に使用するTCPポートを設定するには、[edit system services netconf ssh]階層レベルにportステートメントを含めます。設定されたポートは、NETCONF-over-SSHセッションのみを受け入れます。このポートの通常のSSHセッション要求は拒否されます。

RFC 4742、セキュアシェル(SSH)を介したNETCONF設定プロトコルの使用で指定されているように、SSHを介したNETCONF接続のデフォルトポート830を構成するか、1~65535の任意のポートを構成することができます。

注:
  • デフォルトのSSHポート(22)は、設定されたNETCONFサーバーのポートでもNETCONFセッションを受け入れ続けます。SSHポートがNETCONFセッションの受け付けを無効にするには、ログインイベントスクリプトでこれを指定します。

  • NETCONF-over-SSH接続の設定については、FTP(21)およびTelnet(23)サービスのデフォルトポートを設定することは推奨しません。

TelnetおよびSSHアクセスに対するパスワード再試行の制限

ブルートフォース攻撃や辞書攻撃を防ぐために、デバイスはデフォルトでTelnetまたはSSHセッションに対して次のアクションを実行します。

  • 最大10回連続でパスワードを再試行した後にセッションを切断します。

  • 2回目のパスワード再試行から、5秒の倍数で待ち時間を再試行の間に入れます。

    たとえば、3回目と4回目のパスワード再試行の間に5秒の待ち時間をデバイスが入れた場合、4回目と5回目の待ち時間は10秒になり、これを再試行ごとに繰り返します。

  • 最小セッション時間を20秒に強制し、その間はセッションを切断することができません。最小セッション時間を設定することで、パスワード再試行の待ち時間が適用される前に悪意あるユーザーがセッションを切断することを防ぎます。また、最小セッション時間を設定することで、複数ログインによるブルートフォース攻撃や辞書攻撃を防ぎます。

TelnetおよびSSHアクセスに対するパスワード再試行の制限を設定できます。この例では、デバイスがTelnetおよびSSHセッションに対して次のアクションを実行するように設定します。

  • セッションを切断する前に、最大4回のパスワードの連続再試行を許可します。

  • 2回目のパスワード再試行から、5秒の倍数の待ち時間を再試行の間に入れます。

  • 最小セッション時間を40秒に強制し、その間はセッションを切断することができません。

TelnetおよびSSHアクセスのパスワード再試行の制限を設定します。

  1. Telnet、SSH、またはTelnetセッションを切断する前に、連続してパスワードを再試行する最大回数を設定します。デフォルトの回数は10ですが、110を指定できます。
  2. 連続して2回パスワードを再試行した後に、待ち時間が発生する再試行回数の閾値を設定します。デフォルトの回数は2ですが、13を指定できます。
  3. パスワード再試行回数の閾値より後の連続したパスワードの再試行の待ち時間(秒)を設定します。デフォルトの待ち時間は、5秒の倍数ですが、510秒の値を指定できます。
  4. TelnetまたはSSHセッションを切断できない最小時間(秒)を設定します。デフォルトは、20秒ですが、2060秒の間隔を指定できます。
  5. デバイスの設定後、コンフィギュレーションモードでcommitを入力します。

例:Telnet および SSH アクセスをブロックするフィルターの設定

要件

共有ネットワーク リンクで接続された Junos OS を搭載したデバイスが2台必要です。デバイスの基本的な初期化(管理インターフェース、リモート アクセス、ユーザー ログイン アカウントなど)以外の特別な設定は必要ありません。厳格な要件ではありませんが、R2 デバイスへのコンソール アクセスを推奨します。

注:

この例は、当社のコンテンツテスト チームが検証し、更新したものです。

概要とトポロジー

この例では、IPv4 ステートレス ファイアウォール フィルターを作成します。このフィルターは、発信元が 192.168.1.0/30 サブネットのパケット以外の、ローカル ルーティング エンジン に送信された Telnet または SSH のパケットをログに記録して拒否します。このフィルターはループバック インターフェイスが適用され、ローカル デバイス宛てのトラフィックだけに影響を与えます。フィルターは入力方向に適用します。出力フィルターは使用しません。その結果、ローカルで生成されたすべてのトラフィックが許可されます。

  • 特定のサブネットや IP プレフィックスから送信されたパケットを照合するには、入力方向に適用する source-address IPv4 の一致条件を使用します。

  • Telnet ポートおよび SSH ポート宛のパケットを照合するには、入力方向に適用された port telnet および port ssh のIPv4 一致条件と protocol tcp の一致条件を組み合わせて使用します。

トポロジーの例

図 1 にこの例のテスト トポロジーを示します。ファイアウォールフィルターがR2デバイスに適用され、DUT(被試験デバイス)になります。R1とR2のデバイスは、192.168.1.0/30 のサブネットが割り当てられたリンクを共有します。両デバイスとも、/32サブネットマスクを使用した192.168.255.0/30 プレフィックスから割り当てられたループバックアドレスを持っています。この簡単な例では、内部ゲートウェイプロトコルが設定されていないため、ループバックアドレス間の到達性は静的ルートで確保されます。

図 1: トポロジーの例トポロジーの例

設定

次の例では、設定階層のいくつかのレベルに移動する必要があります。設定モードでのCLIエディターの使用CLIのナビゲーションについては、「1 コンフィグレーション・モードでのCLIエディタの使用」1 を参照してください。

注意:

設計上、サンプル フィルターは、R1 の共有サブネットから発信されたものでない限り、R2 への Telnet および SSH のアクセスを制限します。SSH または Telnet を使用して R2 デバイスに直接アクセスすると、フィルターが適用されて接続を失います。この例に沿って設定を行うなら、コンソール アクセスの取得をお勧めします。必要に応じて、R1 デバイスをジャンプ ホストとして使用し、フィルター適用後に R2 への SSH セッションを開始できます。または、サンプルフィルターを変更して、R2デバイスへのアクセスに使用するマシンに割り当てられたIPサブネットを許可することもできます。

次のタスクを実行して、この例に沿って設定を行いましょう。

CLIクイック構成

R1 デバイスの簡易設定

R1 デバイスを、簡易的に設定する場合、以下のコマンドを適宜編集して、[edit] 階層レベルの CLI に貼り付けます。変更を有効にするには、必ず設定モードで commit を発行してください。

R2 デバイスの簡易設定

R2 デバイスを、簡易的に設定する場合、以下のコマンドを適宜編集して、[edit] 階層レベルの CLI に貼り付けます。変更を有効にするには、必ず モードで commit を発行してください。

ヒント:

デバイスのリモートアクセスに影響を与えうる変更を行う際は、commit-confirmed の使用を検討します。Junos OS の設定有効時の確認要求

R1 デバイスの設定

ステップバイステップでの手順

以下の手順に従って、R1 デバイスを設定します。

  1. インターフェイスを設定します。

  2. R2デバイスのループバックアドレスに対して、ホスト名と静的ルートを設定します。Telnet および SSH のアクセスも設定します。

R1 デバイスでの設定の確認とコミット

ステップバイステップでの手順

次の手順に従って、キャンディデート構成をR1デバイスで確認してコミットします。

  1. show interfaces 設定モード コマンドを使用して、インターフェイスの設定を確認します。コマンドの出力結果に意図した設定内容が表示されない場合は、この例の手順を再実行して設定を修正します。

  2. R2 デバイスがループバック アドレスまで到達するのに使用する静的ルートや、SSH および Telnet アクセスが有効であることを確認します。show routing-options および show system services 設定コマンドを使用します。コマンドの出力結果に意図した設定内容が表示されない場合は、この例の手順を再実行して設定を修正します。

  3. R1 デバイスの設定に問題がなければ、受験者の設定をコミットします。

R2 デバイスの設定

ステップバイステップでの手順

以下の手順に従って、R2 デバイスを設定します。始めに、Telnet および SSH アクセスを選択的にブロックするステートレス ファイアウォール フィルターを定義します。

  1. edit firewall family inet filter local_aclの階層に移動します。

  2. フィルター条件terminal_accessを定義します。この条件は、指定されたソースプレフィックスからのTelnetとSSHを許可します。

  3. フィルター条件terminal_access_deniedを定義します。この条件は、その他すべての送信元アドレスからの SSH および Telnet を拒否します。この条件は、条件に一致するログを記録し、明示的なインターネット制御メッセージ プロトコル(ICMP)宛先到達不能応答をパケットの送信元に返信します。フィルターロギングオプションの詳細については、ファイアウォールフィルターロギングアクションをご覧ください。

    ヒント:

    discard アクションを使用すると、送信元への ICMP エラーメッセージの生成を抑制できます。詳細については、ファイアウォールフィルターロギングアクションをご覧ください。

  4. オプション。

    フィルター条件tcp-estabを定義します。この条件はインターネットへのアウトバウンドアクセスを許可し、Juniper Mist Cloudへの接続をサポートします(tcp-establishedはビットフィールド一致条件のtcp-flags "(ack | rst)"であり、これは確立されたTCPセッションであるものの、TCP接続の最初のパケットではないことを示しています)。

  5. フィルター条件default-termを定義します。この条件は、他のすべてのトラフィックを許可します。Junos OSステートレス フィルターの末尾には、暗黙的な deny 条件があることを思い出してください。default-termは、明示的なacceptアクションでフィルターを終了させてこの動作を上書きします。フィルターが終了すると、その他のすべてのトラフィックがファイラーによって許可されます。

    注:

    この例では他のすべてのトラフィックを許可しますが、ご自身のネットワークでは、ルーティングエンジンを保護した方がよいでしょう。詳細についてはルーティングエンジンを保護するを参照ください。

  6. ループバックインターフェイスを設定し、入力方向にフィルターを適用します。

  7. ホスト名、ge-0/0/0インターフェイス、R1デバイスのループバックアドレスへの静的ルートを設定し、SSHおよびTelnetを使用したリモートアクセスを有効にします。

R2デバイスでの設定の確認とコミット

ステップバイステップでの手順

次の手順に従って、受験者の設定を R2 デバイスで確認してコミットします。

  1. show firewall 設定モード コマンドを使用して、ステートレス ファイアウォール フィルターの設定を確認します。コマンドの出力結果に意図した設定内容が表示されない場合は、この例の手順を再実行して設定を修正します。

  2. show interfaces 設定モード コマンドを使用して、インターフェイスの設定とフィルター アプリケーションを確認します。コマンドの出力結果に意図した設定内容が表示されない場合は、この例の手順を再実行して設定を修正します。

  3. R1 デバイスのループバック アドレスに到達するのに使用する静的ルートを確認し、Telnet および SSH アクセスが有効であることを確認します。show routing-options および show system services 設定コマンドを使用します。コマンドの出力結果に意図した設定内容が表示されない場合は、この例の手順を再実行して設定を修正します。

  4. R2 デバイスの設定に問題がなければ、受験者の設定をコミットします。

    ヒント:

    デバイスのリモートアクセスに影響を与えうる変更を行う際は、commit-confirmed の使用を検討します。

ステートレス ファイアウォール フィルターの確認

TelnetおよびSSHアクセスを制限するファイ ウォールフィルターが正常に動作していることを確認します。

受理されたパケットの確認

目的

トラフィックが 192.168.1.0/30 サブネットから送信されている場合、ファイアウォール フィルターが SSH と Telnet を正しく許可していることを確認します。

アクション
  1. ルーターまたはスイッチのファイアウォール ログを消去します。

  2. 192.168.1.0/30 サブネット内の IP アドレスのホストから、ssh 192.168.255.2 コマンドを使用して、許可された送信元アドレスから SSH を使用してデバイスにログインできるか確認します。このパケットは受理されるべきですが、このパケットのパケット ヘッダー情報は、パケット転送エンジンのファイアウォール フィルター ログ バッファーに記録されるべきではありません。これらのデバイス間のuser最初のSSHログインである場合は、SSHホストキーを保存するようにメッセージが現れます。

    注:

    デフォルトの R1 デバイスは、宛先に到達するために使用するエグレス インターフェイスから SSH トラフィックを送信します。その結果、このトラフィックは、R1デバイスのge-0/0/0インターフェイスに割り当てられた192.168.1.1アドレスから送信されます。

  3. R2デバイスでCLIからログアウトして、SSHセッションを閉じます。

  4. 192.168.1.0/30 サブネット内の IP アドレスのホストから、 telnet 192.168.255.2 コマンドを使用して、許可された送信元アドレスから Telnet を使用してルーターまたはスイッチにログインできるか確認します。このパケットは受理されるべきですが、このパケットのパケット ヘッダー情報は、パケット転送エンジンのファイアウォール フィルター ログ バッファーに記録されるべきではありません。

  5. R2デバイスでCLIからログアウトして、R2デバイスへのTelnetセッションを閉じます。

  6. show firewall log コマンドを使用して、R2 デバイスの パケット転送エンジン(PFE)のファイアウォール ログ バッファーに、192.168.1.0/30 サブネット内の送信元アドレスを持つエントリーが含まれていないか確認します。

ログされたパケットと拒否されたパケットの確認

目的

ファイアウォール フィルターが、発信元が 192.168.1.0/30 サブネットではない SSH および Telnet トラフィックを正しく拒否しているか確認します。

アクション

  1. ルーターまたはスイッチのファイアウォール ログを消去します。

  2. R1デバイスのループバックアドレスから送信されたSSHトラフィックを生成します。このトラフィックの送信元アドレスは、許可された 192.168.1.0/30 サブネットの外にありますssh 192.168.255.2 source 192.168.255.1 コマンドを使用して、この送信元アドレスから SSH を使用してデバイスにログインできないことを確認します。このパケットは拒否され、パケットのヘッダー情報はファイアウォール フィルター ログのバッファーに記録されるはずです。

    この出力結果は、SSH接続が拒否されたことを示しています。この出力は、フィルターが ICMP エラー メッセージを生成していること、および許可されない送信元アドレスから送信された SSH トラフィックを正しくブロックしていることを確認します。

  3. R1 デバイスのループバック アドレスから送信された Telenet トラフィックを生成します。このトラフィックの送信元アドレスは、許可された 192.168.1.0/30 サブネットの外にありますtelnet 192.168.255.2 source 192.168.255.1 コマンドを使用して、この送信元アドレスから Telnet を使用してデバイスにログインできないことを確認します。このパケットは拒否され、パケットのヘッダー情報は PFE のファイアウォール フィルター ログのバッファーに記録されるはずです。

    この出力結果は、Telnet接続が拒否されたことを示しています。この出力は、フィルターが ICMP エラー メッセージを生成していること、および許可されない送信元アドレスから送信された Telnet トラフィックを正しくブロックしていることを確認します。

  4. show firewall log コマンドを使用して、R2デバイスのファイアウォールログバッファーに、送信元アドレスの192.168.255.1を持つパケットが拒否されたことを示すエントリーが含まれていないか確認します。

    この出力から、送信元アドレス192.168.255.1からのトラフィックがフィルターのterminal_access_denied条件に一致したことがわかります。Action 列には、これらのパケットが拒否されたことを示す R が表示されています。インターフェイス、トランスポート プロトコル、送信元アドレスおよび宛先アドレスも一覧表示されています。これらの結果から、この例においてファイアウォールフィルターが正しく動作したことが確認できます。

変更履歴

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。

リリース
説明
19.4R1
Junos OSリリース19.4R1とJunos OSリリース17.4R3以降、no-password-authentication および no-challenge-response オプションを [edit system services ssh] 階層レベルで使用することで、SSHログインパスワードまたはチャレンジ-レスポンス認証のいずれかを無効にできるようになりました。
19.1R1
Junos OSリリース19.1R1以降、受信SFTP接続は、デフォルトでグローバルに無効化されるようになりました。必要に応じ、sftp-server ステートメントを [edit system services ssh] 階層レベルで構成することで、受信SFTP接続をグローバルに有効にできます。
18.3R1
Junos OS リリース 18.3R1 以降、、 ssh-dssssh-dsa のホストキーアルゴリズムは、すぐには削除されませんが、非推奨とされました。これは、後方互換性を確保し、新しい設定に適合させる機会を提供するためです。
18.3R1
(SRX シリーズと MX シリーズ限定)Junos OS リリース 19.3R1 以降では、 階[edit system services outbound-ssh]層レベルに ステートrouting-instanceメントを含めることにより、アウトバウンド SSH 接続が確立する必要があるルーティングインスタンスの名前を指定できます。