このページの目次
リモートアクセスの概要
お客様(ネットワーク管理者)は、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
ステートメントを含めます。
[edit system services] telnet { connection-limit limit; rate-limit limit; }
デフォルトでは、ルーターまたはスイッチがサポートする 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 セッション接続試行が許可されます。
ルーターまたはスイッチへのリモート アクセス用の FTP サービスの設定
アクセスサービスとしてFTPを承認するようデバイスを設定するには、[edit system services]
階層レベルで ftp
ステートメントを含めます。
[edit system services] ftp;
パッシブ FTP を使用して、パッシブ FTP サービスのみを受け入れるデバイスにアクセスできます。FTP を使用するすべてのコマンドとステートメントも、パッシブ FTP を受け入れます。[edit system services]
階層レベルで ftp
ステートメントを含め、アクティブ FTP またはパッシブ FTP を使用します。
パッシブ FTP セッションを開始するには、標準の FTP 形式 (ftp://destination) で (ftp
の代わりに) pasvftp
を使用します。例えば:
request system software add pasvftp://name.com/jinstall.tgz
ルーターへのリモートアクセス用のフィンガーサービスの設定
利用可能なサービスとしてフィンガーを承認するようルーターを設定するには、[edit system services]
階層レベルで finger
ステートメントを含めます。
[edit system services] finger;
ルーターまたはスイッチへのリモートアクセス用にSSHサービスを構成する
アクセスサービスとしてSSHを承認するようルーターまたはスイッチを構成するには、[edit system services]
階層レベルに ssh
ステートメントを含めます。
[edit system services] ssh { authentication-order [method 1 method2...]; authorized-keys-command authorized-keys-command; authorized-keys-command-user authorized-keys-command-user; authorized-principals-file filename authorized-principals-command program-path ciphers [ cipher-1 cipher-2 cipher-3 ...]; client-alive-count-max number; client-alive-interval seconds; connection-limit limit; fingerprint-hash (md5 | sha2-256); host-certificate-file filename hostkey-algorithm (algorithm | no-algorithm); key-exchange [algorithm1 algorithm2...]; log-key-changes log-key-changes; macs [algorithm1 algorithm2...]; max-pre-authentication-packets number; max-sessions-per-connection number; no-challenge-response; no-password-authentication; no-passwords; no-public-keys; no-tcp-forwarding; port port-number; protocol-version [v2]; rate-limit number; rekey { data-limit bytes; time-limit minutes; } root-login (allow | deny | deny-password); sftp-server; tcp-forwarding; trusted-user-ca-key-file filename }
デフォルトでは、ルーターまたはスイッチがサポートする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をSSH経由で実行しているルーターに対して、CLIセッションを経由するSSHトンネルを作成できます。このタイプのトンネルを使用すると、ファイアウォールフィルターやアクセス制御リストをバイパスして、TCPトラフィックを転送できます。ファイアウォールフィルターやアクセス制御リストをバイパスすることで、このタイプのトンネルは、ルーターを超えたリソースへのアクセスを可能にします。ユーザーがSSH経由でルーターへのSSHトンネルを作成できないようにするには、 no-tcp-forwarding
オプションを使用します。
その他の構成設定については、以下のトピックを参照してください。
- SSH経由でルートログインを構成する
- 受信SFTP接続を構成する
- SSHプロトコルのバージョンを構成する
- クライアントアライブメカニズムを構成する
- SSHフィンガープリントハッシュアルゴリズムを設定する
SSH経由でルートログインを構成する
デフォルトでは、パスワードを必要としない認証方法の場合、ユーザーはSSH経由でroot
としてルーターまたはスイッチにログインできます。SSH を介してユーザーアクセスを制御するには、[edit systems services ssh]
階層レベルで root-login
ステートメントを含めます。
[edit system services ssh] root-login (allow | deny | deny-password);
allow
- ユーザがSSH経由でルーターまたはスイッチにrootとしてログインできるようにします。
deny
- ユーザがSSH経由でルーターまたはスイッチにrootとしてログインできないようにします。
deny
-password
—認証方法(RSAなど)がパスワードを必要としない場合、ユーザーはSSH経由でルーターまたはスイッチにrootとしてログインできます。
デフォルトは deny-password
です。
受信SFTP接続を構成する
SSHファイル転送プロトコル(SFTP)は、任意の信頼できるデータストリーム上でファイルアクセス、ファイル転送、およびファイル管理を提供するネットワークプロトコルです。受信SFTP接続はデフォルトで無効になっています。必要に応じ、[edit system services ssh]
階層レベルで ステートメントsftp-server
を設定することで、受信SFTP接続をグローバルに有効にできます。
デフォルトでは、受信SFTP接続のみが無効になっています。例えば、デバイスAとBがある場合、デフォルトではBからAへSFTPで接続することはできません。ただし、デバイスAで sftp-server
を設定すれば、デバイスBからデバイスAへSFTPで接続できます。
受信SFTP接続はデフォルトで無効になっています。受信SFTP接続を有効にするには:
SSHプロトコルのバージョンを構成する
デフォルトでは、SSHプロトコルのバージョン2のみが有効になっています。
SSHプロトコルのバージョン2を使用するようにルーターまたはスイッチを構成するには、protocol-version
ステートメントを含め、[edit system services ssh]
階層レベルでv2
を指定します。
[edit system services ssh] protocol-version [ v2 ];
クライアントアライブメカニズムを構成する
クライアントアライブメカニズムは、クライアントまたはサーバーが、接続がいつ非アクティブになったかを知ることに依存している場合に有効です。これは、標準のキープ アライブ メカニズムとは異なり、クライアントアライブメッセージは暗号化されたチャネルを介して送信されます。クライアントアライブメカニズムは、デフォルトでは有効になっていません。有効にするには、 client-alive-count-max
および client-alive-interval
ステートメントを設定します。このオプションは、SSHプロトコルバージョン2にのみ適用されます。
以下の例では、応答しないSSHクライアントは、約100秒(20 × 5)後に切断されます。
[edit system ssh] client-alive-count-max 5; client-alive-interval 20;
SSHフィンガープリントハッシュアルゴリズムを設定する
SSH サーバーがキーフィンガープリントを表示する際に使用するハッシュアルゴリズムを設定するには、fingerprint-hash
ステートメントを含め、[edit system services ssh]
階層レベルで md5
または sha2-256
を指定します。
[edit system services ssh] fingerprint-hash (md5 | sha2-256);
SSH証明書ベースの認証の概要
Junos OSおよびJunos OS Evolvedリリース22.4R1以降、ユーザーとホストのSSH証明書ベースの認証を設定できるようになりました。この機能により、カギのフィンガープリントで検証することなく、ユーザーと信頼できるホストに対してパスワードレスのSSHアクセスを確立できます。
SSH証明書ベースの認証の利点
-
SSH証明書ベースの認証により、ユーザーがパスワードを覚えて入力する必要がなくなり、ログインプロセスが合理化されます。
-
従来のパスワードベースのアプローチと比較して、SSH証明書はより強力なセキュリティを提供します。推測したり解読したりするパスワードがないため、侵害する方が困難です。
-
SSH証明書は、認証キーの管理を簡素化します。管理者は、ユーザーとホストごとに個別の鍵を管理する代わりに、集中認証局から証明書を発行および取り消すことができます。
署名キーの生成
署名キーは、SSH 証明書ベースの認証で使用される特殊な暗号化キーです。SSH証明書ベースの認証を設定するための最初のステップは、署名キーを生成することです。どの Linux/FreeBSD システムでも署名鍵を生成できます。SSH 証明書ベースの認証用の署名キーを生成するには、次の手順に従います。
コマンドを実行します:
ssh-keygen -f <filename_ca>
。これにより、<filename_ca>
という名前の秘密キーと、<filename_ca.pub>
という名前の対応する公開キーが作成されます。ジュニパーのデバイスにログインし、SSH の信頼できるユーザー認証機関(CA)のキーファイルを設定するには、次のコマンド
set system services ssh trusted-user-ca-key-file <path-to-public-key>
を実行してから、設定をコミットします。各ユーザーは、次の CLI コマンドを使用して、独自のユーザー キーを生成できます。
ssh-keygen -t <rsa|ecdsa|ed25519>
.ユーザーが作成した公開キーを、ユーザー証明書
<filename_ca>
と<filename_ca.pub>
があるマシンにコピーします。<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]
-AuthorizedPrincipals
ファイルを /var/etc に設定します。このファイルには名前のリストが含まれており、認証で承認されるにはその中の 1 つが証明書に記載されている必要があります。 -
[system services ssh authorized-principals-command program-path]
-AuthorizedPrincipals
ファイルに含まれる、許可される証明書プリンシパルのリストの生成に使用するプログラムを指定します。
telnet コマンド
CLI telnet
コマンドを使用して、リモート デバイスへの Telnet セッションを開くことができます。
user@host> telnet host <8bit> <inet> <inet6> <port port> <routing-instance routing-instance-name>
Telnet セッションを出て Telnet コマンド プロンプトに戻るには、Ctrl-] 押します。
Telnet セッションを出て、CLI コマンド プロンプトに戻るには、 quit
を入力します。
オプション |
形容 |
---|---|
|
8 ビット データ パスを使用します。 |
|
指定されたホスト名または IP アドレスへの Telnet セッションを開きます。 |
|
IPv4 宛先への Telnet セッションを強制します。 |
|
IPv6 宛先への Telnet セッションを強制します。 |
|
ホスト上のポート番号またはサービス名を指定します。 |
|
Telnet セッションに指定されたルーティング インスタンスを使用します。 |
sshコマンド
CLI ssh
コマンドを使用して、セキュアシェル(SSH)プログラムを使用し、リモートデバイスへの接続を開けることができます。
user@host> ssh host <bypass-routing> <inet> <inet6> <interface interface-name> <logical-system> <routing-instance routing-instance-name> <source address> <v2>
表 2 に、 ssh
コマンドのオプションを示します。
オプション |
形容 |
---|---|
|
ルーティングテーブルをバイパスし、SSH接続を直接接続されたインターフェースのホストのみに開きます。ホストが直接接続されたインターフェイスではない場合、エラー メッセージが返されます。 |
|
SSH 接続を、指定されたホスト名または IP アドレスへ開きます。 |
|
IPv4 の宛先への SSH 接続を強制します。 |
|
IPv6 の宛先への SSH 接続を強制します。 |
|
SSH接続を、指定されたインターフェース上のホストに開きます。このオプションが含まれていない場合、すべてのインターフェイスが使用されます。 |
|
SSH接続に指定されたルーティングインスタンスを使用します。 |
|
SSH 接続に指定された論理システムを使用します。 |
|
SSH接続に、指定された送信元アドレスを使用します。 |
|
SSH を強制して、接続にバージョン 2 を使用します。 |
データを安全にコピーするためのSSH Knownホストキーを設定する
セキュアシェル(SSHh)は、 暗号アルゴリズムを使用し、安全なデータ送信を確実に行うホスト、サーバー、セッションキーシステムを生成します。設定アーカイブやイベントログなどのデータのバックグラウンド転送向けの FTPの代替として、SSHホストキーを設定し、安全なコピー(SCP)をサポートできます。SCP向けSSHサポートを設定するには、以下のタスクを完了する必要があります。
-
ルーティングエンジン設定階層にホスト名とホストキー情報を入れ、SSHの既知のホストを指定します。
-
SCP URLを設定して、データを受信するホストを指定します。この属性を設定すると、SCPサーバーからSSHホストキー情報を自動的に取得します。
-
ホストキーが本物であるかどうかを検証します。
-
安全な接続を受け入れます。接続を受け入れることで、ローカルホストキーデータベースにホストキー情報が自動的に保存されます。設定階層にホストキー情報を保存することで、安全なハンドシェイクを自動化し、SCPを使用してのバックグラウンドデータ転送が可能になります。
データの安全なコピーのためのSSHホストキーを設定するタスクは、以下の通りです。
SSH既知のホストを設定する
SSHの既知のホストを設定するには、 host
ステートメントを含め、 [edit security ssh-known-hosts]
階層レベルで信頼できるサーバーのホスト名とホストキーオプションを指定します。
[edit security ssh-known-hosts] host corporate-archive-server { dsa-key key; } host archive-server-url { rsa-key key; } host server-with-ssh-version-1 { rsa1-key key; }
ホストキーは、以下のいずれかです。
-
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
ステートメントを含めます。
[edit system archival configuration] archive-sites { scp://username<:password>@host<:port>/url-path; }
IPv6ホストアドレスを使用してJunos OS EvolvedステートメントのURLを指定する場合、URL全体を引用符("")で囲み、IPv6ホストアドレスを括弧([ ])で囲む必要があります。たとえば、"scp://<c7/><:<c8/>>@[<c9/>]<:<c10/>>/<c11/>";
SCP URLを指すように archive-sites
ステートメントを設定すると、自動ホストキー取得がトリガーされます。この時点で、 Junos OS Evolved はSCPホストに接続してSSHパブリックキーを取得し、ホストキーメッセージダイジェストまたはフィンガープリントをコンソールへの出力として表示して、サーバーへの接続を終了します。
user@host# set system archival configuration archive-sites “<scp-url-path>” The authenticity of host <my-archive-server (<server-ip-address>)> can’t be established. RSA key fingerprint is <ascii-text key>. Are you sure you want to continue connecting (yes/no)?
ホストキーが純正であることを確認するには、このフィンガープリントを、信頼できる送信元を使って同じホストから取得するフィンガープリントと比較します。フィンガープリントが同一である場合は、プロンプトで yes と入力して、ホストキーを受け入れます。次に、ホストキー情報がルーティングエンジン設定に保存され、SCPを使用してバックグラウンドデータ転送をサポートします。
SSHホストキー情報を更新する
通常、SSHホストキー情報は、[edit system]
階層レベルでarchival configuration archive-sites
ステートメントを使用してSCPのURL属性を設定すると自動的に取得されます。ただし、ホストキーデータベースを手動で更新する必要がある場合は、以下の方法のいずれかを使用します。
ホストキー情報を手動で取得する
SSHパブリックホストキー情報を手動で取得するには、[edit security ssh-known-hosts]
階層レベルでfetch-from-server
オプションを設定します。SSHパブリックキーを取得するホストを指定する必要があります。
user@host# set security ssh-known-hosts fetch-from-server <hostname>
ファイルからホストキー情報をインポートする
known_hostsファイルからSSHホストキー情報を手動でインポートするには、[edit security ssh-known-hosts]
階層レベルでload-key-file
オプションを含めます。ホストキー情報をインポートするファイルへのパスを指定する必要があります。
user@host# set security ssh-known-hosts load-key-file /var/tmp/known-hosts
レガシー暗号化をサポートする SSH サービスの設定
Junos OS EvolvedのSSHサーバーはOpenSSH 7に基づいており、デフォルトは、よりセキュアな暗号方式と鍵交換アルゴリズムのセットになります。OpenSSH 7 は、一部のレガシー暗号化を省略します。
これらの拡張の詳細については、 https://www.openssh.com/ にある OpenSSH 7 のドキュメントを参照してください。
Junos OS Evolved は、デフォルトで以下の暗号方式をサポートしています。
-
chacha20-poly1305@openssh.com
-
aes128-ctr
-
aes192-ctr
-
aes256-ctr
-
aes128-gcm@openssh.com
-
aes256-gcm@openssh.com
Junos OS Evolvedでは、以下の暗号方式はデフォルトではサポートされていませんが、デバイスがサポートするように設定できます。これらは、セキュリティが最も強いものから最も弱いものまで多岐にわたります。
-
aes256-cbc
-
aes192-cbc
-
aes128-cbc
Junos OS Evolved は、デフォルトで以下の鍵交換方法をサポートしています。
-
curve25519-sha256
-
ecdh-sha2-nistp256
-
ecdh-sha2-nistp384
-
ecdh-sha2-nistp521
-
group-exchange-sha2
-
dh-group14-sha1
Junos OS Evolvedでは、以下の鍵交換方法はデフォルトではサポートされていませんが、デバイスがサポートするように設定できます。
-
group-exchange-sha1
-
dh-group1-sha1
SSH サービスがレガシー暗号化をサポートするように設定するには:
暗号方式、鍵交換方法、またはMAC(メッセージ認証コード)の順序付きセットを設定することで、新しく定義されたセットがサーバー コマンドとクライアント コマンドの両方に適用されます。デフォルトの変更は、SCP(セキュア コピー プロトコル)を使用する場合、 file copy
コマンドに影響します。
関連項目
アウトバウンドSSHサービスを設定する
Junos OS Evolvedを実行しているデバイスを設定して、クライアント管理アプリケーションとの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 接続のキープアライブメッセージを設定する
- 新しいアウトバウンドSSH接続を設定する
- アウトバウンド SSH クライアントを設定して、利用可能なサービスとして NETCONF を承認する
- アウトバウンドSSHクライアントを設定する
- アウトバウンド SSH クライアントにルーティングインスタンスを設定する
アウトバウンド SSH クライアントに公開 SSH ホストキーを送信する
ルーターまたはスイッチがアウトバウンド SSH 接続を確立するたびに、まず管理クライアントに開始シーケンスを送信します。このシーケンスは、管理クライアントに対してルーターまたはスイッチを識別します。この送信内には device-id の値があります。
ルーターまたはスイッチのデバイスIDを設定するには、[edit system services outbound-ssh client client-id]
階層レベルに device-id
ステートメントを含めます。
[edit system services outbound-ssh client client-id] device-id device-id;
secret
が設定されていない場合の開始シーケンス:
MSG-ID: DEVICE-CONN-INFO\r\n MSG-VER: V1\r\n DEVICE-ID: <device-id>\r\n
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
ステートメントを含めます。
[edit system services outbound-ssh client client-id] secret password;
secret
属性が設定された時点で、次のメッセージがデバイスによって送信されます:
MSG-ID: DEVICE-CONN-INFO\r\n MSG-VER: V1\r\n DEVICE-ID: <device-id>\r\n HOST-KEY: <public-host-key>\r\n HMAC:<HMAC(pub-SSH-host-key, <secret>>)>\r\n
アウトバウンド SSH 接続のキープアライブメッセージを設定する
クライアントアプリケーションにルーターまたはスイッチの公開SSHホストキーが設定されたら、TCP/IP接続が作成されたときと同様にSSHシーケンスを開始できます。クライアントは、そのシーケンスの一部として、ルーターまたはスイッチの公開ホスト SSH キーのコピーを使用してデバイスを認証できます。デバイスは、 Junos OS Evolved でサポートされているメカニズム(RSA/DSA公開文字列またはパスワード認証)を通してクライアントユーザーを認証します。
デバイスが SSH プロトコルキープアライブメッセージをクライアントアプリケーションに送信できるようにするには、[edit system services outbound-ssh client client-id]
階層レベルで keep-alive
ステートメントを設定します。
[edit system services outbound-ssh client client-id] keep-alive { retry number; timeout seconds; }
新しいアウトバウンドSSH接続を設定する
切断されると、デバイスが新しいアウトバウンド SSH 接続を開始し始めます。接続デバイスがドロップされた後でサーバーに再接続する方法を指定するには、[edit system services outbound-ssh client client-id]
階層レベルに reconnect-strategy
ステートメントを含めます。
[edit system services outbound-ssh client-id] reconnect-strategy (sticky | in-order);
また、再試行回数を指定して、再接続が停止されるまでの時間を設定することもできます。 アウトバウンド SSH 接続のキープアライブメッセージを設定するを参照してください。
アウトバウンド SSH クライアントを設定して、利用可能なサービスとして NETCONF を承認する
利用可能なサービスとしてNETCONFを承認するようアプリケーションを設定するには、[edit system services outbound-ssh client client-id]
階層レベルで services netconf
ステートメントを含めます。
[edit system services outbound-ssh client client-id] services { netconf; }
アウトバウンドSSHクライアントを設定する
このアウトバウンド SSH 接続で利用可能なクライアントを設定するには、 [edit system services outbound-ssh client client-id]
階層レベルで個別のアドレスステートメントをリストします。
[edit system services outbound-ssh client client-id] address address { retry number; timeout seconds; port port-number; }
アウトバウンドSSH接続は、IPv4およびIPv6アドレスフォーマットをサポートしています。
アウトバウンド SSH クライアントにルーティングインスタンスを設定する
管理ルーティングインスタンスを使用するには、まず set system management-instance
コマンドを使用して、mgmt_junos
ルーティングインスタンスを有効にします。
他のルーティングインスタンスを使用するには、まず [edit routing-instances]
階層でルーティングインスタンスを設定します。
ルーティングインスタンスを指定しない場合、デバイスはデフォルトのルーティングテーブルを使ってアウトバウンド SSH 接続を確立します。
指定されたTCPポートでのNETCONF-over-SSH接続の設定
Junos OS Evolvedを使用すると、ファイアウォールを設定せずに、指定された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)サービスのデフォルトポートを設定することは推奨しません。