Scroll to navigation

SSH(1) General Commands Manual SSH(1)

NAME

sshOpenSSH 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 porthostnameuser@hostname [command]

描述 (DESCRIPTION)

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

當用戶透過 ssh 連線並登入主機 hostname 後, 根據所用的協議版本, 使用者必須透過下述方法之一向遠端主機證明他/她的身份:

SSH 協議第一版

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

第二種認證方法是 rhostshosts.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 命令 (假設是預設的 ‘~’) 有:

斷開連線
把 ssh 送到後臺
列出轉發的連線 (forwarded connection)
當等待轉發的連線/X11會話結束時, ssh 在後臺退出登入
顯示 escape 字元的列表
開啟命令列 (僅用於 -L-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 選項用來防止登入到主機金鑰不能識別或發生改變的那些機器.

命令列選項有:

禁止轉發認證代理的連線.
允許轉發認證代理的連線. 可以在配置檔案中對每個主機單獨設定這個引數.

代理轉發須謹慎. 某些使用者能夠在遠端主機上繞過檔案訪問許可權 (由於代理的 UNIX 域 socket), 他們可以透過轉發的連線訪問本地代理. 攻擊者不可能從代理獲得金鑰內容, 但是他們能夠操作這些金鑰, 利用載入到代理上 的身份資訊透過認證.

bind_address
在擁有多個介面或地址別名的機器上, 指定收發介面.
blowfish|3des|des
選擇加密會話的密碼術. 3des 是預設演算法. 3des (triple-des) 用三支不同的金鑰做加密-解密-加密三次運算, 被認為比較可靠. blowfish 是一種快速的分組加密術(block cipher), 非常安全, 而且速度比 3des 快的多. des 僅支援 ssh 客戶端, 目的是能夠和老式的不支援 3des 的協議第一版互操作. 由於其密碼演算法上的弱點, 強烈建議避免使用.
cipher_spec
另外, 對於協議第二版, 這裡可以指定一組用逗號隔開, 按優先順序排列的密碼術. 詳見 Ciphers.
ch|^ch|none
設定 pty 會話的 escape 字元 (預設字元: ‘~’). escape 字元只在行首有效, escape 字元後面跟一個點 (‘.’) 表示結束連線, 跟一個 control-Z 表示掛起連線(suspend), 跟 escape 字元自己 表示輸出這個字元. 把這個字元設為 “none” 則禁止 escape 功能, 使會話完全透明.
要求 ssh 在執行命令前退至後臺. 它用於當 ssh 準備詢問口令或密語, 但是使用者希望它在後臺進行. 該選項隱含了 -n 選項. 在遠端機器上啟動 X11 程式的推薦手法就是類似於 ssh -f host xterm 的命令.
允許遠端主機連線本地轉發的埠.
identity_file
指定一個 RSA 或 DSA 認證所需的身份(私鑰)檔案. 預設檔案是協議第一版的 $HOME/.ssh/identity 以及協議第二版的 $HOME/.ssh/id_rsa$HOME/.ssh/id_dsa 檔案. 也可以在配置檔案中對每個主機單獨指定身份檔案. 可以同時使用多個 -i 選項 (也可以在配置檔案中指定多個身份檔案).
smartcard_device
指定智慧卡(smartcard)裝置. 引數是裝置檔案, ssh 能夠用它和智慧卡通訊, 智慧卡里面儲存了使用者的 RSA 私鑰.
禁止轉發 Kerberos 門票和 AFS 令牌. 可以在配置檔案中對每個主機單獨設定這個引數.
login_name
指定登入遠端主機的使用者. 可以在配置檔案中對每個主機單獨設定這個引數.
mac_spec
另外, 對於協議第二版, 這裡可以指定一組用逗號隔開, 按優先順序排列的 MAC(訊息驗證碼)演算法 (message authentication code). 詳情以 MACs 為關鍵字查詢.
把 stdin 重定向到 /dev/null (實際上防止從 stdin 讀取資料). ssh 在後臺執行時一定會用到這個選項. 它的常用技巧是遠端執行 X11 程式. 例如, ssh -n shadows.cs.hut.fi emacs & 將會在 shadows.cs.hut.fi 上啟動 emacs, 同時自動在加密通道中轉發 X11 連線. ssh 在後臺執行. (但是如果 ssh 要求口令或密語, 這種方式就無法工作; 參見 -f 選項.)
不執行遠端命令. 用於轉發埠. (僅限協議第二版)
option
可以在這裡給出某些選項, 格式和配置檔案中的格式一樣. 它用來設定那些沒有命令列開關的選項.
port
指定遠端主機的埠. 可以在配置檔案中對每個主機單獨設定這個引數.
安靜模式. 消除所有的警告和診斷資訊.
請求遠端系統啟用一個子系統. 子系統是 SSH2 協議的一個特性, 能夠協助 其他應用程式(如 sftp)把SSH用做安全通路. 子系統透過遠端命令指定.
強制分配偽終端. 可以在遠端機器上執行任何全螢幕(screen-based)程式, 所以非常有用, 例如選單服務. 並聯的 -t 選項強制分配終端, 即使 ssh 沒有本地終端.
禁止分配偽終端.
冗詳模式. 使 ssh 列印關於執行情況的除錯資訊. 在除錯連線, 認證和配置問題時非常有用. 並聯的 -v 選項能夠增加冗詳程度. 最多為三個.
禁止 X11 轉發.
允許 X11 轉發. 可以在配置檔案中對每個主機單獨設定這個引數.

應該謹慎使用 X11 轉發. 如果使用者在遠端主機上能夠繞過檔案訪問許可權 (根據使用者的X授權資料庫), 他就可以透過轉發的連線訪問本地 X11 顯示器. 攻擊者可以據此採取行動, 如監視鍵盤輸入等.

要求進行資料壓縮 (包括 stdin, stdout, stderr 以及轉發 X11 和 TCP/IP 連線 的資料). 壓縮演算法和 gzip(1) 的一樣, 協議第一版中, 壓縮級別 “level” 用 CompressionLevel 選項控制. 壓縮技術在 modem 線路或其他慢速連線上很有用, 但是在高速網路上反而 可能降低速度. 可以在配置檔案中對每個主機單獨設定這個引數. 另見 Compression 選項.
configfile
指定一個使用者級配置檔案. 如果在命令列上指定了配置檔案, 系統級配置檔案 (/etc/ssh/ssh_config) 將被忽略. 預設的使用者級配置檔案是 $HOME/.ssh/config.
port:host:hostport
將本地機(客戶機)的某個埠轉發到遠端指定機器的指定埠. 工作原理是這樣的, 本地機器上分配了一個 socket 偵聽 port 埠, 一旦這個埠上有了連線, 該連線就經過安全通道轉發出去, 同時遠端主機和 hosthostport 埠建立連線. 可以在配置檔案中指定埠的轉發. 只有 root 才能轉發特權埠. IPv6 地址用另一種格式說明: port/host/hostport
port:host:hostport
將遠端主機(伺服器)的某個埠轉發到本地端指定機器的指定埠. 工作原理是這樣的, 遠端主機上分配了一個 socket 偵聽 port 埠, 一旦這個埠上有了連線, 該連線就經過安全通道轉向出去, 同時本地主機和 hosthostport 埠建立連線. 可以在配置檔案中指定埠的轉發. 只有用 root 登入遠端主機 才能轉發特權埠. IPv6 地址用另一種格式說明: port/host/hostport
port
指定一個本地機器 “動態的” 應用程式埠轉發. 工作原理是這樣的, 本地機器上分配了一個 socket 偵聽 port 埠, 一旦這個埠上有了連線, 該連線就經過安全通道轉發出去, 根據應用程式的協議可以判斷出遠端主機將和哪裡連線. 目前支援 SOCKS4 協議, ssh 將充當 SOCKS4 伺服器. 只有 root 才能轉發特權埠. 可以在配置檔案中指定動態埠的轉發.
強制 ssh 只使用協議第一版.
強制 ssh 只使用協議第二版.
強制 ssh 只使用 IPv4 地址.
強制 ssh 只使用 IPv6 地址.

配置檔案 (CONFIGURATION FILES)

ssh 可以從使用者級配置檔案和系統級配置檔案中獲取更多的配置資料. 配置檔案的格式及其內容參見 ssh_config(5).

環境變數 (ENVIRONMENT)

ssh 一般將設定下面的環境變數:

環境變數 DISPLAY 指出 X11 伺服器的位置. ssh 自動設定這個變數, 變數指向 “hostname:n” 格式的資料, 其中 hostname 指出執行 shell 的主機, 而 n 是大於等於 1 的整數. ssh 根據這個資料, 用安全通路轉發 X11 連線. 使用者一般不需要主動設定 DISPLAY 變數, 否則會導致 X11 連線不安全 (而且會導致使用者手工複製所需的授權 cookie).
設定為使用者根目錄的路徑.
等於 USER; 用來相容使用這個變數的系統.
設定為使用者郵箱的路徑.
設定為預設的 PATH, 如同編譯 ssh 時要求的一樣.
如果 ssh 需要一個密語(passphrase), 只要它是終端上啟動的, 它會從當前終端上讀取. 如果 ssh 沒有聯接終端, 但是設定了 DISPLAYSSH_ASKPASS 變數, ssh 就執行 SSH_ASKPASS 指定的程式, 開啟一個 X11 視窗讀取密語. 當從 .Xsession 或類似的 script 中呼叫 ssh 時, 這個功能特別有用. (注意, 某些機器上可能需要將輸入重定向為 /dev/null 才能工作.)
標識某個 UNIX 域 socket 的路徑, 用於和代理通訊.
標識連線的客戶端和伺服器端. 變數包含四個用空格隔開的欄位: 客戶端IP地址, 客戶端埠號, 伺服器IP地址, 伺服器埠號.
如果強制執行了某條命令, 該變數就儲存了最初的命令列. 可以用它獲取初始引數.
設定為關聯當前 shell 或命令的終端名字(裝置的路徑). 如果會話沒有終端, 就不設定這個變數.
如果啟動後臺程序(daemon)時設定了時區, 就設定這個時區變數, 指出現在的時區 (就是說, 後臺程序會把這個變數傳給新建連線).
設定為登入的使用者名稱.

另外, 如果允許使用者改變他們的環境資料, 而且有 $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
這三個檔案包含了主機金鑰的私有部分, 它們用於 RhostsRSAAuthenticationHostbasedAuthentication. 如果使用了協議第一版的 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 認證的同時防止 rloginrsh(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

September 25, 1999 Debian