NAME

     ssh — OpenSSH SSH 客戶端 (遠程登錄程序)

總覽 (SYNOPSIS)

     ssh [-l login_name] hostname | user@hostname [command]

     ssh [-afgknqstvxACNTX1246] [-b bind_address] [-c cipher_spec] [-e escape_char]
     [-i identity_file] [-l login_name] [-m mac_spec] [-o option] [-p port] [-F configfile]
     [-L port:host:hostport] [-R port:host:hostport] [-D port] hostname | user@hostname [command]

描述 (DESCRIPTION)

     ssh (SSH 客戶端) 用於登錄遠程主機, 並且在遠程主機上執行命令.  它的目的是替換 rlogin 和 rsh,
     同時在不安全的網絡之上, 兩個互不 信任的主機之間, 提供加密的, 安全的通信連接.  X11 連接和任意
     TCP/IP 端口均可以通過此安全通道轉發(forward).

     當用戶通過 ssh 連接並登錄主機 hostname 後, 根據所用的協議版本, 用戶必須通過下述方法之一向遠
     程主機證明他/她的身份:

   SSH 協議第一版
     第一, 如果發出登錄命令的本地主機已經列在遠程主機的 /etc/hosts.equiv 或 /etc/ssh/shosts.equiv
     文件中, 並且兩端的用戶名相同, 則立即允許該用戶登錄.  第二, 如果遠程主機的用戶根目錄 (home 目
     錄) 下存在 .rhosts 或 .shosts, 並且其中有一行包含了客戶機的名字和客戶機上的用戶名, 則允許該
     用戶登錄.  一般來說, 服務器不允許單獨使用這種認證方式, 因爲它不安全.

     第二種認證方法是 rhosts 或 hosts.equiv 文件結合基於 RSA 的主機認證. 這意味着如果
     $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, 或 /etc/ssh/shosts.equiv 允許登錄, 並且如果
     服務器能夠驗證客戶的主機密鑰(host key) (參見 文件(FILE) 節的 /etc/ssh/ssh_known_hosts 和
     $HOME/.ssh/known_hosts ), 主機才允許客戶登錄.  這個認證方法關閉了因 IP 欺騙, DNS 欺騙和路由
     欺騙造成的安全漏洞.  [系統管理員注意: 一般說來 /etc/hosts.equiv, $HOME/.rhosts, 和
     rlogin/rsh 協議的本質是不可靠地, 要安全就應該關掉它們.]

     作爲第三種認證方式, ssh 支持基於 RSA 的認證.  這種方案依託於公開密鑰算法: 密碼系統的加密和解
     密通過不同的密鑰完成, 無法 通過加密密鑰推導出解密密鑰. RSA 就是這種密碼系統.  每個用戶創建一
     對公開/私密鑰匙用於認證.  服務器知道用戶的公鑰, 只有用戶知道他自己的私鑰.
     $HOME/.ssh/authorized_keys 文件列出允許登錄的(用戶的)公鑰. 當用戶開始登錄, ssh 程序告訴服務
     器它準備使用哪對鑰匙(公鑰)做認證.  服務器檢查這隻密鑰(公鑰)是否獲得許可, 如果許可, 服務器向
     用戶 (實際上是用戶面前運行的 ssh 程序) 發出測試, 用用戶的公鑰加密一個隨機數. 這個隨機數只能
     用正確的私鑰解密.  隨後用戶的客戶程序用私鑰解出測試數字, 即可證明他/她掌握私鑰, 而又無需(把
     私鑰)暴露給服務器.

     ssh 能夠自動執行 RSA 認證協議. 用戶通過運行 ssh-keygen(1) 創建他/她的 RSA 密鑰對. 私鑰存放在
     用戶根目錄下的 $HOME/.ssh/identity 中, 而公鑰存放在 $HOME/.ssh/identity.pub 中. 隨後, 用戶應
     該把 identity.pub 複製到遠程服務器中, 作爲 $HOME/.ssh/authorized_keys 存放到他/她的用戶根目
     錄下 ( authorized_keys 對應傳統的 $HOME/.rhosts 文件, 每一行只有一隻密鑰, 儘管一行可以很長).
     用戶無須密碼就可以直接登錄. RSA 認證遠比 rhosts 認證安全.

     RAS 認證最便捷的用法大概就是使用認證代理(authentication agent) 了. 詳見 ssh-agent(1) 手冊頁.

     如果這些認證方式都失敗了, ssh 就提示用戶輸入口令(password), 然後把口令送到服務器做驗證. 由於
     整個通信過程是 加密的, 因此別人不可能通過偵聽網絡獲得這個口令.

   SSH 協議第二版
     當用戶以協議第二版連接時, 類似的認證方法一樣有效. 如果使用了 PreferredAuthentications 的默認
     內容, 客戶端首先試着用基於主機的認證方法進行連接; 如果這個方法失敗了 就用公開密鑰方法作認證;
     最後, 如果它也失敗了, 就進入鍵盤操作, 試試 用戶口令認證.

     這個公開密鑰方法類似於上一節描述的 RAS 認證, 並且允許使用 RAS 或 DSA 算法: 客戶端用他的私鑰
     ( $HOME/.ssh/id_dsa 或 $HOME/.ssh/id_rsa ) 對會話標識符(session identifier)簽名, 然後把結果
     送到服務器.  服務器檢查 $HOME/.ssh/authorized_keys 中是否有匹配的公鑰, 如果密鑰和簽名都正確,
     訪問就可以繼續進行.  會話標識符來自共享的 Diffie-Hellman 值, 只有客戶端和服務器端才知道這個
     值.

     如果公鑰認證失敗或無效, 用戶口令將會加密後送到遠端主機來證明用戶的身份.

     另外, ssh 支持基於主機或測試應答的認證方式.

     協議第二版提供附加機制增強保密性 (數據流用 3DES, Blowfish, CAST128 或 Arcfour 加密) 和完整性
     (hmac-md5, hmac-sha1).  注意, 協議第一版缺少強有力的機制確保連接的完整性.

   登錄會話和遠程執行
     服務器接受用戶身份後, 服務器即可以執行給定的命令, 也可以讓用戶登錄並給他 一個正常的 shell.
     所有和遠端命令或 shell 的通信被自動加密.

     如果分配了僞終端(pseudo-terminal)(普通的登錄會話), 用戶可以使用後面將 提到的 escape 字符.

     如果沒有分配僞終端, 則會話是透明的(transparent), 能夠可靠的傳送二進制數據.  大多數系統上, 即
     使分配了終端, 把 escape 字符設爲 “none” 也可以讓會話透明.

     當遠程主機上的命令或 shell 退出時, 會話即結束, 並關閉所有 X11 和 TCP/IP 連接.  遠端程序的返
     回碼做爲 ssh 的返回碼返回.

   Escape 字符
     如果啓用了僞終端, ssh 能夠通過 escape 字符支持一組功能.

     單獨的波浪符可以用 ~~ 送出去, 只要後面不跟下面列舉的字符, 也可以把它直接送出去.  escape 字符
     必須接在換行(newline)後面, 這樣才具有特別含義.  在配置文件中可以用 EscapeChar 命令更改
     escape 字符, 在命令行上可以用 -e 選項更改.

     已支持的 escape 命令 (假設是默認的 ‘~’) 有:

     ~.      斷開連接

     ~^Z     把 ssh 送到後臺

     ~#      列出轉發的連接 (forwarded connection)

     ~&      當等待轉發的連接/X11會話結束時, ssh 在後臺退出登錄

     ~?      顯示 escape 字符的列表

     ~C      打開命令行 (僅用於 -L 和 -R 選項增加端口轉發)

     ~R      請求連接的重建(rekeying) (僅用於SSH協議第二版, 且對方支持)

   X11 和 TCP 轉發 (forwarding)
     如果 ForwardX11 變量設爲 “yes” (或參見後面對 -X 和 -x 選項的描述), 並且用戶正在使用 X11 (設
     置了 DISPLAY 環境變量), 和 X11 顯示器的連接將自動以這種形式轉發到遠端: 任何用 shell 或命令啓
     動的 X11 程序將穿過加密的通道, 從本地機器連接真正的 X 服務器. 用戶不應該手動設置 DISPLAY.
     可以在命令行上, 也可以在配置文件中設置 X11 連接的轉發.

     ssh 設置的 DISPLAY 值將指向服務器, 但是顯示器號大於零. 這很自然, 因爲 ssh 在服務器上創建了一
     個 “proxy” X 服務器, 把連接通過加密通道轉發出去.

     ssh 將自動在服務器上設置 Xauthority 數據. 目的是這樣的: SSH 生成一個隨機的授權 cookie, 存放
     在服務器的 Xauthority 中.  SSH 檢查並確保轉發的連接攜帶了這個 cookie, 打開連接後, 把它替換爲
     真正的 cookie.  真正的認證 cookie 絕不會送往服務器 (也不會有任何明文傳送的 cookie).

     如果 ForwardAgent 變量設爲 “yes” (或參見後面對 -A 和 -a 選項的描述), 並且用戶正在使用認證代
     理(authentication agent), 則和代理的連接將自動轉發到遠程主機.

     既可以在命令行上, 也可以在配置文件中指定通過加密通道轉發的任何 TCP/IP 連接.  TCP/IP 轉向的應
     用有, 比如說, 和電子錢包的安全連接, 或者是穿過防火牆等.

   服務器認證
     ssh 自動維護並檢查一個身份數據庫, 它包含所有(成功)來訪的主機的身份數據.  主機密鑰存放在用戶
     根目錄下的 $HOME/.ssh/known_hosts 文件中. 另外, SSH 自動檢查 /etc/ssh/ssh_known_hosts 裏面已
     知的主機. 任何新主機將被自動添加到用戶文件中.  如果某個主機的身份發生改變, ssh 就會發出警告,
     並且關閉對它的密碼認證, 以防止特洛伊木馬竊取用戶密碼.  這個機制的另一個目的是防止中間人攻擊,
     否則這種攻擊可能會繞過加密系統.  StrictHostKeyChecking 選項用來防止登錄到主機密鑰不能識別或
     發生改變的那些機器.

     命令行選項有:

     -a      禁止轉發認證代理的連接.

     -A      允許轉發認證代理的連接.  可以在配置文件中對每個主機單獨設定這個參數.

             代理轉發須謹慎.  某些用戶能夠在遠程主機上繞過文件訪問權限 (由於代理的 UNIX 域
             socket), 他們可以通過轉發的連接訪問本地代理.  攻擊者不可能從代理獲得密鑰內容, 但是他
             們能夠操作這些密鑰, 利用加載到代理上 的身份信息通過認證.

     -b bind_address
             在擁有多個接口或地址別名的機器上, 指定收發接口.

     -c blowfish|3des|des
             選擇加密會話的密碼術.  3des 是默認算法.  3des (triple-des) 用三支不同的密鑰做加密-解
             密-加密三次運算, 被認爲比較可靠.  blowfish 是一種快速的分組加密術(block cipher), 非
             常安全, 而且速度比 3des 快的多.  des 僅支持 ssh 客戶端, 目的是能夠和老式的不支持
             3des 的協議第一版互操作. 由於其密碼算法上的弱點, 強烈建議避免使用.

     -c cipher_spec
             另外, 對於協議第二版, 這裏可以指定一組用逗號隔開, 按優先順序排列的密碼術.  詳見
             Ciphers.

     -e ch|^ch|none
             設置 pty 會話的 escape 字符 (默認字符: ‘~’).  escape 字符只在行首有效, escape 字符後
             面跟一個點 (‘.’) 表示結束連接, 跟一個 control-Z 表示掛起連接(suspend), 跟 escape 字
             符自己 表示輸出這個字符. 把這個字符設爲 “none” 則禁止 escape 功能, 使會話完全透明.

     -f      要求 ssh 在執行命令前退至後臺. 它用於當 ssh 準備詢問口令或密語, 但是用戶希望它在後臺
             進行. 該選項隱含了 -n 選項. 在遠端機器上啓動 X11 程序的推薦手法就是類似於 ssh -f
             host xterm 的命令.

     -g      允許遠端主機連接本地轉發的端口.

     -i identity_file
             指定一個 RSA 或 DSA 認證所需的身份(私鑰)文件. 默認文件是協議第一版的
             $HOME/.ssh/identity 以及協議第二版的 $HOME/.ssh/id_rsa 和 $HOME/.ssh/id_dsa 文件. 也
             可以在配置文件中對每個主機單獨指定身份文件.  可以同時使用多個 -i 選項 (也可以在配置
             文件中指定多個身份文件).

     -I smartcard_device
             指定智能卡(smartcard)設備. 參數是設備文件, ssh 能夠用它和智能卡通信, 智能卡里面存儲
             了用戶的 RSA 私鑰.

     -k      禁止轉發 Kerberos 門票和 AFS 令牌.  可以在配置文件中對每個主機單獨設定這個參數.

     -l login_name
             指定登錄遠程主機的用戶.  可以在配置文件中對每個主機單獨設定這個參數.

     -m mac_spec
             另外, 對於協議第二版, 這裏可以指定一組用逗號隔開, 按優先順序排列的 MAC(消息驗證碼)算
             法 (message authentication code). 詳情以 MACs 爲關鍵字查詢.

     -n      把 stdin 重定向到 /dev/null (實際上防止從 stdin 讀取數據).  ssh 在後臺運行時一定會用
             到這個選項. 它的常用技巧是遠程運行 X11 程序. 例如, ssh -n shadows.cs.hut.fi emacs &
             將會在 shadows.cs.hut.fi 上啓動 emacs, 同時自動在加密通道中轉發 X11 連接.  ssh 在後
             臺運行. (但是如果 ssh 要求口令或密語, 這種方式就無法工作; 參見 -f 選項.)

     -N      不執行遠程命令. 用於轉發端口. (僅限協議第二版)

     -o option
             可以在這裏給出某些選項, 格式和配置文件中的格式一樣.  它用來設置那些沒有命令行開關的
             選項.

     -p port
             指定遠程主機的端口. 可以在配置文件中對每個主機單獨設定這個參數.

     -q      安靜模式. 消除所有的警告和診斷信息.

     -s      請求遠程系統激活一個子系統. 子系統是 SSH2 協議的一個特性, 能夠協助 其他應用程序(如
             sftp)把SSH用做安全通路. 子系統通過遠程命令指定.

     -t      強制分配僞終端.  可以在遠程機器上執行任何全屏幕(screen-based)程序, 所以非常有用, 例
             如菜單服務. 並聯的 -t 選項強制分配終端, 即使 ssh 沒有本地終端.

     -T      禁止分配僞終端.

     -v      冗詳模式. 使 ssh 打印關於運行情況的調試信息. 在調試連接, 認證和配置問題時非常有用.
             並聯的 -v 選項能夠增加冗詳程度. 最多爲三個.

     -x      禁止 X11 轉發.

     -X      允許 X11 轉發. 可以在配置文件中對每個主機單獨設定這個參數.

             應該謹慎使用 X11 轉發. 如果用戶在遠程主機上能夠繞過文件訪問權限 (根據用戶的X授權數據
             庫), 他就可以通過轉發的連接訪問本地 X11 顯示器.  攻擊者可以據此採取行動, 如監視鍵盤
             輸入等.

     -C      要求進行數據壓縮 (包括 stdin, stdout, stderr 以及轉發 X11 和 TCP/IP 連接 的數據).
             壓縮算法和 gzip(1) 的一樣, 協議第一版中, 壓縮級別 “level” 用 CompressionLevel 選項控
             制. 壓縮技術在 modem 線路或其他慢速連接上很有用, 但是在高速網絡上反而 可能降低速度.
             可以在配置文件中對每個主機單獨設定這個參數. 另見 Compression 選項.

     -F configfile
             指定一個用戶級配置文件. 如果在命令行上指定了配置文件, 系統級配置文件
             (/etc/ssh/ssh_config) 將被忽略. 默認的用戶級配置文件是 $HOME/.ssh/config.

     -L port:host:hostport
             將本地機(客戶機)的某個端口轉發到遠端指定機器的指定端口.  工作原理是這樣的, 本地機器
             上分配了一個 socket 偵聽 port 端口, 一旦這個端口上有了連接, 該連接就經過安全通道轉發
             出去, 同時遠程主機和 host 的 hostport 端口建立連接. 可以在配置文件中指定端口的轉發.
             只有 root 才能轉發特權端口.  IPv6 地址用另一種格式說明: port/host/hostport

     -R port:host:hostport
             將遠程主機(服務器)的某個端口轉發到本地端指定機器的指定端口.  工作原理是這樣的, 遠程
             主機上分配了一個 socket 偵聽 port 端口, 一旦這個端口上有了連接, 該連接就經過安全通道
             轉向出去, 同時本地主機和 host 的 hostport 端口建立連接. 可以在配置文件中指定端口的轉
             發. 只有用 root 登錄遠程主機 才能轉發特權端口. IPv6 地址用另一種格式說明:
             port/host/hostport

     -D port
             指定一個本地機器 “動態的” 應用程序端口轉發. 工作原理是這樣的, 本地機器上分配了一個
             socket 偵聽 port 端口, 一旦這個端口上有了連接, 該連接就經過安全通道轉發出去, 根據應
             用程序的協議可以判斷出遠程主機將和哪裏連接. 目前支持 SOCKS4 協議, ssh 將充當 SOCKS4
             服務器. 只有 root 才能轉發特權端口.  可以在配置文件中指定動態端口的轉發.

     -1      強制 ssh 只使用協議第一版.

     -2      強制 ssh 只使用協議第二版.

     -4      強制 ssh 只使用 IPv4 地址.

     -6      強制 ssh 只使用 IPv6 地址.

配置文件 (CONFIGURATION FILES)

     ssh 可以從用戶級配置文件和系統級配置文件中獲取更多的配置數據.  配置文件的格式及其內容參見
     ssh_config(5).

環境變量 (ENVIRONMENT)

     ssh 一般將設置下面的環境變量:

     DISPLAY
             環境變量 DISPLAY 指出 X11 服務器的位置.  ssh 自動設置這個變量, 變量指向 “hostname:n”
             格式的數據, 其中 hostname 指出運行 shell 的主機, 而 n 是大於等於 1 的整數.  ssh 根據
             這個數據, 用安全通路轉發 X11 連接. 用戶一般不需要主動設置 DISPLAY 變量, 否則會導致
             X11 連接不安全 (而且會導致用戶手工複製所需的授權 cookie).

     HOME    設置爲用戶根目錄的路徑.

     LOGNAME
             等於 USER; 用來兼容使用這個變量的系統.

     MAIL    設置爲用戶郵箱的路徑.

     PATH    設置爲默認的 PATH, 如同編譯 ssh 時要求的一樣.

     SSH_ASKPASS
             如果 ssh 需要一個密語(passphrase), 只要它是終端上啓動的, 它會從當前終端上讀取. 如果
             ssh 沒有聯接終端, 但是設置了 DISPLAY 和 SSH_ASKPASS 變量, ssh 就運行 SSH_ASKPASS 指
             定的程序, 打開一個 X11 窗口讀取密語. 當從 .Xsession 或類似的 script 中調用 ssh 時,
             這個功能特別有用. (注意, 某些機器上可能需要將輸入重定向爲 /dev/null 才能工作.)

     SSH_AUTH_SOCK
             標識某個 UNIX 域 socket 的路徑, 用於和代理通信.

     SSH_CONNECTION
             標識連接的客戶端和服務器端. 變量包含四個用空格隔開的字段: 客戶端IP地址, 客戶端端口
             號, 服務器IP地址, 服務器端口號.

     SSH_ORIGINAL_COMMAND
             如果強制執行了某條命令, 該變量就保存了最初的命令行. 可以用它獲取初始參數.

     SSH_TTY
             設置爲關聯當前 shell 或命令的終端名字(設備的路徑).  如果會話沒有終端, 就不設置這個變
             量.

     TZ      如果啓動後臺進程(daemon)時設置了時區, 就設置這個時區變量, 指出現在的時區 (就是說, 後
             臺進程會把這個變量傳給新建連接).

     USER    設置爲登錄的用戶名.

     另外, 如果允許用戶改變他們的環境數據, 而且有 $HOME/.ssh/environment 這個文件, ssh 將讀取其中
     數據, 把 “VARNAME=value” 這種格式的數據行添加進環境數據區. 另見 sshd_config(5) 的
     PermitUserEnvironment 選項.

文件 (FILES)

     $HOME/.ssh/known_hosts
             主機密鑰的記錄, 記錄有用戶登錄上來, 但是沒有列在 /etc/ssh/ssh_known_hosts 中的主機.
             參見 sshd(8).

     $HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa
             包含了用戶的身份信息. 它們分別是協議第一版的 RSA, 協議第二版的 DSA, 協議第二版的
             RSA. 這些文件存有敏感信息, 只應由該用戶讀取, 不允許其他用戶 訪問(讀/寫/執行). 注意,
             如果一個私鑰文件能夠讓其他用戶訪問, ssh 將忽略這個文件. 在生成密鑰的時候可以指定一個
             密語(passphrase), 用這個密語和 3DES 加密文件的敏感部分.

     $HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub
             包含認證用的公鑰 (以文本格式保存的身份文件的公開部分).  如果用戶希望用協議第一版的
             RSA 認證登錄這些機器, $HOME/.ssh/identity.pub 的內容應該添加到所有機器的
             $HOME/.ssh/authorized_keys 中. 如果用戶希望用協議第二版的 DSA/RSA 認證登錄這些機器,
             $HOME/.ssh/id_dsa.pub 和 $HOME/.ssh/id_rsa.pub 的內容應該添加到所有機器的
             $HOME/.ssh/authorized_keys 中. 這些文件沒有敏感數據, 可以(但不是必須)讓任何人讀取.
             ssh 絕不會自動訪問這些文件, 它們也不是不可或缺; 只是爲了用戶方便才提供這些文件.

     $HOME/.ssh/config
             用戶級配置文件.  ssh_config(5) 描述了文件格式及其配置選項.

     $HOME/.ssh/authorized_keys
             存放 RSA/DSA 公鑰, 用戶通過它登錄機器.  sshd(8) 手冊頁描述了這個文件的格式. 最簡單的
             文件格式和 .pub 身份文件一樣.  文件內容並非高度敏感, 但是仍然建議僅讓此文件的用戶讀
             寫, 而拒絕其他用戶的訪問.

     /etc/ssh/ssh_known_hosts
             已知的主機密鑰的系統級列表. 系統管理員應該準備好這個文件, 把所需主機的公鑰 保存在文
             件裏面. 這個文件應該能夠全局讀取. 文件中一行一支公鑰, 格式是 (字段用空格隔開): 系統
             名字, 公鑰, 可選的註釋域. 如果同一個機器使用了多個名字, 所有名字都應該(用逗號隔開)列
             出來. 文件格式在 sshd(8) 手冊頁中有描述.

             登錄的時候, sshd(8) 用規範的系統名字(名字服務器返回的)確認客戶機; 其他名字也需要, 因
             爲校驗密鑰前 ssh 不會把用戶提供的名字轉換爲規範名字, 防止能夠操作名字服務器的人欺騙
             主機認證.

     /etc/ssh/ssh_config
             系統級配置文件.  ssh_config(5) 描述了文件格式和配置選項.

     /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key
             這三個文件包含了主機密鑰的私有部分, 它們用於 RhostsRSAAuthentication 和
             HostbasedAuthentication.  如果使用了協議第一版的 RhostsRSAAuthentication 方法, ssh
             必須是 setuid root, 因爲只有 root 才能讀取主機密鑰. 而對於協議第二版的
             HostbasedAuthentication 方法, ssh 使用 ssh-keysign(8) 訪問主機密鑰. 這樣消除了驗證身
             份時對 ssh setuid root 的要求. 默認情況下 ssh 不是 setuid root.

     $HOME/.rhosts
             該文件用於 .rhosts 認證, 裏面列出允許登錄的主機/用戶對.  (注意 rlogin 和 rsh 也使用
             這個文件, 導致這個文件的應用變得不安全) 文件中的每一行包括一個主機名字(用名字服務器
             返回的規範名字), 和主機上的 用戶名字, 用空格隔開. 某些機器上, 如果用戶根目錄位於 NFS
             分區, 這個文件可能需要全局可讀, 因爲 sshd(8) 以 root 身份讀它. 此外, 該文件必須屬於
             這個用戶, 其他人不允許持有寫權限.  對大多數機器推薦的訪問權限是, 它的用戶可以讀寫,
             而不讓其他人訪問.

             注意, 默認情況下會安裝 sshd(8) , 因此在允許 .rhosts 認證前, sshd(8) 要求成功進行了
             RSA 主機驗證. 如果沒有 /etc/ssh/ssh_known_hosts 文件存放客戶的主機密鑰, 密鑰可以存放
             在 $HOME/.ssh/known_hosts 中. 最簡單的做法是用 ssh 從服務器回連客戶機; 這樣會自動把
             主機密鑰添加到 $HOME/.ssh/known_hosts.

     $HOME/.shosts
             這個文件的用法和 .rhosts 完全一樣. 它的目的是允許 ssh 做 rhosts 認證的同時防止
             rlogin 或 rsh(1) 登錄.

     /etc/hosts.equiv
             .rhosts 認證 使用這個文件. 它包含規範的主機名字, 一行一個( sshd(8) 手冊頁描述了完整
             的格式). 如果文件中發現了客戶機的名字, 而且客戶機和服務器的用戶名相同, 則自動允許登
             錄.  另外, 一般情況下要求 RSA 主機認證成功. 這個文件只應該讓 root 可寫.

     /etc/ssh/shosts.equiv
             這個文件的用法和 /etc/hosts.equiv 完全一樣. 用於允許 ssh 登錄, 但不允許 rsh/rlogin
             的時候.

     /etc/ssh/sshrc
             當用戶登錄後, 運行 shell (或命令)前, ssh 執行這個文件中的命令. 詳見 sshd(8) 手冊頁.

     $HOME/.ssh/rc
             當用戶登錄後, 運行 shell (或命令)前, ssh 執行這個文件中的命令. 詳見 sshd(8) 手冊頁.

     $HOME/.ssh/environment
             含有關於環境變量的附加定義, 另見前面的 ENVIRONMENT 節.

診斷 (DIAGNOSTICS)

     ssh 結束時的狀態碼就是遠端命令結束時的返回碼, 如果發生了錯誤就返回255.

作者 (AUTHORS)

     OpenSSH 源自最初 Tatu Ylonen 發表的自由 ssh 1.2.12.  Aaron Campbell, Bob Beck, Markus
     Friedl, Niels Provos, Theo de Raadt 和 Dug Song 消除了許多 BUGS, 增加新的特徵, 從而創建了
     OpenSSH.  Markus Friedl 貢獻了對 SSH 協議1.5版和2.0版的支持.

另見 (SEE ALSO)

     rsh(1), scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), telnet(1), ssh_config(5),
     ssh-keysign(8), sshd(8) T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen, SSH
     Protocol Architecture, draft-ietf-secsh-architecture-12.txt, January 2002, work in progress
     material.

[中文版維護人]

     徐明 <xuming@users.sourceforge.net>

[中文版最新更新]

     2004/06/11 第一版

《中國Linux論壇man手冊頁翻譯計劃》

     http://cmpp.linuxforum.net

跋

     本頁面中文版由中文 man 手冊頁計劃提供。
     中文 man 手冊頁計劃：https://github.com/man-pages-zh/manpages-zh