SSH(1) | General Commands Manual | SSH(1) |
ssh
— OpenSSH SSH
客戶端
(遠端登入程式)
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]
ssh
(SSH 客戶端)
用於登入遠端主機,
並且在遠端主機上執行命令.
它的目的是替換 rlogin 和
rsh,
同時在不安全的網路之上,
兩個互不
信任的主機之間,
提供加密的,
安全的通訊連線. X11
連線和任意 TCP/IP
埠均可以透過此安全通道轉發(forward).
當用戶透過
ssh
連線並登入主機
hostname 後,
根據所用的協議版本,
使用者必須透過下述方法之一向遠端主機證明他/她的身份:
第一, 如果發出登入命令的本地主機已經列在遠端主機的 /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),
然後把口令送到伺服器做驗證.
由於整個通訊過程是
加密的,
因此別人不可能透過偵聽網路獲得這個口令.
當用戶以協議第二版連線時,
類似的認證方法一樣有效.
如果使用了
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
的返回碼返回.
如果啟用了偽終端,
ssh
能夠透過 escape
字元支援一組功能.
單獨的波浪符可以用
~~
送出去,
只要後面不跟下面列舉的字元,
也可以把它直接送出去.
escape
字元必須接在換行(newline)後面,
這樣才具有特別含義.
在配置檔案中可以用
EscapeChar
命令更改 escape
字元,
在命令列上可以用
-e
選項更改.
已支援的 escape 命令
(假設是預設的
‘~
’) 有:
如果 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|desssh
客戶端,
目的是能夠和老式的不支援
3des
的協議第一版互操作.
由於其密碼演算法上的弱點,
強烈建議避免使用.-c
cipher_specCiphers
.-e
ch|^ch|none~
’). escape
字元只在行首有效, escape
字元後面跟一個點
(‘.
’)
表示結束連線, 跟一個
control-Z 表示掛起連線(suspend),
跟 escape 字元自己
表示輸出這個字元.
把這個字元設為
“none” 則禁止 escape 功能,
使會話完全透明.-f
ssh
在執行命令前退至後臺.
它用於當 ssh
準備詢問口令或密語,
但是使用者希望它在後臺進行.
該選項隱含了
-n
選項.
在遠端機器上啟動 X11
程式的推薦手法就是類似於
ssh -f host xterm
的命令.-g
-i
identity_file-i
選項
(也可以在配置檔案中指定多個身份檔案).-I
smartcard_devicessh
能夠用它和智慧卡通訊,
智慧卡里面儲存了使用者的
RSA 私鑰.-k
-l
login_name-m
mac_specMACs
為關鍵字查詢.-n
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
-t
-t
選項強制分配終端,
即使 ssh
沒有本地終端.-T
-v
ssh
列印關於執行情況的除錯資訊.
在除錯連線,
認證和配置問題時非常有用.
並聯的 -v
選項能夠增加冗詳程度.
最多為三個.-x
-X
應該謹慎使用 X11 轉發. 如果使用者在遠端主機上能夠繞過檔案訪問許可權 (根據使用者的X授權資料庫), 他就可以透過轉發的連線訪問本地 X11 顯示器. 攻擊者可以據此採取行動, 如監視鍵盤輸入等.
-C
CompressionLevel
選項控制.
壓縮技術在 modem
線路或其他慢速連線上很有用,
但是在高速網路上反而
可能降低速度.
可以在配置檔案中對每個主機單獨設定這個引數.
另見 Compression
選項.-F
configfile-L
port:host:hostport-R
port:host:hostport-D
portssh
將充當 SOCKS4
伺服器. 只有 root
才能轉發特權埠.
可以在配置檔案中指定動態埠的轉發.-1
ssh
只使用協議第一版.-2
ssh
只使用協議第二版.-4
ssh
只使用 IPv4
地址.-6
ssh
只使用 IPv6
地址.ssh
可以從使用者級配置檔案和系統級配置檔案中獲取更多的配置資料.
配置檔案的格式及其內容參見
ssh_config(5).
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
SSH_CONNECTION
SSH_ORIGINAL_COMMAND
SSH_TTY
TZ
USER
另外,
如果允許使用者改變他們的環境資料,
而且有 $HOME/.ssh/environment
這個檔案, ssh
將讀取其中資料, 把
“VARNAME=value”
這種格式的資料行新增進環境資料區.
另見 sshd_config(5) 的
PermitUserEnvironment
選項.
ssh
將忽略這個檔案.
在生成金鑰的時候可以指定一個密語(passphrase),
用這個密語和 3DES
加密檔案的敏感部分.登入的時候,
sshd(8)
用規範的系統名字(名字伺服器返回的)確認客戶機;
其他名字也需要,
因為校驗金鑰前
ssh
不會把使用者提供的名字轉換為規範名字,
防止能夠操作名字伺服器的人欺騙主機認證.
RhostsRSAAuthentication
和
HostbasedAuthentication
.
如果使用了協議第一版的
RhostsRSAAuthentication
方法,
ssh
必須是 setuid root,
因為只有 root
才能讀取主機金鑰.
而對於協議第二版的
HostbasedAuthentication
方法,
ssh
使用
ssh-keysign(8)
訪問主機金鑰.
這樣消除了驗證身份時對
ssh
setuid root 的要求.
預設情況下 ssh
不是 setuid root.注意, 預設情況下會安裝 sshd(8) , 因此在允許 .rhosts 認證前, sshd(8) 要求成功進行了 RSA 主機驗證. 如果沒有 /etc/ssh/ssh_known_hosts 檔案存放客戶的主機金鑰, 金鑰可以存放在 $HOME/.ssh/known_hosts 中. 最簡單的做法是用 ssh 從伺服器回連客戶機; 這樣會自動把主機金鑰新增到 $HOME/.ssh/known_hosts.
ssh
做 rhosts
認證的同時防止
rlogin
或 rsh(1)
登入.ssh
登入, 但不允許 rsh/rlogin
的時候.ssh
執行這個檔案中的命令.
詳見 sshd(8) 手冊頁.ssh
執行這個檔案中的命令.
詳見 sshd(8) 手冊頁.ssh
結束時的狀態碼就是遠端命令結束時的返回碼,
如果發生了錯誤就返回255.
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版的支援.
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 第一版
http://cmpp.linuxforum.net
本頁面中文版由中文
man 手冊頁計劃提供。
中文 man
手冊頁計劃:https://github.com/man-pages-zh/manpages-zh
September 25, 1999 | Debian |