Hot answers tagged

59

The simplest solution is: rm -f .ssh/known_hosts ssh will recreate the file again, but you lose key checking for other hosts! Or, you can use: ssh-keygen -R "hostname" Or the ssh "man-in-the-middle" message should indicate which line of the known_hosts file has the offending fingerprint. Edit the file, jump to that line and delete it.


53

sed -i '6d' ~/.ssh/known_hosts Will modify the file ~/.ssh/known_hosts:6 , removing the 6th line. In my opinion, using ssh-keygen -R is a better solution for an openssh power user, while your regular Linux admin would do better to keep his/her sed skills fresh by using the above method.


38

There is an ssh-keygen switch (-R) for this. man ssh-keygen reads: -R hostname Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option above).


10

The warning will tell you the exact line in the known hosts file. Here's an example: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The RSA host key for foo-bar.net has changed, and the key for the corresponding IP address ...


6

Heartbleed does not require a man-in-the-middle attack to compromise a system. In fact, you don't even have to be connected to the vulnerable site for your personal information to be compromised. The heartbleed defect in OpenSSL allows an attacker to read bits of information stored in memory on the vulnerable system. Reading heartbleed.com should answer ...


5

There is no way to detect an arbitrary MITM, because there are several techniques to perform them. However, most MITM attacks on Ethernet or WLAN use ARP spoofing to redirect traffic. There are tools to detect ARP spoofing, these should indicate most MITM attacks. See e.g. the Wikipedia page for some tools.


5

discover you're being sniffed This is exactly what SSH protects against. As long as you carefully verify the host key, it doesn't matter if someone is reading your traffic: it's all encrypted. disconnecting before any sensitive information is disclosed Again, standard SSH will be fine. Host key checking is one of the first things done when ...


5

You can also instruct ssh to not check the known_hosts file using the UserKnownHostsFile and StrictHostKeyChecking flags. For instance: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@example.com For ease of use you can alias this: alias boldssh='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no' Now you can just ...


4

Here is a great answer by Bruce Schneier, from which I quote: Should you not use SSL until it's fixed, and only pay for internet purchases over the phone? Should you download some kind of protection? Should you take some other remedial action? What? If you read the IT press regularly, you'll see this sort of question again and again. ...


4

Short answer: You can 1) wait, 2) avoid connections to important servers on public access points. First of all, don't get overly scared. Remain calm, and listen to the followup episodes which will surely deal with fixing or circumventing the problem. As far as I understand, what the described attack makes possible is creating a single TLS (aka SSL) secured ...


4

Found the answer myself in case anyone is interested (source is blogs.telerik.com) WebSockets Fiddler’s HTML5 WebSockets support continues to grow; Fiddler extensions can now capture and manipulate WebSocket messages by handling the FiddlerApplication.OnWebSocketMessage event. In preparation for a full-featured WebSockets UI, Fiddler no longer spews ...


4

You can't stop a MITM attack without physically disconnecting the computer/person/software performing the MITM (have you tried kicking 'em where it hurts?). What you can do is make an end-to-end connection to a remote host tamper-evident, meaning, you would be able to know if either (a) your brother is listening in, or (b) modifying the contents of the ...


3

SSL uses two keys, a private and a public one. Only the public key is sent and this key has no value unless you know the private one. Every party is encrypting the data it sends with the public key of the other one (that's a little bit more complex but you got the idea). Only the recipient is able to (easily) decode the traffic. That means that traffic ...


3

You, sir, have malware installed on your client computer. This software likely "listens" to the common browser processes (i.e. IE and FF) and intercepts HTTP traffic, appending "frtree...com" to it. Hard to say exactly what it is or how it got there, but one thing is clear: you need to find a virus scanner that will remove it, or roll your OS. Edit: it's ...


2

You can also remove a single line from known hosts with e.g. rmknownhost 111 (111 is the line to remove): #! /usr/bin/env ruby line = ARGV[0] || raise("gimme line to remove") hosts = File.expand_path("~/.ssh/known_hosts") content = File.readlines(hosts) removed = content.delete_at line.to_i - 1 puts "Removed:\n#{removed}" File.open(hosts, 'w'){|f| f.write ...


2

Is it possible your router has been compromised by a virus and is redirecting traffic?


2

Any unencrypted traffic will be at risk. You can use TLS/SSL enabled protocols to prevent passwords from passing in the clear. Depending on your email software you can use IMAPS and SMTPS to secure your traffic, or STARTTLS on IMAP and SMTP to prevent passwords from traveling in the clear. SFTP can be used for file transfers. Internet traffic passing in ...


2

It doesn't screw up the headers; you haven't told the OS/browser to use a proxy server, you're telling the OS that the actual server is at 127.0.0.1, so you're receiving the SSL/TLS handshake.


1

First thing's first: DO NOT DO THE FOLLOWING IF YOU DO NOT TRUST THE CERTIFICATE ISSUER Doing this a man-in-the-middle to see all of your communications. This fix should only be employed if you are in a situation which warrants it, not if you're sitting at a coffee shop and having problems connecting to things. That said... The first step is to acquire ...


1

There's no fail-proof way of detecting this (if there was, MitM attacks wouldn't be a problem!). There're a few possible techniques, though. You could try looking at the times it takes to serve something; a delay might indicate a MitM attack occurring. Or it could just indicate the network is being slow. If you think someone is editing the content of ...


1

MiM attacks are done against encrypted traffic (You don't have to do MiM in non encrypted traffic, you can just sniff it). There is some math behind it but long story short: you have to check key finger print. So for example when you login via ssh first time ssh client displays the servers fingerprint. If you want to protect against MiM you mast know this ...


1

I encountered the exact same problem with Charles Proxy in combination with Wireshark. I think the issue is that Charles sends two (or more) certificates to the client (check the Certificate message sent from proxy to the client). Wireshark will then use the first certificate in that list, which probably will not match the private key you generated. (This ...


1

There is a UPNP vulnerability that is being exploited in the wild in a way that causes the authorization popup. Disable UPNP on your router and power cycle it. Then google for "upnp vulnerability" for more info than I could provide.


1

IMHO you shouldn't be able to route the traffic of your Mac to a VM (Host-only Adapters) on this Mac, which relies on this Mac to route (NAT-Adapter) the whole traffic to the internet. Solutions Set up a MacOS X VM with the Android SDK (probably), configure a Host-only Adapter and use the Tapioca VM as proxy/router for the MacOS X VM Set up a 2nd Mac ...


1

if (oSession.url.Contains("search_query=dolphin")) { oSession.url = oSession.url.Replace("search_query=dolphin","search_query="); }


1

The HTTPS/SSL protocol uses Private/Public Keys to ensure a secure connection. http://en.wikipedia.org/wiki/Transport_Layer_Security


1

As long as the line is not secure there is not much you can do that can save you from MITM (Man in the Middle) and arp poisoning.


1

arpwatch works for me: sudo aptitude install arpwatch echo "wlan3 -a -n 10.10.0.0/24 -m me@gmail.com" | sudo tee -a /etc/arpwatch.conf /etc/init.d/arpwatch start Like you said, it would be nice to automate the defense. http://ifttt.com looks like it would help with sending SMS alerts, etc. The rest is up to you and your MTA (postfix) and e-mail filters.


1

Don't listen to people who try to scare you! This certainly is not worth changing operating system over. Just use your internet like normal with your usual DNS provider and don't worry so much. Man in the middle attacks require... a man in the middle and on a standard network, this just doesn't really happen. If you use Wireless, make sure you are using ...



Only top voted, non community-wiki answers of a minimum length are eligible