LIBOF

コマンドラインのマニュアル

Man » ssh マニュアルオンライン - ssh マニュアルページの詳細なオンラインドキュメント

🌍 ☰ 
ssh — OpenSSH リモートログインクライアント

概要

ssh   [-46AaCfGgKkMNnqsTtVvXxYy]   [-B   bind_interface]   [-b   bind_address]  [-c  cipher_spec]
[-D  [bind_address:]port]  [-E  log_file]  [-e  escape_char]  [-F  configfile]  [-I   pkcs11]
[-i  identity_file]  [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd]
[-o  option]   [-P   tag]   [-p   port]   [-R   address]   [-S   ctl_path]   [-W   host:port]
[-w local_tun[:remote_tun]] destination [command [argument ...]]
ssh [-Q query_option]

説明

ssh (SSH クライアント) は、リモートマシンにログインし、リモートマシン上でコマンドを実行するためのプログラムです。これは、2つの信頼できないホスト間で安全な暗号化された通信を提供することを目的としており、安全でないネットワーク上で行われます。X11 接続、任意の TCP ポート、および Unix ドメインソケットも、安全なチャネルを介して転送できます。

ssh は、指定された宛先に接続してログインします。宛先は、[user@]hostname または ssh://[user@]hostname[:port] の形式の URI として指定できます。ユーザーは、次のいずれかの方法を使用して、リモートマシンに対して自身の身元を証明する必要があります（以下を参照）。

コマンドが指定された場合、ログインシェルではなく、リモートホスト上でそのコマンドが実行されます。 完全なコマンドラインは、コマンドとして指定することも、追加の引数を指定することもできます。指定された場合、引数はコマンドに追加され、スペースで区切られてからサーバーに送信され、そこで実行されます。

オプションは次のとおりです。

-4      ssh が IPv4 アドレスのみを使用するように強制します。

-6      ssh が IPv6 アドレスのみを使用するように強制します。

-A      ssh-agent(1) などの認証エージェントからの接続の転送を有効にします。これは、構成ファイル内のホストごとに指定することもできます。

エージェントの転送は注意して有効にする必要があります。リモートホスト上のファイルパーミッションを回避できるユーザー（エージェントの Unix ドメインソケットの場合）は、転送された接続を介してローカルエージェントにアクセスできます。攻撃者はエージェントからキーマテリアルを取得することはできませんが、エージェントにロードされた ID を使用して認証できるようにする操作を実行できます。より安全な代替手段は、ジャンプホストを使用することです（-J を参照）。

-a      認証エージェント接続の転送を無効にします。

-B bind_interface
宛先ホストに接続する前に、bind_interface のアドレスにバインドします。これは、複数のアドレスを持つシステムでのみ役立ちます。

-b bind_address
ローカルマシンの bind_address を接続のソースアドレスとして使用します。これは、複数のアドレスを持つシステムでのみ役立ちます。

-C すべてのデータ（stdin、stdout、stderr、および転送されるX11、TCP、およびUnixドメイン接続のデータを含む）の圧縮を要求します。圧縮アルゴリズムは、[gzip]({filename}../../gzip)(1)で使用されるものと同じです。圧縮は、モデム回線やその他の低速接続では望ましいですが、高速ネットワークでは速度が低下するだけです。デフォルト値は、ホストごとに設定ファイルで設定できます。ssh_config(5)の「圧縮」オプションを参照してください。

-c cipher_spec

セッションの暗号化に使用する暗号仕様を選択します。cipher_specは、優先順にリストされた暗号のカンマ区切りリストです。詳細については、ssh_config(5)の「Ciphers」キーワードを参照してください。

-D [bind_address:]port

ローカルの「動的」アプリケーションレベルポートフォワーディングを指定します。これにより、ローカル側でポートをリッスンするソケットが割り当てられ、必要に応じて指定されたbind_addressにバインドされます。このポートに接続が確立されると、接続はセキュアチャネルを介して転送され、アプリケーションプロトコルを使用して、リモートマシンからどこに接続するかを決定します。現在、SOCKS4およびSOCKS5プロトコルがサポートされており、sshはSOCKSサーバーとして機能します。特権ポートをフォワードできるのはrootのみです。動的ポートフォワーディングは、設定ファイルでも指定できます。

IPv6アドレスは、アドレスを角かっこで囲んで指定できます。特権ポートをフォワードできるのはスーパーユーザーのみです。デフォルトでは、ローカルポートはGatewayPorts設定に従ってバインドされます。ただし、明示的なbind_addressを使用して、接続を特定の宛先にバインドできます。bind_addressを「localhost」にすると、リッスンポートはローカルでのみ使用するようにバインドされ、「」または「*」にすると、ポートはすべてのインターフェースからアクセスできるようになります。

-E log_file

debugログを標準エラーではなく、log_fileに追加します。

-e escape_char

ptyを使用するセッションのエスケープ文字を設定します（デフォルト：‘\~’）。エスケープ文字は、行の先頭でのみ認識されます。エスケープ文字の後にドット（‘.’）が続くと、接続が閉じられます。control-Zが続くと、接続が中断されます。エスケープ文字の後にそれ自体が続くと、エスケープ文字が1回送信されます。文字を「none」に設定すると、エスケープが無効になり、セッションが完全に透過されます。

-F configfile

代替のユーザーごとの設定ファイルを指定します。コマンドラインで設定ファイルが指定された場合、システム全体の構成ファイル（/etc/ssh/ssh_config）は無視されます。ユーザーごとの構成ファイルのデフォルトは~/.ssh/configです。これを「none」に設定すると、構成ファイルは読み込まれません。

-f sshがコマンドの実行直前にバックグラウンドに移行するように要求します。これは、sshがパスワードまたはパスフレーズを要求する場合に便利ですが、ユーザーはそれをバックグラウンドで実行したい場合に役立ちます。これは-nを意味します。リモートサイトでX11プログラムを開始する推奨される方法は、ssh -f host xtermを使用することです。

^ xitOnForwardFailure 設定オプションが "yes" に設定されている場合、-f で起動されたクライアントは、すべてのリモートポートフォワードが正常に確立されるまで、バックグラウンドに移行するのを待ちます。詳細は、ssh_config(5) の ForkAfterAuthentication の説明を参照してください。

^ G ssh は、Host ブロックと Match ブロックを評価した後、構成を出力して終了します。

^ g リモートホストがローカルでフォワードされたポートに接続できるようにします。複数化された接続で使用する場合、このオプションはマスタープロセスで指定する必要があります。

^ I pkcs11 ssh が PKCS#11 トークンと通信するために使用する PKCS#11 共有ライブラリを指定します。このトークンは、ユーザー認証のためのキーを提供します。

^ i identity_file パブリックキー認証で使用する ID (秘密鍵) を読み込むファイルを選択します。パブリックキーファイルを指定することもでき、その場合、ローカルに秘密鍵ファイルが存在しない場合は、ssh-agent(1) にロードされている対応する秘密鍵が使用されます。デフォルトは ~/.ssh/id_rsa、~/.ssh/id_ecdsa、~/.ssh/id_ecdsa_sk、~/.ssh/id_ed25519、および ~/.ssh/id_ed25519_sk です。ID ファイルは、構成ファイルでホストごとに指定することもできます。複数の -i オプション (および構成ファイルで指定された複数の ID) を使用できます。CertificateFile ディレクティブで明示的に指定された証明書がない場合、ssh は ID ファイル名に -cert.pub を追加したファイル名から証明書情報をロードしようとします。

^ J destination ターゲットホストに接続するには、まず destination で説明されているジャンプホストに ssh 接続し、次にそこから最終的な宛先への TCP フォワーディングを確立します。複数のジャンプホップをカンマで区切って指定できます。IPv6 アドレスは、角かっこで囲んで指定できます。これは、ProxyJump 構成ディレクティブを指定するショートカットです。コマンドラインで指定された構成ディレクティブは、通常、宛先ホストに適用され、指定されたジャンプホストには適用されないことに注意してください。ジャンプホストの構成は、~/.ssh/config を使用して指定します。

^ K GSSAPI ベースの認証と、サーバーへの GSSAPI 認証情報のフォワーディング (委任) を有効にします。

^ k サーバーへの GSSAPI 認証情報のフォワーディング (委任) を無効にします。

^ L [bind_address:]port:host:hostport ^ L [bind_address:]port:remote_socket ^ L local_socket:host:hostport ^ L local_socket:remote_socket 指定された TCP ポートまたは Unix ソケットへの接続を、ローカル (クライアント) ホストで行い、それをリモート側の指定されたホストとポート、または Unix ソケットにフォワーディングします。これにより、ローカル側で TCP ポート、または指定された bind_address にバインドされた Unix ソケットにリッスンするソケットが割り当てられます。ローカルポートまたはソケットへの接続が行われると、その接続はセキュアチャネル経由でフォワーディングされ、リモートマシンからホストポート hostport、または Unix ソケット remote_socket への接続が確立されます。

ポートフォワーディングは、設定ファイルでも指定できます。特権ポートをフォワーディングできるのはスーパーユーザーのみです。IPv6アドレスは、アドレスを角括弧で囲んで指定できます。

デフォルトでは、ローカルポートはGatewayPorts設定に従ってバインドされます。ただし、明示的なbind_addressを使用して、接続を特定の宛先にバインドできます。bind_addressに「localhost」を指定すると、リッスンポートがローカルでのみ使用されるようにバインドされ、空のアドレスまたは「*」を指定すると、ポートがすべてのインターフェースからアクセス可能になります。

-l login_name
リモートマシンにログインするユーザーを指定します。これも、設定ファイルでホストごとに指定できます。

-M
SSHクライアントを「マスター」モードで接続共有できるようにします。複数の-Mオプションを指定すると、SSHは「マスター」モードになりますが、ssh-askpass(1)を使用して、マルチプレクシングの状態を変更する各操作（新しいセッションを開くなど）の前に確認が必要になります。詳細については、ssh_config(5)のControlMasterの説明を参照してください。

-m mac_spec
カンマで区切られたMAC（メッセージ認証コード）アルゴリズムのリストで、優先順に指定します。詳細については、ssh_config(5)のMACsキーワードを参照してください。

-N
リモートコマンドを実行しません。これは、ポートをフォワーディングするためだけに役立ちます。詳細については、ssh_config(5)のSessionTypeの説明を参照してください。

-n
stdinを/dev/nullからリダイレクトします（実際には、stdinからの読み取りを防止します）。これは、SSHをバックグラウンドで実行する場合に使用する必要があります。一般的なテクニックは、これを使用して、リモートマシンでX11プログラムを実行することです。たとえば、ssh -n shadows.cs.hut.fi emacs &は、shadows.cs.hut.fiでemacsを開始し、X11接続は暗号化されたチャネルを介して自動的にフォワードされます。SSHプログラムはバックグラウンドで実行されます。（これは、SSHがパスワードまたはパスフレーズを尋ねる必要がある場合、または-fオプションも参照してください。動作しません。）詳細については、ssh_config(5)のStdinNullの説明を参照してください。

-O ctl_cmd
アクティブな接続マルチプレクシングマスタープロセスを制御します。-Oオプションが指定された場合、ctl\_cmd引数は解釈され、マスタープロセスに渡されます。有効なコマンドは、「check」（マスタープロセスが実行されているか確認する）、「forward」（コマンドの実行なしでフォワーディングを要求する）、「cancel」（フォワーディングをキャンセルする）、「proxy」（実行中のマルチプレクシングマスターにプロキシモードで接続する）、「exit」（マスターにマルチプレクシングを終了するように要求する）、「stop」（マスターにそれ以上のマルチプレクシング要求の受け入れを停止するように要求する）です。

-o option
設定ファイルで使用される形式でオプションを指定するために使用できます。これは、個別のコマンドラインフラグがないオプションを指定する場合に役立ちます。以下のオプションと、その可能な値の詳細については、ssh_config(5)を参照してください。

AddKeysToAgent
AddressFamily
BatchMode
BindAddress
BindInterface
CASignatureAlgorithms
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
CertificateFile
ChannelTimeout
CheckHostIP
Ciphers
ClearAllForwardings
Compression
ConnectTimeout
ConnectionAttempts
ControlMaster
ControlPath
ControlPersist
DynamicForward
EnableEscapeCommandline
EnableSSHKeysign
EscapeChar
ExitOnForwardFailure
FingerprintHash
ForkAfterAuthentication
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GSSAPIAuthentication
GSSAPIKeyExchange
GSSAPIClientIdentity
GSSAPIDelegateCredentials
GSSAPIKexAlgorithms
GSSAPIRenewalForcesRekey
GSSAPIServerIdentity
GSSAPITrustDns
GatewayPorts
GlobalKnownHostsFile
HashKnownHosts
Host
HostKeyAlgorithms
HostKeyAlias
HostbasedAcceptedAlgorithms
HostbasedAuthentication
Hostname
IPQoS
IdentitiesOnly
IdentityAgent
IdentityFile
IgnoreUnknown
Include
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
KnownHostsCommand
LocalCommand
LocalForward
LogLevel
LogVerbose
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
ObscureKeystrokeTiming
PKCS11Provider
PasswordAuthentication
PermitLocalCommand
PermitRemoteOpen
Port
PreferredAuthentications
ProxyCommand
ProxyJump
ProxyUseFdpass
PubkeyAcceptedAlgorithms
PubkeyAuthentication
RekeyLimit
RemoteCommand
RemoteForward
RequestTTY
RequiredRSASize
RevokedHostKeys
SecurityKeyProvider
SendEnv
ServerAliveCountMax
ServerAliveInterval
SessionType
SetEnv
StdinNull
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
SyslogFacility
TCPKeepAlive
Tag
Tunnel
TunnelDevice
UpdateHostKeys
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation

-P tag   `ssh_config(5)` で構成を選択するために使用できるタグ名を指定します。
[Tag] および [Match] キーワードについては、`ssh_config(5)` を参照してください。
-p port
リモートホストで接続するポート。これは、構成ファイルでホストごとに指定できます。

-Q query_option
次の機能のいずれかによってサポートされているアルゴリズムをクエリします。cipher (サポートされている対称暗号)、cipher-auth (認証された暗号化をサポートする対称暗号)、help (-Q フラグで使用するためのサポートされているクエリ用語)、mac (サポートされているメッセージ整合性コード)、kex (鍵交換アルゴリズム)、kex-gss (GSSAPI 鍵交換アルゴリズム)、key (鍵タイプ)、key-ca-sign (証明書に対する有効な CA 署名アルゴリズム)、key-cert (証明書鍵タイプ)、key-plain (非証明書鍵タイプ)、key-sig (すべての鍵タイプと署名アルゴリズム)、protocol-version (サポートされている SSH プロトコルバージョン)、および sig (サポートされている署名アルゴリズム)。または、[ssh_config(5)] または [sshd_config(5)] のキーワードで、アルゴリズムリストを受け入れるものは、対応する query_option のエイリアスとして使用できます。

-q      静音モード。ほとんどの警告および診断メッセージを抑制します。

-R [bind_address:]port:host:hostport
-R [bind_address:]port:local_socket
-R remote_socket:host:hostport
-R remote_socket:local_socket
-R [bind_address:]port
リモート（サーバー）ホストの指定されたTCPポートまたはUnixソケットへの接続をローカル側に転送するように指定します。

これは、リモート側にTCPポートまたはUnixソケットのいずれかに接続するためのソケットを割り当てることによって機能します。このポートまたはUnixソケットへの接続が確立されると、接続はセキュアチャネルを介して転送され、ローカルマシンから明示的な宛先（host:hostportまたはlocal_socketで指定）への接続が確立されます。
または、明示的な宛先が指定されていない場合、sshはSOCKS 4/5プロキシとして機能し、リモートのSOCKSクライアントによって要求された宛先への接続を転送します。

ポートフォワーディングは、構成ファイルにも指定できます。特権ポートは、リモートマシンでrootとしてログインしている場合にのみ転送できます。IPv6アドレスは、アドレスを角括弧で囲んで指定できます。

デフォルトでは、サーバー上のTCPリスニングソケットは、ループバックインターフェイスにのみバインドされます。これは、bind_addressを指定することでオーバーライドできます。空のbind_addressまたはアドレス「*」は、リモートソケットがすべてのインターフェイスでリッスンするように指示します。リモートのbind_addressを指定するには、サーバーのGatewayPortsオプションが有効になっている必要があります（sshd_config(5)を参照）。

ポート引数が「0」の場合、リスンポートはサーバー上で動的に割り当てられ、実行時にクライアントに報告されます。-O forwardと組み合わせて使用​​すると、割り当てられたポートが標準出力に出力されます。

-S ctl_path
接続共有用のコントロールソケットの場所を指定するか、「none」という文字列を指定して、接続共有を無効にします。ControlPathおよびControlMasterの説明については、ssh_config(5)を参照してください。

-s      リモートシステムでサブシステムを呼び出すように要求するために使用できます。サブシステムは、SSHを他のアプリケーション（例：[sftp]({filename}../../sftp)(1)）のセキュアな転送として使用するための機能を提供します。サブシステムは、リモートコマンドとして指定されます。SessionTypeの説明については、ssh_config(5)を参照してください。

-T      疑似端末の割り当てを無効にします。

-t      疑似端末の割り当てを強制します。これは、リモートマシンで任意の画面ベースのプログラムを実行するために使用できます。たとえば、メニューサービスを実装する場合に役立ちます。複数の-tオプションは、sshにローカルttyがない場合でも、ttyの割り当てを強制します。

-V      バージョン番号を表示して終了します。

-v      詳細モード。sshは、進行状況に関するデバッグメッセージを出力します。これは、接続、認証、および構成の問題のデバッグに役立ちます。複数の-vオプションは、詳細度を上げます。最大値は3です。

-W host:port

クライアントの標準入力と出力を、セキュアなチャネルを介して host の port に転送するように要求します。-N、-T、ExitOnForwardFailure、および ClearAllForwardings も暗黙的に有効になりますが、これらは構成ファイルまたは -o コマンドラインオプションを使用してオーバーライドできます。

-w local_tun[:remote_tun]

指定された tun(4) デバイスを使用して、クライアント (local_tun) とサーバー (remote_tun) の間にトンネルデバイス転送を要求します。

デバイスは、数値 ID またはキーワード「any」で指定できます。これにより、次の使用可能なトンネルデバイスが使用されます。remote_tun が指定されていない場合は、デフォルトで「any」になります。ssh_config(5) の Tunnel および TunnelDevice ディレクティブも参照してください。

Tunnel ディレクティブが設定されていない場合、デフォルトのトンネルモード (「ポイントツーポイント」) が設定されます。別のトンネル転送モードが必要な場合は、-w オプションの前に指定する必要があります。

-X      X11 転送を有効にします。これは、構成ファイル内のホストごとに指定することもできます。

X11 転送は注意して有効にする必要があります。リモートホストのファイル権限を回避できるユーザー (ユーザーの X 認証データベースの場合) は、転送された接続を介してローカルの X11 ディスプレイにアクセスできます。攻撃者は、キーストロークの監視などのアクティビティを実行できる場合があります。

この理由から、X11 転送はデフォルトで X11 SECURITY 拡張機能の制限の対象となります。ssh -Y オプションと ssh_config(5) の ForwardX11Trusted ディレクティブを参照してください。

(Debian 固有: X11 転送は、X11 SECURITY 拡張機能の制限の対象となっていません。これは、多くのプログラムがこのモードでクラッシュするためです。ForwardX11Trusted オプションを「no」に設定して、アップストリームの動作を復元できます。これは、クライアント側の改善に応じて将来変更される可能性があります。)

-x      X11 転送を無効にします。

-Y      信頼された X11 転送を有効にします。信頼された X11 転送は、X11 SECURITY 拡張機能の制御の対象となりません。

(Debian 固有: デフォルトの構成では、このオプションは -X と同じです。これは、ForwardX11Trusted が上記のように「yes」のデフォルトであるためです。ForwardX11Trusted オプションを「no」に設定して、アップストリームの動作を復元できます。これは、クライアント側の改善に応じて将来変更される可能性があります。)

-y      syslog(3) システムモジュールを使用してログ情報を送信します。デフォルトでは、この情報は stderr に送信されます。

ssh は、さらに、ユーザーごとの構成ファイルとシステム全体の構成ファイルから構成データを取得できます。ファイル形式と構成オプションは、ssh_config(5) に記載されています。

認証

OpenSSH SSH クライアントは、SSH プロトコルバージョン 2 をサポートしています。

利用可能な認証方法は次のとおりです: GSSAPI ベースの認証、ホストベースの認証、公開鍵認証、キーボードインタラクティブ認証、およびパスワード認証。認証方法は、上記の順に試行されますが、PreferredAuthentications を使用してデフォルトの順序を変更できます。

ホストベース認証は、次のように機能します。ユーザーがログインするマシンが、リモートマシンの /etc/hosts.equiv または /etc/ssh/shosts.equiv にリストされている場合、ユーザーが root ユーザーではなく、両方のマシンでユーザー名が同じである場合、またはユーザーのホームディレクトリにある .rhosts または .shosts ファイルに、クライアントマシンの名前とクライアントマシン上のユーザー名を含む行が含まれている場合、ユーザーはログインの対象と見なされます。さらに、サーバーはクライアントのホストキーを検証できる必要があります（/etc/ssh/ssh_known_hosts および ~/.ssh/known_hosts の説明を参照）。この認証方法は、IP スプーフィング、DNS スプーフィング、ルーティングスプーフィングによるセキュリティ上の脆弱性を解消します。 [管理者への注意：/etc/hosts.equiv、~/.rhosts、および rlogin/rsh プロトコルは、本質的に安全ではないため、セキュリティが必要な場合は無効にしてください。]

公開鍵認証は、次のように機能します。この方式は、公開鍵暗号に基づいており、公開鍵と秘密鍵を別々に使用して暗号化と復号化を行い、暗号化キーから復号化キーを推測することが不可能です。各ユーザーは、認証のために公開鍵と秘密鍵のペアを作成します。サーバーは公開鍵を知っており、ユーザーのみが秘密鍵を知っています。ssh は、ECDSA、Ed25519、または RSA のいずれかのアルゴリズムを使用して、公開鍵認証プロトコルを自動的に実装します。

ファイル ~/.ssh/authorized_keys には、ログインを許可する公開鍵がリストされています。ユーザーがログインすると、ssh プログラムはサーバーに、認証に使用するキーペアを伝えます。クライアントは、秘密鍵にアクセスできることを証明し、サーバーは、対応する公開鍵がアカウントを受け入れるように承認されていることを確認します。

サーバーは、別の方法で認証が完了した後、公開鍵認証が成功しなかった原因となったエラーをクライアントに通知できます。これらは、LogLevel を DEBUG 以上に上げることで確認できます（例：-v フラグを使用）。

ユーザーは、ssh-keygen(1) を実行してキーペアを作成します。これにより、秘密鍵が ~/.ssh/id_ecdsa (ECDSA)、~/.ssh/id_ecdsa_sk (Authenticator-hosted ECDSA)、~/.ssh/id_ed25519 (Ed25519)、~/.ssh/id_ed25519_sk (Authenticator-hosted Ed25519)、または ~/.ssh/id_rsa (RSA) に、公開鍵が ~/.ssh/id_ecdsa.pub (ECDSA)、~/.ssh/id_ecdsa_sk.pub (Authenticator-hosted ECDSA)、~/.ssh/id_ed25519.pub (Ed25519)、~/.ssh/id_ed25519_sk.pub (Authenticator-hosted Ed25519)、または ~/.ssh/id_rsa.pub (RSA) に、ユーザーのホームディレクトリに保存されます。次に、ユーザーは公開鍵をリモートマシンのホームディレクトリにある ~/.ssh/authorized_keys にコピーする必要があります。authorized_keys ファイルは、従来の ~/.rhosts ファイルに対応し、1 行に 1 つのキーが含まれます。ただし、行は非常に長くなる可能性があります。その後、ユーザーはパスワードを入力せずにログインできます。

公開鍵認証のバリエーションとして、証明書認証が利用できます。
公開鍵/秘密鍵のセットの代わりに、署名された証明書を使用します。これにより、複数の公開鍵/秘密鍵の代わりに、単一の信頼された認証局を使用できるという利点があります。
詳細は、ssh-keygen(1) の CERTIFICATES セクションを参照してください。

公開鍵または証明書認証を使用する最も便利な方法は、認証エージェントを使用することです。ssh-agent(1) および (オプションで) ssh_config(5) の AddKeysToAgent ディレクティブを参照して、詳細を確認してください。

キーボードインタラクティブ認証は、次のように機能します。サーバーは任意の「チャレンジ」テキストを送信し、応答を促します。この処理は複数回繰り返される場合があります。キーボードインタラクティブ認証の例としては、BSD認証 (login.conf(5) 参照) や PAM (OpenBSD 以外のシステム) などがあります。

最後に、他の認証方法が失敗した場合、ssh はユーザーにパスワードを要求します。パスワードはリモートホストに送信されて検証されます。ただし、すべての通信は暗号化されているため、パスワードはネットワークを監視している人には見ることができません。

ssh は、これまで使用したすべてのホストの識別情報を保持し、チェックするデータベースを自動的に維持します。ホストキーは、ユーザーのホームディレクトリにある ~/.ssh/known_hosts に保存されます。さらに、/etc/ssh/ssh_known_hosts ファイルも既知のホストに対して自動的にチェックされます。新しいホストはユーザーのファイルに自動的に追加されます。ホストの識別情報が変更された場合、ssh は警告を発し、パスワード認証を無効にします。これにより、サーバーの偽装や中間者攻撃を防ぎ、それらを暗号化を回避するために使用されるのを防ぎます。StrictHostKeyChecking オプションを使用して、既知ではないホストキーを持つマシンへのログインを制御できます。

ユーザーの識別情報がサーバーによって受け入れられると、サーバーは指定されたコマンドを非インタラクティブなセッションで実行するか、コマンドが指定されていない場合は、マシンにログインして、ユーザーに通常のシェルをインタラクティブなセッションとして提供します。リモートコマンドまたはシェルとのすべての通信は自動的に暗号化されます。

インタラクティブなセッションが要求された場合、ssh はデフォルトで、クライアントにターミナルがある場合にのみ、疑似端末 (pty) を要求します。-T フラグと -t フラグを使用して、この動作をオーバーライドできます。

疑似端末が割り当てられている場合、ユーザーは以下に記載されているエスケープ文字を使用できます。

疑似端末が割り当てられていない場合、セッションは透過的になり、バイナリデータを確実に転送できます。ほとんどのシステムでは、エスケープ文字を「なし」に設定すると、tty が使用されている場合でもセッションが透過的になります。

セッションは、リモートマシンのコマンドまたはシェルが終了し、すべての X11 および TCP 接続が閉じられたときに終了します。

エスケープ文字

疑似端末が要求された場合、ssh はエスケープ文字を使用していくつかの機能を提供します。

チルダ文字を 1 つだけ送信するには、~~ を使用するか、チルダの後に説明されている文字以外の文字を続けます。エスケープ文字は、特殊として解釈されるためには、常に改行の後に続く必要があります。エスケープ文字は、構成ファイルで EscapeChar 構成ディレクティブを使用して、またはコマンドラインで -e オプションを使用して変更できます。

サポートされているエスケープシーケンス (デフォルトの「\~」を想定) は次のとおりです。

~.      切断します。

~^Z     ssh をバックグラウンドで実行します。

~#      転送された接続を一覧表示します。

~&      ログアウト時に、転送された接続または X11 セッションの終了を待機して、ssh をバックグラウンドで実行します。

~?      エスケープ文字のリストを表示します。

~B      リモートシステムに BREAK シグナルを送信します (相手がサポートしている場合にのみ有効です)。

~C      コマンドラインを開きます。これにより、`-L`、`-R`、および `-D` オプションを使用してポートフォワーディングを追加できます (上記を参照)。また、`-KL[bind_address:]port` (ローカル)、`-KR[bind_address:]port` (リモート)、および `-KD[bind_address:]port` (動的) を使用して、既存のポートフォワーディングをキャンセルすることもできます。`!command` を使用すると、`ssh_config(5)` で `PermitLocalCommand` オプションが有効になっている場合に、ローカルコマンドを実行できます。基本的なヘルプは、`-h` オプションを使用して利用できます。

~R      接続のリキーを要求します (相手がサポートしている場合にのみ有効です)。

~V      エラーが stderr に書き込まれるときの詳細度 (LogLevel) を下げます。

~v      エラーが stderr に書き込まれるときの詳細度 (LogLevel) を上げます。

TCP フォワーディング

任意の TCP 接続のフォワーディングは、コマンドラインまたは構成ファイルで指定できます。TCP フォワーディングの 1 つの可能な用途は、メールサーバーへの安全な接続です。もう 1 つは、ファイアウォールを通過することです。

次の例では、IRC サーバーが直接暗号化された通信をサポートしていない場合でも、IRC クライアントの通信を暗号化する方法を示します。これは次のように機能します。ユーザーは ssh を使用してリモートホストに接続し、接続に使用するポートを指定します。その後、ローカルでプログラムを開始すると、ssh は接続を暗号化してリモートサーバーに転送します。

次の例は、「server.example.com」の IRC サーバーに接続し、チャンネル「#users」にニックネーム「pinky」で参加し、標準の IRC ポート 6667 を使用する IRC セッションをクライアントからトンネルします。

$ ssh -f -L 6667:localhost:6667 server.example.com sleep 10
$ irc -c '#users' pinky IRC/127.0.0.1

^ f オプションは ssh をバックグラウンドで実行し、リモートコマンド「sleep 10」は、トンネルを使用するプログラムを開始するのに十分な時間 (例では 10 秒) を与えるために指定されます。指定された時間内に接続が確立されない場合、ssh は終了します。

X11 フォワーディング

^ orwardX11 変数が "yes" に設定されている場合 (または、上記の説明にある -X、-x、および -Y オプションを参照)、ユーザーが X11 を使用している場合 (DISPLAY 環境変数が設定されている)、X11 ディスプレイへの接続が自動的にリモート側にフォワードされ、シェル (またはコマンド) から開始された X11 プログラムは、暗号化されたチャネル経由で実行され、実際の X サーバーへの接続はローカルマシンから行われます。ユーザーは、手動で DISPLAY を設定しないでください。X11 接続のフォワーディングは、コマンドラインまたは設定ファイルで構成できます。

^ sh によって設定される DISPLAY 値は、サーバーマシンを指しますが、表示番号はゼロより大きくなります。これは正常であり、ssh が暗号化されたチャネル経由で接続をフォワードするために、サーバーマシン上に「プロキシ」X サーバーを作成するためです。

^ sh は、サーバーマシンに Xauthority データも自動的に設定します。この目的のために、ランダムな認証クッキーを生成し、サーバー上の Xauthority に保存し、フォワードされた接続がこのクッキーを保持していることを確認し、接続が開かれるときにそれを実際のクッキーに置き換えます。実際の認証クッキーは、サーバーマシンに送信されることはありません (プレーンテキストでクッキーが送信されることもありません)。

^ orwardAgent 変数が "yes" に設定されている場合 (または、上記の説明にある -A および -a オプションを参照)、認証エージェントへの接続が自動的にリモート側にフォワードされます。

ホストキーの検証

サーバーに初めて接続する場合、サーバーの公開キーのフィンガープリントがユーザーに表示されます (ただし、StrictHostKeyChecking オプションが無効になっていない場合)。フィンガープリントは、ssh-keygen(1) を使用して決定できます。

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

フィンガープリントがすでにわかっている場合は、それを照合して、キーを受け入れるか拒否できます。サーバーのレガシー (MD5) フィンガープリントのみが利用可能な場合は、ssh-keygen(1) の -E オプションを使用して、フィンガープリントアルゴリズムをダウングレードして一致させることができます。

ホストキーを単にフィンガープリント文字列を見ることによって比較することが困難であるため、ホストキーを視覚的に比較するためのサポートも提供されています。VisualHostKey オプションを "yes" に設定すると、セッション自体がインタラクティブであるかどうかにかかわらず、各サーバーへのログイン時に小さな ASCII グラフィックが表示されます。既知のサーバーが生成するパターンを学習することで、ユーザーはホストキーが変更されたときに、まったく異なるパターンが表示されるのを見て、簡単にそれを知ることができます。ただし、これらのパターンは必ずしも明確ではないため、記憶しているパターンに似たパターンは、ホストキーが同じである可能性が高いことを示すだけであり、保証されるものではありません。

$ ssh-keygen -lv -f ~/.ssh/known_hosts

既知のホストのフィンガープリントとそれに対応するランダムアートのリストを取得するには、次のコマンドラインを使用できます。

$ ssh-keygen -lv -f ~/.ssh/known_hosts

フィンガープリントが不明な場合は、別の検証方法が利用できます。DNS で検証された SSH フィンガープリントです。追加のリソースレコード (RR)、SSHFP がゾーンファイルに追加され、接続するクライアントは、提示されたキーのフィンガープリントを照合できます。

この例では、クライアントをサーバー "host.example.com" に接続します。まず、host.example.com のゾーンファイルに SSHFP リソースレコードを追加する必要があります。

$ ssh-keygen -r host.example.com.

出力行をゾーンファイルに追加する必要があります。ゾーンがフィンガープリントクエリに応答していることを確認するには、次を使用します。

$ dig -t SSHFP host.example.com

最後に、クライアントを接続します。

$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]

DNS でホストキーのフィンガープリントが一致しました。 接続を続行しますか？ (yes/no)

詳細については、ssh_config(5) の VerifyHostKeyDNS オプションを参照してください。

SSH ベースの仮想プライベートネットワーク

ssh には、tun(4) ネットワークデバイスを使用して、2 つのネットワークを安全に結合する仮想プライベートネットワーク (VPN) トンネルをサポートする機能が含まれています。shd_config(5) の構成オプション PermitTunnel は、サーバーがこれをサポートするかどうか、およびどのレベル (レイヤー 2 またはレイヤー 3 トラフィック) でサポートするかを制御します。

次の例では、クライアントネットワーク 10.0.50.0/24 を、ポイントツーポイント接続 10.1.1.1 から 10.1.1.2 を使用して、リモートネットワーク 10.0.99.0/24 に接続します。これは、リモートネットワークへのゲートウェイで実行されている SSH サーバーが、アドレス 192.168.1.15 でこれを許可する場合にのみ可能です。

クライアント側：

# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2

サーバー側：

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1

/root/.ssh/authorized_keys ファイル (以下を参照) と、サーバーオプション PermitRootLogin を使用して、クライアントアクセスをより細かく調整できます。次のエントリは、PermitRootLogin が "forced-commands-only" に設定されている場合、tun(4) デバイス 1 からユーザー "jane"、および tun デバイス 2 からユーザー "john" での接続を許可します。

tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

SSH ベースのセットアップにはかなりのオーバーヘッドがかかるため、ワイヤレス VPN などの一時的なセットアップに適している場合があります。より永続的な VPN は、ipsecctl(8) や isakmpd(8) などのツールでより適切に提供できます。

環境

ssh は通常、次の環境変数を設定します。

DISPLAY DISPLAY 変数は、X11 サーバーの場所を示します。ssh は、"hostname:n" という形式の値になるように自動的に設定します。ここで "hostname" はシェルが実行されているホストを示し、'n' は 1 以上の整数です。
ssh は、この特別な値をセキュリティで保護されたチャネルを介して X11 接続を転送するために使用します。通常、ユーザーは DISPLAY を明示的に設定しないでください。そうすると、X11 接続が安全ではなくなり (ユーザーが手動で必要な承認クッキーをコピーする必要があるため) ます。

HOME        ユーザーのホームディレクトリのパスに設定されます。

LOGNAME     USERの同義語。この変数を使用するシステムとの互換性のために設定されます。

MAIL        ユーザーのメールボックスのパスに設定されます。

PATH        sshのコンパイル時に指定されたデフォルトのPATHに設定されます。

SSH_ASKPASS     sshがパスフレーズを必要とする場合、現在のターミナルからパスフレーズを読み取ります（ターミナルから実行された場合）。sshにターミナルが関連付けられておらず、DISPLAYとSSH_ASKPASSが設定されている場合、SSH_ASKPASSで指定されたプログラムを実行し、パスフレーズを読み取るためにX11ウィンドウを開きます。これは、.xsessionまたは関連するスクリプトからsshを呼び出す場合に特に役立ちます。（一部のシステムでは、/dev/nullから入力をリダイレクトして、これを機能させる必要がある場合があります。）

SSH_ASKPASS_REQUIRE     askpassプログラムの使用をさらに制御します。この変数が「never」に設定されている場合、sshはaskpassプログラムを使用しません。 「prefer」に設定されている場合、sshはTTYではなく、askpassプログラムを使用することを優先します。最後に、変数が「force」に設定されている場合、DISPLAYが設定されているかどうかに関係なく、askpassプログラムがすべてのパスフレーズ入力に使用されます。

SSH_AUTH_SOCK       エージェントとの通信に使用されるUnixドメインソケットのパスを識別します。

SSH_CONNECTION      クライアントとサーバーの接続の両端を識別します。この変数には、4つのスペースで区切られた値が含まれます。クライアントのIPアドレス、クライアントのポート番号、サーバーのIPアドレス、サーバーのポート番号です。

SSH_ORIGINAL_COMMAND        強制コマンドが実行された場合に、元のコマンドラインが含まれます。これを使用して、元の引数を抽出できます。

SSH_TTY     現在のシェルまたはコマンドに関連付けられているtty（デバイスへのパス）の名前です。現在のセッションにttyがない場合、この変数は設定されません。

SSH_TUNNEL      クライアントによってトンネルフォワーディングが要求された場合、[sshd]({filename}../../sshd)(8)によってオプションで設定され、割り当てられたインターフェイス名が含まれます。

SSH_USER_AUTH       [sshd]({filename}../../sshd)(8)によってオプションで設定され、セッションが確立されたときに正常に使用された認証方法のリスト（使用された公開キーを含む）を含むファイルへのパスが含まれる場合があります。

TZ      デーモンが起動されたときにタイムゾーンが設定されている場合、この変数は現在のタイムゾーンを示すように設定されます（つまり、デーモンはその値を新しい接続に渡します）。

USER        ログインしているユーザーの名前に設定されます。

さらに、sshは~/.ssh/environmentを読み取り、ファイルが存在し、ユーザーが環境を変更することを許可している場合、VARNAME=valueの形式の行を環境に追加します。詳細については、sshd_config(5)のPermitUserEnvironmentオプションを参照してください。

ファイル

~/.rhosts
このファイルは、ホストベース認証に使用されます（上記参照）。一部のシステムでは、ユーザーのホームディレクトリがNFSパーティションにある場合、[sshd]({filename}../../sshd)(8)がrootとして読み取るため、このファイルが世界中で読み取り可能である必要があります。さらに、このファイルはユーザーが所有し、他の誰にも書き込み権限を与えてはなりません。ほとんどのシステムで推奨される権限は、ユーザーに対して読み取り/書き込み権限を与え、他のユーザーにはアクセスを許可しないことです。

~/.shosts
このファイルは`.rhosts`と同じように使用されますが、`rlogin`/`rsh`によるログインを許可せずに、ホストベース認証を可能にします。

~/.ssh/
このディレクトリは、すべてのユーザー固有の構成と認証情報のデフォルトの場所です。このディレクトリ全体のコンテンツを秘密にしておく一般的な要件はありませんが、推奨される権限は、ユーザーに対して読み取り/書き込み/実行権限を与え、他のユーザーにはアクセスを許可しないことです。

~/.ssh/authorized_keys
このファイルには、このユーザーとしてログインするために使用できる公開鍵（ECDSA、Ed25519、RSA）がリストされています。このファイルの形式は、[sshd]({filename}../../sshd)(8)のマニュアルページで説明されています。このファイルは機密性が高いわけではありませんが、推奨される権限は、ユーザーに対して読み取り/書き込み権限を与え、他のユーザーにはアクセスを許可しないことです。

~/.ssh/config
これは、ユーザーごとの設定ファイルです。ファイル形式と設定オプションは、ssh_config(5)で説明されています。悪用の可能性があるため、このファイルは厳密な権限を持つ必要があります。ユーザーに対して読み取り/書き込み権限を与え、他のユーザーには書き込み権限を与えないでください。このファイルがグループ書き込み可能であっても、そのグループにはユーザーのみが含まれている必要があります。

~/.ssh/environment
環境変数の追加の定義が含まれています。上記「ENVIRONMENT」を参照してください。

~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
これらのファイルには、認証に使用する秘密鍵が含まれています。これらのファイルには機密データが含まれているため、ユーザーが読み取り可能で、他のユーザーがアクセスできないようにする必要があります（読み取り/書き込み/実行権限）。sshは、秘密鍵ファイルが他のユーザーがアクセス可能な場合、単にそれを無視します。秘密鍵を生成するときにパスフレーズを指定すると、そのパスフレーズを使用して、このファイルの機密部分をAES-128で暗号化できます。

~/.ssh/id_ecdsa.pub
~/.ssh/id_ecdsa_sk.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_ed25519_sk.pub
~/.ssh/id_rsa.pub
これらのファイルには、認証に使用する公開鍵が含まれています。これらのファイルは機密ではありません（ただし、必ずしもすべてのユーザーが読み取り可能である必要はありません）。

~/.ssh/known_hosts
このファイルには、ユーザーがログインしたすべてのホストのホストキーのリストが格納されています。ただし、システム全体の既知のホストキーのリストにすでに含まれているホストは除きます。詳細については、[sshd]({filename}../../sshd)(8)のマニュアルページを参照してください。

~/.ssh/rc
このファイル内のコマンドは、ユーザーがログインするときにsshによって実行されます。ユーザーのシェル（またはコマンド）が開始される直前です。詳細については、[sshd]({filename}../../sshd)(8)のマニュアルページを参照してください。

/etc/hosts.equiv

このファイルはホストベース認証用です（上記を参照）。rootのみが書き込み可能である必要があります。

/etc/ssh/shosts.equiv

このファイルは hosts.equiv とまったく同じように使用されますが、rlogin/rsh を使用したログインを許可せずにホストベース認証を可能にします。

/etc/ssh/ssh_config

システム全体の構成ファイルです。ファイル形式と構成オプションについては、ssh_config(5) を参照してください。

/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key

これらのファイルには、ホストキーのプライベート部分が含まれており、ホストベース認証に使用されます。

/etc/ssh/ssh_known_hosts

システム全体の既知のホストキーのリストです。このファイルは、システム管理者が組織内のすべてのマシンの公開ホストキーを含むように準備する必要があります。これは、世界中で読み取り可能である必要があります。詳細については、sshd(8) のマニュアルページを参照してください。

/etc/ssh/sshrc

このファイル内のコマンドは、ユーザーがログインしたときに ssh によって実行され、ユーザーのシェル（またはコマンド）が開始される直前です。詳細については、sshd(8) のマニュアルページを参照してください。

終了ステータス

ssh は、リモートコマンドの終了ステータス、またはエラーが発生した場合は 255 で終了します。

関連項目

scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-argv0(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)

標準

S. Lehtinen と C. Lonvick、「The Secure Shell (SSH) Protocol Assigned Numbers」、RFC 4250、200 年 1 月。

T. Ylonen と C. Lonvick、「The Secure Shell (SSH) Protocol Architecture」、RFC 4251、2006 年 1 月。

T. Ylonen と C. Lonvick、「The Secure Shell (SSH) Authentication Protocol」、RFC 4252、2006 年 1 月。

T. Ylonen と C. Lonvick、「The Secure Shell (SSH) Transport Layer Protocol」、RFC 4253、2006 年 1 月。

T. Ylonen と C. Lonvick、「The Secure Shell (SSH) Connection Protocol」、RFC 4254、2006 年 1 月。

J. Schlyter と W. Griffin、「Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints」、RFC 4255、2006 年 1 月。

F. Cusack と M. Forssen、「Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)」、RFC 4256、2006 年 1 月。

J. Galbraith と P. Remaker、「The Secure Shell (SSH) Session Channel Break Extension」、RFC 4335、2006 年 1 月。

M. Bellare、T. Kohno、C. Namprempre、「The Secure Shell (SSH) Transport Layer Encryption Modes」、RFC 4344、2006 年 1 月。

B. Harris、「Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol」、RFC 4345、2006 年 1 月。

M. Friedl、N. Provos、W. Simpson、「Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol」、RFC 4419、2006 年 3 月。

J. Galbraith と R. Thayer、「The Secure Shell (SSH) Public Key File Format」、RFC 4716、2007 年 11 月。

D. Stebila と J. Green、「Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer」、RFC 5656、2009 年 12 月。

A. Perrig と D. Song, Hash Visualization: セキュリティを向上させるための新しい技術、1999年、

国際暗号技術および電子商取引ワークショップ（CrypTEC '99）。

著者

OpenSSH は、Tatu Ylonen によるオリジナルの無料の ssh 1.2.12 リリースの派生です。Aaron Campbell、Bob Beck、Markus Friedl、Niels Provos、Theo de Raadt、Dug Song は、多くのバグを修正し、より新しい機能を再追加し、OpenSSH を作成しました。Markus Friedl は、SSH プロトコルバージョン 1.5 および 2.0 のサポートに貢献しました。