SSH 協議第一版¶

第二種認證方法是 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 協議第二版¶

這個公開密鑰方法類似於上一節描述的 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). 注意, 協議第一版缺少強有力的機制確保連接的完整性.

登錄會話和遠程執行¶

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

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

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

Escape 字符¶

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

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

~.

斷開連接

~^Z

把 ssh 送到後臺

~#

列出轉發的連接 (forwarded connection)

~&

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

~?

顯示 escape 字符的列表

~C

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

~R

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

X11 和 TCP 轉發 (forwarding)¶

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 轉向的應用有, 比如說, 和電子錢包的安全連接, 或者是穿過防火牆等.

服務器認證¶

命令行選項有:

-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 地址.