Physical Network Topology
Figure 1-1 Network where the management network port cannot be accessed through SSH
Fault Description
Users want to log in to the device in a secure manner. Because Telnet lacks a secure authentication method, users can log in to the device through STelnet. As shown in Figure 1, the device functions as an SSH server and is reachable to the terminal PC. 10.137.217.203 is the management interface IP address of the SSH server. On the SSH server, configure one login user as the client. The PC uses the client user to log in to the SSH server through RSA authentication.
"RSA host key changed" error when accessing SSH server on client:
dz196-slot2:~/openssh-6.1p1 # ssh -l
ssh 10.137.217.203
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
a0:13:8a:32:fb:71:94:10:18:89:27:96:9d:a6:7c:5f.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hoststo get rid of this message.
Offending RSA key in /root/.ssh/known_hosts:5
RSA host key for 10.137.217.203 has changed and you have requested strict
checking.
Configuration Files
l CE12800
#
sysname SSH Server
#
rsa peer-public-key rsakey001
public-key-code begin
30820108
02820101
00DD8904 1A5E30AA 976F384B 5DB366A7 048C0E79 06EC6B08
8BB9567D 75914B5B
4EA7B2E5 1938D118 4B863A38 BA7E0F0D BE5C5AE4 CA55B192
B531AC48 B07D21E3
62E3F2A5 8C04C443 CF51CF51 136B5B9E 812AB1B7 1250EB24
A4AE5083 A1DB18EC
E2395C9B B806E8F0 0BE24FB5 16958784 403B617F 8AAAB1F8
C6DE8C3C F09E4D23
7D1C17BF 4AAF09C4 74C083AF 17CD3075 3396B322 32C57FF0
B1991971 02F1033B
81AA6D47 44520F23 685FAF72 04BA4B6E 615EF224 14E64E2A
331EEB7F 188D9805
96DBFD30 0C947A5A BA879DC4 F848B769 513C35CD B52B2917
02B77693 F79910EE
5287F252 977F985E 5F186C94 93F26780 4E7F5F9D 5287350A
0A4F4988 1BF6AB7C
1B
0201
25
public-key-code end
peer-public-key end
#
aaa
local-user client001 password irreversible-cipher
$1a$v!=.5/:(q-$xL=\K+if"'S}>k7vGP5$_ox0B@ys7.'DBHL~3*aN$
local-user client001 service-type ssh
local-user client001 level 3
#
stelnet ipv4 server enable
stelnet ipv6 server enable
ssh user client001
ssh user client001 authentication-type password
ssh user client001 service-type stelnet
ssh user client002
ssh user client002 authentication-type rsa
ssh user client002 assign rsa-key rsakey001
ssh user client002 service-type stelnet
#
user-interface vty 0 4
authentication-mode aaa
user privilege level 3
protocol inbound ssh
#
return
1.1.2 Troubleshooting Location
Troubleshooting Procedure
When handling this kind of cases, we can trouble this like follows:
l Query case by error code
Figure 1-2 train of thought
l Check according to normal positioning ideas
Figure 1-3 train of thought
Step 1 Check on the client side whether the link is ok.
< HUAWEI > ping 10.137.217.203
Step 2 Check the service status on the SSH server.
Preparation:Log in to the device using telnet or console.
Check the ssh service status to confirm that the following information is correct:
(1) The version number of the SSH protocol (1.99 supports both v1 and v2);
(2) Is the Stelnet service enabled?
(3) Whether the service port is modified;
(4) Whether to bind source ip address.
Step 3 Check whether there are free channels on the SSH server.
Preparation: Log in to the device using telnet or console.
(1) Check the user-interface configuration and confirm that you can log in to the ssh VTY channel. VTY channels that can be SSHed must satisfy two conditions: 1) bind the ssh protocol, and 2) use the aaa authentication mode.
The following VTY0, VTY1, and VTY2 can be ssh login.
[hauwei]user-interface vty 0 4
[huawei-ui-vty0-4]dis this
#
user-interface con 0
user-interface aux 0
user-interface vty 0 2
authentication-mode aaa
user privilege level 15
protocol inbound all
user-interface vty 3 4
authentication-mode aaa
user privilege level 15
protocol inbound telnet
user-interface vty 16 20
#
(2) Check user online status.
The users of VTY0, VTY1, and VTY2 are already online. Therefore, SSH users cannot log in.
<huawei> display users
User-Intf Delay Type
Network Address AuthenStatus
AuthorcmdFlag
34 VTY 0 00:04:11 TEL
10.137.211.108
no Username : Unspecified
+35 VTY 1 00:00:00 TEL
10.137.211.108
no Username : Unspecifie
36 VTY 2 00:37:19 TEL
10.135.41.122
no Username : Unspecified
37 VTY 3 00:31:06 TEL
10.135.32.199
no
Username : Unspecified
38 VTY 4 02:14:06 TEL
10.135.22.124
no Username : Unspecified
Step 4 Check whether the SSH user configuration is normal on the SSH server.
Preparation: Log in to the device using telnet or console.
l Check the ssh user's configuration and confirm the following information:
l Is there an SSH user configuration for the login account and the configuration is complete?
l If the login account does not use the ssh user configuration, the ssh authentication-type default password configuration exists.
<huawei> display
current-configuration | inc ssh
ssh authentication-type default password
ssh user client001
ssh user client001 authentication-type password
ssh user client001 service-type all
Note: The account used for ssh login must use the "ssh user" command to configure the attributes. If you do not configure (such as using a Tacacs account), you must configure "ssh authentication-type default password". Otherwise, the account cannot be used.
Step 5 Check on the server side for ACL filtering.
Preparation: Log in to the device using telnet or console.
(1) Check the user-interface configuration to confirm that there is an ACL binding.
[hauwei]user-interface vty 0 4
[huawei-ui-vty0-4]dis this
#
user-interface con 0
user-interface aux 0
user-interface vty 0 4
acl 3999
inbound
<--band ACL 3999
authentication-mode aaa
user privilege level 15
protocol inbound all
user-interface vty 16 20
#
(2) Check the ACL configuration to confirm whether the client ip can pass.
[huawei]acl 3999
[huawei-acl-adv-3999]dis this
#
acl number 3999
rule 1 permit tcp source 2.2.2.2 0 0
rule 2 permit tcp source 3.3.3.3 0 0
rule 3 permit tcp source 4.4.4.4 0 0
rule 4 permit tcp source 5.5.5.5 0 0
rule 15 deny ip
#
Note: The VPN IP address must be specified in the ACL rule.
#
acl number 2222
rule permit source 219.133.0.3 0 vpn-instance
vrf3-JD ß The ACL rule requires VPN configuration.
#
Step 6 Check the link for problems.
Method one: Use the debug command
Preparation: Log in to the device using telnet or console.
(1) On the server side Stelnet itself, confirm whether the connection can be established normally.
The following connection can be normal, indicating that the SSH service is normal and there is a problem with the link.
[huawei]ssh client first-time
enable <-- Confirm the configuration of ssh client
first-time enable before Stelnet
[huawei]stelnet 10.137.131.164 <--
Stelnet itself, pay attention to whether the ACL can pass.
Please input the username:ssh
Trying 10.137.131.164 ...
Press CTRL+K to abort
Connected to 10.137.131.164 ...
Enter
password:
<-- connection succeeded
Info: The max number of VTY users is 20, and the number
of current VTY users on line is 7.
The current login time is 2013-12-16 03:44+00:00.
<164>
(2) Open the following debugging switch on the server side.
< HUAWEI >debugging tcp
packet dest-port 22
Info: Filter added!
< HUAWEI >debugging tcp packet src-port 22
Info: Filter added!
< HUAWEI >t m
Info: Current terminal monitor is on.
< HUAWEI >t d
Info: Current terminal debugging is on.
(3) Connect the remote Stelnet once again to analyze the output of the server-side debugging information.If the following debug information (SYN output 3 times) appears, it proves that the TCP connection cannot be established.
Sep 10 2013 09:49:50.650.1+01:01 181
SOCKET/7/TCP PACKET:
TCP debug packet information:
1378806590: Output: task = VT3 (215), socketid = 1,
(State:Syn_Sent,src = 10.137.131.181:54600,dst = 10.137.131.162:22,VrfIndex =
0,seq = 2916144432,
ack = 0,datalen = 0,optlen = 4,flag = SYN,window = 8192,ttl = 255,tos = 192,MSS = 512)
Sep 10 2013 09:49:56.240.1+01:01 181 SOCKET/7/TCP PACKET:
TCP debug packet information:
1378806596: Output: task = VT3 (215), socketid = 1,
(State:Syn_Sent,src = 10.137.131.181:54600,dst = 10.137.131.162:22,VrfIndex =
0,seq = 2916144432,
ack = 0,datalen = 0,optlen = 4,flag = SYN,window = 8192,ttl = 255,tos = 192,MSS = 512)
Sep 10 2013 09:50:20.240.1+01:01 181 SOCKET/7/TCP PACKET:
TCP debug packet information:
1378806620: Output: task = VT3 (215), socketid = 1,
(State:Syn_Sent,src = 10.137.131.181:54600,dst = 10.137.131.162:22,VrfIndex =
0,seq = 2916144432,
ack = 0,datalen = 0,optlen = 4,flag = SYN,window = 8192,ttl = 255,tos = 192,MSS = 512)
Method 2: The client confirms the packet capture.
The packet capture analysis on the client side is as follows:
(1) TCP establishes a connection normally.
(2) No response to the TCP connection request.
(3) The TCP connection request was rejected.
Root Cause
The client does not access the SSH server for the first time. It has previously accessed the SSH server of the server. However, on the SSH server device, the RSA key has changed, but the old RSA key is still on the client and the old secret is still used. The key is to access the server, resulting in unsuccessful access.
