SSHクライアントのカスタム接続オプションの設定方法

はじめに

SSHまたはセキュアシェルは、リモート管理のためのLinuxサーバーへの接続方法として最も一般的です。単一のサーバーにコマンドラインで接続することは比較的簡単ですが、複数のリモートシステムに接続するためのワークフローオプティマイゼーションもあります。

ほとんどのシステムで一般的に使用されているコマンドラインのSSHクライアント、OpenSSHは、カスタマイズされた接続オプションを提供することができます。これらは、サーバーごとに異なるオプションが含まれた設定ファイルに保存することができます。これにより、各ホストごとに使用する異なる接続オプションを分けて整理し、接続するたびに詳細なオプションをコマンドラインで指定する必要がなくなります。

このガイドでは、SSHクライアントの設定ファイルの構造と、いくつかの一般的なオプションについて説明します。

前提条件

このガイドを完成させるためには、SSHについての作業知識と接続時に提供できるいくつかのオプションを必要とします。また、少なくともテスト目的で、いくつかのユーザーやサーバーに対してSSHキーに基づいた認証を設定する必要もあります。

SSH Configファイルの構造と解釈アルゴリズム

あなたのシステム上の各ユーザーは、自分のホームディレクトリ内に独自のSSH設定ファイルを保持することができます。これには、接続パラメータを指定するためにコマンドラインで使用するオプションを含めることができます。また、接続時に追加のフラグをsshコマンドに追加することで、設定ファイルで定義された値を常に上書きすることができます。

SSHクライアントの設定ファイルの場所

お客様側の設定ファイルは、~/.ssh/config に保存されます。ここでの ~ はホームディレクトリへの一般的なショートカットを指します。通常、このファイルはデフォルトでは作成されないため、自分で作成する必要があるかもしれません。もし存在しない場合は、touchコマンドを使用して作成されます(既に存在する場合は最終変更日時が更新されます)。

  1. touch ~/.ssh/config

 

構成ファイルの構造

構成ファイルは、ホストごとに整理されています。つまり、リモートサーバーごとに整理されています。各ホスト定義は、特定のホストに対する接続オプションを定義することができます。より広範な範囲を持つオプションに対してはワイルドカードもサポートされています。

以下の各セクションは、続く構成オプションに一致するホストを定義するヘッダーで始まります。一致するホストの特定の構成項目は、以下に定義されます。デフォルト値と異なる項目のみを指定する必要があります。未定義の項目に対しては、各エントリはデフォルト値を継承します。各セクションは、一つのホストヘッダから次のホストヘッダまで続きます。

通常、組織的な目的と読みやすさのために、各ホストに対して設定されるオプションはインデントされます。これは厳格な要件ではありませんが、一目で解釈することができる便利な規則です。

一般的な形式はこのような感じになります。

以下は日本語で自然に言い換えたものです。いくつかのオプションがありますが、一つだけ表示します:
「~/.ssh/config」
Host firsthost
    Hostname your-server.com
    User username-to-connect-as
    IdentityFile /path/to/non/default/keys.pem

Host secondhost
    ANOTHER_OPTION custom_value

Host *host
    ANOTHER_OPTION custom_value

Host *
    CHANGE_DEFAULT custom_value

ここでは、対象のホストに応じて接続試行ごとに適用される4つのセクションがあります。

解釈アルゴリズム

SSHが設定値を適用するためにファイルを解釈する方法を理解することは重要です。これはワイルドカードやホスト「*」の一般的なホスト定義を使用する際に影響を及ぼします。

SSHは、コマンドラインで指定されたホスト名を設定セクションを定義するホストヘッダーのそれぞれと一致させます。

例えば、以下の定義を考えてみましょう。

~/.ssh/configを日本語で自然に言い換えると、次のようになります:
ホームディレクトリの.ssh/configファイル
Host devel
    HostName devel.example.com
    User tom

このホストでは、コマンドラインにこれを入力することで、私たちはtom@devel.example.comとして接続することができます。

  1. ssh devel

 

SSHは設定ファイルの最上部から始まり、コマンドラインで指定された値と一致するかどうかを確認するために各ホスト定義をチェックします。最初に一致するホスト定義が見つかった場合、関連するSSHオプションは次の接続に適用されます。

SSHは、その後ファイルをスクロールダウンして、他のホスト定義とも一致するかどうかをチェックします。コマンドラインで指定された現在のホスト名に一致する他の定義が見つかった場合、SSHは新しいセクションに関連付けられたSSHオプションを考慮します。前のセクションで既に定義されていない新しいセクションのSSHオプションを適用します。

これは重要なポイントです。SSHは、コマンドラインで指定したホスト名に一致する各ホストセクションを順番に解釈します。このプロセス中、常に各オプションの最初に指定された値が使用されます。以前に一致したセクションによって既に値が指定されている場合、その値を上書きする方法はありません。

これは、設定ファイルは最も具体的な設定を先頭に持つべきであることを意味しています。一つ前の一致するセクションで定義されていなかったオプションを適用するために、より一般的な定義は後になるべきです。

前のセクションからの例をもう一度見てみましょう。 (Mae no sekushon kara no rei o mōichido mite mimashou.)

「~/.ssh/config」を日本語で自然に言い換えると、以下のようになります :
ホームディレクトリ以下の.sshフォルダ内のconfigファイル
Host firsthost
    Hostname your-server.com
    User username-to-connect-as
    IdentityFile /path/to/non/default/keys.pem

Host secondhost
    ANOTHER_OPTION custom_value

Host *host
    ANOTHER_OPTION custom_value

Host *
    CHANGE_DEFAULT custom_value

ここでは、最初の2つのセクションが文字通りのホスト名(またはエイリアス)によって定義されていることがわかります。つまり、ワイルドカードは使用されていません。sshを使用してfirsthostに接続すると、最初のセクションが適用されます。これによって、この接続のためのホスト名、ユーザー、およびIdentityFileが設定されます。

それは第二セクションをチェックし、一致しないことを確認して次に進みます。それから、第三セクションを見つけ、一致することを確認します。それから、既に前のセクションでANOTHER_OPTIONの値を持っているかどうかを確認します。それがないことがわかると、このセクションからの値を適用します。最後のセクションも一致するので、Host * の定義はすべての接続に一致します。他のセクションでのモックのCHANGE_DEFAULTオプションの値を持っていないので、このセクションからの値を使用します。このプロセスで収集されたオプションで接続が行われます。

もう一度試してみましょう。コマンドラインからssh secondhostを呼び出していると仮定しましょう。

再び、最初のセクションから始まり、一致するかどうかをチェックします。これは最初のホストへの接続にのみ一致するため、このセクションはスキップされます。次に、2番目のセクションに進みます。このセクションがリクエストと一致することがわかったら、この接続のANOTHER_OPTIONの値を収集します。

SSHは次に第3の定義を見て、ワイルドカードが現在の接続に一致することを確認します。その後、ANOTHER_OPTIONの値が既に存在するかどうかをチェックします。このオプションは既に一致した第2のセクションで定義されていたため、第3のセクションの値は破棄され、影響を及ぼしません。

SSHはその後、4番目のセクションをチェックし、先に一致したセクションで定義されていないオプションを適用します。それから収集した値を使用して接続を試みます。

接続オプション

設定ファイルの書き方についてアイデアがわかったので、一緒に一般的なオプションとそれらをコマンドラインで指定するための形式について話しましょう。

最初にカバーするのは、リモートホストに接続するために必要な最低限の設定です。具体的には、SSHサーバーが動作しているホスト名、ユーザー名、およびポート番号です。

コマンドラインから、ユーザー名がapolloで、ポート4567でSSHデーモンを実行しているホストであるexample.comに接続するためには、次のようにsshを実行できます。「ssh apollo@example.com -p 4567」

ssh -p 4567 apollo@example.com

しかし、-o フラグを使用して、オプションの完全な名前も使用することもできます。

ssh -o "User=apollo" -o "Port=4567" -o "HostName=example.com"

SSHマニュアルページには利用可能なオプションの完全なリストが掲載されています。

設定ファイルにこれらを設定するには、homeのようなホストヘッダ名を選択する必要があります。

Host home
    HostName example.com
    User apollo
    Port 4567

一般的なSSHの設定オプション

これまで、接続を確立するために必要ないくつかのオプションについて話し合ってきました。以下のオプションを取り上げました。

  • HostName: The actual hostname that should be used to establish the connection. This replaces any alias defined in the Host header. This option is not necessary if the Host definition specifies the actual valid address to connect to.
  • User: The username to be used for the connection.
  • Port: The port that the remote SSH daemon is running on. This option is only necessary if the remote SSH instance is not running on the default port 22.

他にも探索する価値のある便利なオプションがたくさんあります。一般的なオプションの中から、機能ごとにいくつかを紹介します。

一般的な調整と接続アイテム

  • ServerAliveInterval: This option can be configured to let SSH know when to send a packet to test for a response from the server. This can be useful if your connection is unreliable and you want to know if it is still available.
  • LogLevel: This configures the level of detail in which SSH will log on the client-side. This can be used for turning off logging in certain situations or increasing the verbosity when trying to debug. From least to most verbose, the levels are QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG1, DEBUG2, and DEBUG3.
  • StrictHostKeyChecking: This option configures whether ssh SSH will ever automatically add hosts to the ~/.ssh/known_hosts file. By default, this will be set to “ask” meaning that it will warn you if the Host Key received from the remote server does not match the one found in the known_hosts file. If you are constantly connecting to a large number of ephemeral hosts (such as testing servers), you may want to turn this to “no”. SSH will then automatically add any hosts to the file. This can have security implications if your known hosts ever do change addresses when they shouldn’t, so think carefully before enabling it.
  • UserKnownHostsFile: This option specifies the location where SSH will store the information about hosts it has connected to. Usually you do not have to worry about this setting, but you may wish to set this to /dev/null so they are discarded if you have turned off strict host checking above.
  • VisualHostKey: This option can tell SSH to display an ASCII representation of the remote host’s key upon connection. Turning this on can be a useful way to get familiar with your host’s key, allowing you to recognize it if you have to connect from a different computer sometime in the future.
  • Compression: Turning compression on can be helpful for very slow connections. Most users will not need this.

上記の設定項目を考慮しながら、私たちはいくつかの有用な設定の微調整を行うことができます。 (Jōki no settei kōmoku o kōryoshinagara, watashitachi wa ikutsu ka no yūyōna settei no bitōchō o okonau koto ga dekimasu.)

例えば、クラウドプロバイダでホストを素早く作成し破棄する場合、このようなものが役立つかもしれません。

Host home
    VisualHostKey yes

Host cloud*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
    LogLevel QUIET

Host *
    StrictHostKeyChecking ask
    UserKnownHostsFile ~/.ssh/known_hosts
    LogLevel INFO
    ServerAliveInterval 120

これにより、自宅の接続用のビジュアルホストキーが有効になります。これにより、変更された場合や異なるマシンから接続する際に認識できるようになります。また、cloud*で始まるホストについては、ホストのチェックや失敗の記録を行わないように設定しています。その他のホストについては、適切なフォールバック値が設定されています。

接続転送

SSHの一般的な用途の一つは、接続の転送です。これにより、ローカルな接続がリモートホストを経由してトンネリングすることができるだけでなく、リモートマシンがローカルマシンを経由してトンネリングすることも可能です。これは、ファイアウォールの背後にあるリモートマシンに別個の「ゲートウェイ」サーバーを介して接続する必要がある場合に、必要な場合があります。SSHは、SOCKS5などのプロトコルを使用してダイナミックな転送も行うことができます。これには、リモートホストの転送情報が含まれています。

この動作を制御するオプションは、以下の通りです:

  • LocalForward: This option is used to specify a connection that will forward a local port’s traffic to the remote machine, tunneling it out into the remote network. The first argument should be the local port you wish to direct traffic to and the second argument should be the address and port that you wish to direct that traffic to on the remote end.
  • RemoteForward: This option is used to define a remote port where traffic can be directed to in order to tunnel out of the local machine. The first argument should be the remote port where traffic will be directed on the remote system. The second argument should be the address and port to point the traffic to when it arrives on the local system.
  • DynamicForward: This is used to configure a local port that can be used with a dynamic forwarding protocol like SOCKS5. Traffic using the dynamic forwarding protocol can then be directed at this port on the local machine and on the remote end, it will be routed according to the included values.

これらのオプションは、こちらで確認できるように、両方向のポートの転送に使用することができます。

# This will allow us to use port 8080 on the local machine
# in order to access example.com at port 80 from the remote machine
Host local_to_remote
    LocalForward 8080 example.com:80

# This will allow us to offer access to internal.com at port 443
# to the remote machine through port 7777 on the other side
Host remote_to_local
    RemoteForward 7777 internal.com:443

これは、SSH経由でしか直接アクセスできないサーバー上で実行されているプライベートダッシュボードや他のWebアプリケーションをブラウザウィンドウで開く必要がある場合に特に便利です。

他の転送

SSHには、接続転送と同時に他の種類の転送も可能です。

ローカルマシンのエージェントに保存されているSSHキーを転送することで、リモートシステムから、ローカルシステムに保存されている資格情報を使用して接続することができます。また、リモートシステム上でアプリケーションを起動し、X11転送を使用してグラフィカルディスプレイをローカルシステムに転送することもできます。X11はLinuxのディスプレイサーバーであり、Linuxデスクトップシステムがないと直感的に使用することができません。ただし、リモートとローカルの両方でLinux環境を使用している場合には非常に便利です。

これらはこれらの機能に関連する指示です。 (Korera wa korera no kinou ni kansuru shiji desu.)

  • ForwardAgent: This option allows authentication keys stored on our local machine to be forwarded onto the system you are connecting to. This can allow you to hop from host-to-host using your home keys.
  • ForwardX11: If you want to be able to forward a graphical screen of an application running on the remote system, you can turn this option on.

キーの特定

もしホストのためにSSHキーが設定されている場合、これらのオプションは各ホストにどのキーを使用するかを管理するのに役立ちます。

  • IdentityFile: This option can be used to specify the location of the key to use for each host. SSH will use keys located in ~/.ssh by default, but if you have keys assigned per-server, this can be used to specify the exact path where they can be found.
  • IdentitiesOnly: This option can be used to force SSH to only rely on the identities provided in the config file. This may be necessary if an SSH agent has alternative keys in memory that are not valid for the host in question.

これらのオプションは、異なるホストの大量の鍵を管理し、1つ以上のSSHエージェントを利用する必要がある場合に特に便利です。

結論

SSHが値を解釈する方法を念頭に置いておく限り、合理的な代替値で具体的なセットを豊富に設定することができます。

非常に弱いまたは断続的な接続(飛行機のWi-Fiなど)でSSHを使用しなければならない場合は、逆境下で動作するように設計されたmoshを試してみることもできます。

コメントを残す 0

Your email address will not be published. Required fields are marked *