Provided by: manpages-zh_1.6.4.3-1_all 
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
Debian September 25, 1999 SSH(1)