目 錄
1.1 H3C設備作為服務器,用戶使用密碼認證登錄失敗.. 1
1.2 H3C設備作為服務器,用戶使用公鑰認證登錄失敗.. 7
1.3 H3C設備作為客戶端,用戶使用密碼認證登錄失敗.. 11
1.4 H3C設備作為客戶端,用戶使用公鑰認證登錄失敗.. 14
& 說明:
本文檔不嚴格和具體的軟硬件版本對應。
H3C設備作為SSH服務器,SSH客戶端配置無誤,用戶在SSH客戶端以密碼認證方式登錄服務器時失敗。
圖1-1 H3C設備作為服務器,用戶使用密碼認證無法登錄服務器故障處理流程圖
在客戶端ping服務器的IP地址,檢查客戶端和服務器端的網絡是否可用,排除因網絡故障導致SSH連接不能建立的可能性。
如果服務器端未開啟SSH服務器功能,則客戶端無法登錄服務器。可以通過下述命令確認SSH服務器端是否開啟了SSH服務器功能:
<Server> display ssh server status
SSH server: Disable
SSH version : 1.99
SSH authentication-timeout : 60 second(s)
SSH server key generating interval : 0 hour(s)
SSH authentication retries : 3 time(s)
SFTP server: Disable
SFTP server Idle-Timeout: 10 minute(s)
如果SSH服務器的狀態為Disable,則需要在服務器上通過ssh server enable命令開啟SSH服務器功能。
如果是使用SFTP方式登錄,還需要檢查是否使能了SFTP服務。在服務器上通過sftp server enable命令可以使能SFTP服務。
服務器和客戶端之間的版本不能協商成功,則連接無法建立。可以通過display ssh server status命令查看服務器上的SSH版本。
<Server> display ssh server status
SSH server: Disable
SSH version : 1.99
SSH authentication-timeout : 60 second(s)
SSH server key generating interval : 0 hour(s)
SSH authentication retries : 3 time(s)
SFTP server: Disable
SFTP server Idle-Timeout: 10 minute(s)
SSH服務器的版本號是SSH2.0時,如果客戶端使用SSH1.5或更低的版本,則版本協商會失敗。
如果客戶端必須使用SSH1.5版本登錄,可以在服務器上通過ssh server compatible-ssh1x enable命令配置服務器兼容SSH1.5版本,此時顯示的SSH版本為1.99;如果客戶端版本可以選擇,建議使用SSH2.0的版本,這樣連接會更加安全。
開啟SSH服務器功能後,如果客戶端登錄服務器端時,未提示用戶是否認可該服務器身份,就退出了登錄,且服務器端沒有任何調試輸出,則可能是由於服務器端的VTY用戶界麵配置不正確導致的。
(1) SSH用戶登錄時要求存在認證模式是scheme的VTY用戶界麵
可以通過下述命令查看VTY用戶界麵上的配置:
[Server-ui-vty0-4] display this
#
user-interface con 0
user-interface vty 0 4
#
return
缺省情況下,VTY用戶界麵的認證模式不是scheme,需要在VTY用戶界麵視圖下增加如下配置:
[Server-ui-vty0-4] authentication-mode scheme
(2) SSH用戶登錄時要求VTY用戶界麵支持SSH協議
可以通過下述命令查看VTY用戶界麵上的配置:
[Server-ui-vty0-4] display this
#
user-interface con 0
user-interface vty 0 4
authentication-mode scheme
protocol inbound telnet
#
return
上述配置表明VTY用戶界麵僅支持Telnet協議,增加如下配置可以解決此問題:
[Server-ui-vty0-4] protocol inbound all
缺省情況下,VTY用戶界麵支持包括SSH在內的所有協議。
為了防止“偽服務器欺騙”,客戶端登錄服務器端時,客戶端通過數字簽名的方法驗證服務器的身份。如果客戶端沒有保存服務器的公鑰或保存的服務器公鑰不正確,則服務器身份驗證將會失敗,從而導致客戶端無法登錄服務器。因此,客戶端登錄服務器之前,需要先在服務器端創建密鑰對,並將正確的服務器公鑰保存在客戶端。
如果客戶端輸入用戶名後,未提示用戶是否認可服務器的身份即退出登錄,則問題的原因可能是服務器端未創建密鑰對。
可以通過下述命令查看服務器端的公鑰配置:
<Server> display public-key local dsa public
或
<Server> display public-key local rsa public
如果沒有顯示配置的DSA或RSA公鑰,說明服務器上還沒有配置公鑰。通過以下方式可以解決該問題:
(1) 在服務器端執行public-key local create命令創建密鑰對;
(2) 在服務器端執行public-key local export命令將服務器端的公鑰導入到文件中;
(3) 將保存服務器公鑰的文件通過FTP/TFTP方式上傳到客戶端,並在客戶端指定該公鑰文件用於認證服務器身份。
客戶端登錄服務器時,提示用戶反複輸入密碼,但是認證都不成功。該問題的原因可能是服務器端不存在該用戶。
SSH為了防止用戶名猜測,服務器不會提示客戶端登錄的用戶名不存在。可以通過display local-user命令查看服務器端的本地用戶配置,如果AAA使用遠程認證,需要查看遠程認證服務器上的用戶配置。
如果服務器端不存在該用戶名,則需要在服務器上創建該用戶。
客戶端登錄服務器時,提示用戶反複輸入密碼,但是認證都不成功。該問題的原因也可能是:
(1) 密碼不正確
用戶登錄時輸入的用戶名和密碼要求與服務器上配置的完全一致。如果輸入的密碼錯誤,則需要獲取正確的密碼,或修改服務器上用戶名對應的密碼。
(2) 用戶已經被服務器記入黑名單
在某些設備上,使能密碼管理功能後,對於連續失敗認證次數超過設置次數的終端,服務器會將其IP地址以及用戶名記入黑名單中,並拒絕後續從該終端登錄的用戶。
可以通過display password-control blacklist命令查看服務器端的黑名單列表,確認用戶是否已經列入黑名單。如果用戶被列入黑名單,則無法登錄服務器。
可以通過reset password-control blacklist user-name命令將指定用戶從黑名單中刪除。
(3) 用戶可以使用的服務類型設置不正確
SSH用戶要想成功登錄服務器,則需要在服務器上指定用戶可以使用的服務類型為SSH。
可以通過display local-user命令查看用戶可以使用的服務類型是否為SSH;如果AAA使用遠程認證,則必須查看遠程認證服務器上的用戶配置。
<Server> display local-user user-name test
The contents of local user test:
State: Active
ServiceType: ssh
Access-limit: Disable Current AccessNum: 0
User-group: system
Bind attributes:
Authorization attributes:
Total 1 local user(s) matched.
如果用戶可以使用的服務類型配置不正確,則需要在本地用戶視圖下通過service-type ssh命令或在遠程服務器上修改本地用戶的配置。
SSH用戶服務類型包括Stelnet和SFTP兩種。如果用戶登錄時使用的服務類型與服務器上配置的用戶服務類型不一致,則用戶登錄會失敗。
可以在服務器端通過display ssh user-information命令查看SSH用戶的配置:
<Server> display ssh user-information
Total ssh users:1
Username Authentication-type User-public-key-name Service-type
test password null sftp
如果為登錄用戶配置的服務類型與用戶登錄時實際使用的服務類型不一致,則可以通過ssh user username service-type命令修改用戶的服務類型。
服務器端打印如下調試信息後,用戶退出登錄。
*Jan 24 14:40:12:100 2008 Server SSH/7/Server_ERROR: VTY[0]:Login Error:
SSH user user failed to login because of authentication timeout.
出現這個問題的原因是用戶登錄過程的時間超過了服務器設置的時間,一般是由服務器上設置的超時時間不合適導致的。
可以通過display ssh server status命令查看服務器上的超時時間配置:
<Server> display ssh server status
SSH server: Enable
SSH version : 2.0
SSH authentication-timeout : 20 second(s)
SSH server key generating interval : 0 hour(s)
SSH authentication retries : 3 time(s)
SFTP server: Disable
SFTP server Idle-Timeout: 10 minute(s)
SSH登錄過程中密鑰交換運算量比較大,如果設備性能較低,需要配置較長的認證超時時間。
通過ssh server authentication-timeout命令可以修改服務器端配置的認證超時時間。
SSH用戶服務類型為SFTP時,如果服務器上設置的SFTP用戶工作目錄不正確,則用戶不能成功登錄。
服務器端打印如下調試信息時,登錄失敗的原因可能是工作目錄設置錯誤。
Jan 30 17:12:34:891 2008 Server SSH/7/Server_MESSAGE: VTY[0]:SSH_Channel:
Send Message SSH2_MSG_CHANNEL_FAILURE(100):RemoteID=1
*Jan 30 17:12:34:891 2008 Server SSH/7/Server_ERROR: SFTPS Error:
Invalid sftp service or maximum sftp sessions exceeded.
對於隻采用密碼方式認證的用戶,工作目錄為通過AAA授權的工作目錄。通過如下方法可以查看本地為用戶配置的工作目錄是否正確。
[Server-luser-test] display this
#
local-user test
password simple 123
authorization-attribute work-directory cf:/
service-type ssh
#
return
如果工作目錄配置錯誤,則需要通過在本地用戶視圖下執行authorization-attribute work-directory命令配置正確的工作目錄。
如果AAA使用遠程認證,則需要在遠程認證服務器上修改用戶的工作目錄。
H3C設備作為服務器,SSH客戶端配置無誤,用戶在SSH客戶端以公鑰認證方式登錄服務器時失敗。
圖1-2 H3C設備作為服務器,用戶使用公鑰認證無法登錄服務器故障處理流程圖
H3C設備作為服務器,用戶使用公鑰認證無法登錄服務器與使用密碼認證無法登錄服務器的故障處理過程類似,二者的區別主要在於:
l 公鑰認證利用RSA或DSA算法,采用數字簽名的方法認證用戶;密碼認證采用密碼比較的方式認證用戶。因此,故障處理過程中的“1.1.3 7. 認證失敗”有所不同。
l 公鑰認證和密碼認證用戶使用的工作目錄不同。隻采用密碼認證方式的用戶,使用的工作目錄為通過AAA授權的工作目錄;采用公鑰認證方式的用戶,使用的工作目錄為通過ssh user命令為該用戶設置的工作目錄。因此,故障處理過程中的“1.1.3 10. 檢查SFTP工作目錄配置是否正確”有所不同。
下麵隻說明與使用密碼認證無法登錄服務器故障處理過程不同的步驟,其他故障排除方法請參見“1.1.3 故障處理步驟”。
客戶端使用公鑰認證方式登錄SSH服務器,認證失敗,服務器端的調試信息如下:
*Jan 30 10:12:28:703 2008 Server SSH/7/Server_ERROR: VTY[0]:Process AuthPK Error: Failed to vertify public key!
*Jan 30 10:12:28:703 2008 Server SSH/7/Server_EVENT: VTY[0]:LOGIN Failed:
SSH user user failed to login from 192.168.1.2(0000-5e28-b700) on VTY0.
*Jan 30 10:22:28:875 2008 Server SSH/7/Server_EVENT: VTY[0]:SSH user[user] have reached the max permit retry times[3].
出現這個問題可能的原因是:
(1) 服務器端配置的用戶公鑰錯誤
通過display ssh user-information命令在服務器端查看該用戶對應的公鑰名稱。
<Server> display ssh user-information
Total ssh users:1
Username Authentication-type User-public-key-name Service-type
test1 publickey user_key3 stelnet|sftp
通過display public-key peer命令查看用戶公鑰的詳細信息。
<Server> display public-key peer name user_key3
=====================================
Key Name : user_key3
Key Type : RSA
Key Module: 1024
=====================================
Key Code:
30819F300D06092A864886F70D010101050003818D0030818902818100E31EE84BB745DA6F9ACCF5B6CA7BC4C0599A45F65281BE869AD90A192D37BBCE5683F7A68F0C95A0399A3022C7F66EC52DE951630874CD8EE11AFA876ABE3937E86BF9A83EFC0C8E68144FE38DFAEDC12E48654F8D15703455C96E9BCE026A91A2435E675BB7420D5A4AB5CE2520A213405AFED986F8F59101B745D9BF9BBA4D0203010001
在客戶端顯示用戶公鑰的信息,與服務器端保存的用戶公鑰進行比較。如果不一致,則需要重新獲取用戶的公鑰。獲取方法為:將用戶的公鑰文件通過FTP/TFTP以二進製方式上傳到服務器,通過public-key peer import sshkey命令從公鑰文件中導入公鑰,並通過ssh user命令指定與用戶關聯的公鑰。
& 說明
不同SSH客戶端顯示用戶公鑰的方式不同,請以實際情況為準。
(2) 服務器端配置的用戶公鑰和用戶使用的私鑰不匹配
SSH客戶端可能支持多種公鑰算法,每種公鑰算法對應不同的公鑰和私鑰對。隻有服務器端保存的用戶公鑰類型與用戶登錄時使用的私鑰類型一致時,用戶認證才會成功。例如,服務器端為某用戶配置了DSA類型的公鑰,用戶也持有與之相匹配的私鑰,但是登錄時用戶使用的私鑰類型為RSA,此時用戶認證將會失敗。
可以通過以下方法解決該問題:客戶端登錄服務器時使用的用戶私鑰類型與服務器上為用戶配置的公鑰類型保持一致。
& 說明
不同SSH客戶端指定認證過程中使用的私鑰的方式不同,有些客戶端通過命令關鍵字指定私鑰類型,有些客戶端直接指定私鑰文件,請以SSH客戶端的實際情況為準。
SSH用戶服務類型為SFTP時,如果服務器上設置的SFTP用戶工作目錄不正確,則用戶不能成功登錄。
服務器端打印如下調試信息時,登錄失敗的原因可能是工作目錄設置錯誤。
Jan 30 17:12:34:891 2008 Server SSH/7/Server_MESSAGE: VTY[0]:SSH_Channel:
Send Message SSH2_MSG_CHANNEL_FAILURE(100):RemoteID=1
*Jan 30 17:12:34:891 2008 Server SSH/7/Server_ERROR: SFTPS Error:
Invalid sftp service or maximum sftp sessions exceeded.
采用公鑰認證方式的用戶,使用的工作目錄為通過ssh user命令的work-directory關鍵字為該用戶設置的工作目錄。通過下麵的方法查看工作目錄設置是否正確:
<Server> display current-configuration | include ssh user
ssh user test service-type sftp authentication-type publickey assign publickey test work-directory cf:/
如果工作目錄設置錯誤,則需要通過ssh user命令指定正確的工作目錄。
H3C設備作為SSH客戶端,SSH服務器配置無誤,用戶在SSH客戶端輸入登錄命令,以密碼認證方式登錄服務器時失敗。
圖1-3 H3C設備作為客戶端,用戶使用密碼認證登錄失敗故障處理流程圖
在客戶端ping服務器的IP地址,檢查客戶端和服務器端的網絡是否可用,排除因網絡故障導致SSH連接不能建立的可能性。
客戶端和服務器之間的版本協商失敗,會導致連接無法建立。
設備作為SSH客戶端時支持的版本為SSH2.0,如果服務器使用SSH1.5或更低的版本,則版本協商會失敗。隻有更改服務器的版本,使其支持SSH2.0,才能解決該問題。
為了防止“偽服務器欺騙”,客戶端登錄服務器端時,客戶端通過數字簽名的方法驗證服務器的身份。如果客戶端沒有保存服務器的公鑰或保存的服務器公鑰不正確,則服務器身份驗證將會失敗,從而導致客戶端無法登錄服務器。
設備作為SSH客戶端時支持首次認證功能,即當SSH客戶端首次訪問服務器,而客戶端沒有配置服務器端的主機公鑰時,用戶可以選擇繼續訪問該服務器,並在客戶端保存該主機公鑰,當用戶下次訪問該服務器時,就以保存的主機公鑰來認證該服務器。如果配置SSH客戶端支持首次認證功能,則不需要事先在客戶端配置服務器的公鑰;否則,需要在登錄服務器之前,在客戶端上配置正確的服務器的公鑰。缺省情況下,客戶端支持首次認證。
(1) 客戶端不支持首次認證,但未提前在本地配置服務器公鑰
客戶端登錄服務器時,輸入用戶名後馬上退出:
<Client> ssh2 192.168.1.1
Username: test
Trying 192.168.1.1 ...
Press CTRL+K to abort
Connected to 192.168.1.1 ...
Connection closed.
這個問題可能是由於客戶端配置了不支持首次認證,但是未提前在客戶端手工配置服務器公鑰造成的。
通過命令display current-configuration命令可以查看當前是否配置了undo ssh client first-time命令,從而確定客戶端是否支持首次認證。如果配置了該命令,則客戶端不支持首次認證。
可以通過兩種方法解決上述問題:
l 將服務器端的公鑰文件通過FTP/TFTP以二進製方式上傳到客戶端,通過public-key peer import sshkey命令從公鑰文件中導入公鑰,並通過ssh client authentication server命令在客戶端手工配置服務器與公鑰之間的關聯;
l 通過ssh client first-time enable命令配置客戶端支持首次認證。
注意
如果配置了ssh client first-time enable命令,客戶端本身無法保證連接的安全性。
(2) 客戶端保存的服務器公鑰與實際的服務器公鑰不一致
客戶端登錄服務器時,提示如下信息:
<Client> ssh2 192.168.40.182
Username: test
Trying 192.168.40.182 ...
Press CTRL+K to abort
Connected to 192.168.40.182 ...
The server's host key does not match the local cached key. Either the server administrator has changed the host key, or you connected to another server pretending to be this server. Please remove the local cached key, before logging in!
Connection closed.
這個問題是由於客戶端保存的服務器公鑰和服務器的實際公鑰不一致,導致客戶端認證服務器身份失敗。可以通過下述方法查看客戶端保存的服務器公鑰。
首先,顯示客戶端保存的該服務器公鑰的名稱。
<Client> display ssh server-info
Server Name(IP) Server public key name
_________________________________________________________________________
192.168.40.182 server-key-name
其次,顯示本地保存的服務器公鑰的信息。
<Client> display public-key peer name server-key-name
最後,將顯示的內容和服務器端本地顯示的公鑰進行比較,如果不一致則可以確定是該問題。
& 說明
l 不同SSH服務器顯示用戶公鑰的方式不同,請以實際情況為準。
l 同時采用H3C設備作為SSH客戶端和SSH服務器時,SSH客戶端采用DSA算法認證SSH服務器端的身份,因此需要在SSH客戶端上保存SSH服務器的DSA公鑰。
為了解決這個問題,首先需要在客戶端執行如下命令,取消服務器與錯誤公鑰之間的關聯:
[Client] undo ssh client authentication server 192.168.40.182 assign publickey
然後,可以通過以下兩種方法重新獲取服務器的公鑰:
l 將服務器端的公鑰文件通過FTP/TFTP以二進製方式上傳到客戶端,通過public-key peer import sshkey命令從公鑰文件中導入公鑰,並通過ssh client authentication server命令在客戶端手工配置服務器與公鑰之間的關聯;
l 在客戶端配置命令ssh client first-time enable,使能客戶端首次認證功能,客戶端再次登錄服務器時,自動從服務器端獲取公鑰,並建立關聯。
客戶端登錄服務器時,提示用戶反複輸入密碼,但是認證都不成功。該問題的原因可能是用戶輸入的用戶名和密碼不正確。請獲取正確的用戶名和密碼,再登錄。
H3C設備作為SSH客戶端,SSH服務器配置無誤,用戶在SSH客戶端輸入登錄命令,以公鑰認證方式登錄服務器時失敗。
圖1-4 H3C設備作為客戶端,用戶使用公鑰認證登錄失敗
H3C設備作為客戶端,用戶使用公鑰認證登錄失敗的故障處理流程與使用密碼認證登錄失敗的故障處理流程類似。二者的區別主要在於:公鑰認證利用RSA或DSA算法,采用數字簽名的方法認證用戶;密碼認證采用密碼比較的方式認證用戶。因此,故障處理過程中的最後一步有所不同。下麵隻說明二者不同的步驟,其他故障排除方法請參見“1.3.3 故障處理步驟”。
H3C設備作為SSH客戶端時,支持使用RSA和DSA兩種類型的公鑰算法認證客戶端。服務器端保存的用戶公鑰類型與用戶登錄時指定的公鑰認證算法(通過登錄命令ssh2或sftp中的identity-key關鍵字指定)一致時,認證才會成功。例如,服務器端為某用戶配置了DSA類型的公鑰,用戶也持有與之相匹配的私鑰,但是登錄時用戶指定公鑰認證算法為RSA,此時用戶認證將失敗。
可以通過以下方法解決該問題:用戶執行ssh2或sftp命令登錄服務器時,通過identity-key關鍵字指定的公鑰認證算法與服務器上為用戶配置的公鑰類型保持一致。H3C設備作為SSH客戶端,缺省情況下使用公鑰認證算法為DSA。
命令 | 說明 |
display local-user | 顯示本地用戶的相關信息 |
display password-control blacklist | 顯示用戶認證失敗後,被加入黑名單中的用戶信息 |
display public-key local | 顯示本地密鑰對的公鑰部分 |
display public-key peer | 顯示保存在本地的遠端公鑰信息 |
display ssh server status | 在SSH服務器端顯示該服務器的狀態信息 |
display ssh user-information | 在SSH服務器端顯示SSH用戶信息 |
debugging ssh server | 打開SSH服務器的調試信息開關 |
命令 | 說明 |
display public-key local | 顯示本地密鑰對的公鑰部分 |
display public-key peer | 顯示保存在本地的遠端公鑰信息 |
display ssh server-info | 在SSH客戶端顯示客戶端保存的服務器端的主機公鑰和服務器的對應關係 |
debugging ssh client | 打開SSH客戶端的調試信息開關 |
Copyright ©2008 杭州華三通信技術有限公司 版權所有,保留一切權利。
非經本公司書麵許可,任何單位和個人不得擅自摘抄、複製本文檔內容的部分或全部,並不得以任何形式傳播。
本文檔中的信息可能變動,恕不另行通知。