Yes OpenSSH's fingerprint is a hash of the publickey, and (except SSHv1 keys aka -t RSA1 which is long broken and should never be used) specifically of the publickey format stored in base64 in (usually) /etc/ssh/ssh_host_${alg}_key.pub which is the wire encoding in the relevant KEX-reply message depending on key type (currently RSA, DSA, ECDSA, ED25519). See https://superuser.com/questions/421997/what-is-a-ssh-key-fingerprint-and-how-is-it-generated
Traditionally this hash has been MD5, and displayed in hex with colons between each byte. OpenSSH recently (6.8 in March 2015) switched to SHA256, displayed in base64, by default; you can get the old one with FingerprintHash option on client, or -E option on ssh-keygen -l; see the man pages for ssh_config and ssh-keygen if you have a recent version, or see online http://www.openssh.com/manual.html for the latest version.
OpenSSH also supports displaying this hash (now either SHA256 or MD5) in an ASCII-art form that is supposedly easier to compare visually. IME this is rarely used. But then IME users rarely verify the fingerprint at all.
Yes, if a MitM can intercept your first connection to an SSH server AND feed you a wrong fingerprint you are pwned. The most conservative advice is you should get the fingerprint from an admin or other 'reliable' person face-to-face, or over the phone if you know their voice well enough to distinguish from an imposter, or other out-of-band secure means like registered mail. But in today's world, especially when dealing with lots of systems and many of them far away or in the cloud, this is often impractical.
If the fingerprint is on an HTTPS website (with certificate, ciphersuites and protocol version up to current standards) -- and the website itself isn't hacked (which has been known to happen) -- that's usually good enough.
But SSH clients are supposed to, and OpenSSH in particular does, remember the previously seen publickey (the whole key, not just the fingerprint) for each server, so if you get the first connection securely and MitM intercepts a subsequent connection it detects the discrepancy and gives you a big ugly error message with lots of uppercase and atsigns about 'WARNING! REMOTE HOST IDENTIFICATION HAS CHANGED! Someone could be eavesdropping on you!'.
However, if the server legitimately replaces its key(s), as they sometimes must or otherwise do, you get this same alarm, so as with all alarms that are often false, most people soon ignore them, or set the option (StrictHostKeyChecking no) to suppress them -- and advise others to do the same.
Also, if the client 'loses' its memory (for OpenSSH in the file ~/.ssh/known_hosts), you are back to the vulnerable initial connection state. For example your PC became obsolete or just unfashionable and was replaced and you didn't copy this file, or it was lost or destroyed (or stolen) and replaced, or the filesystem or disk was accidentally overwritten or corrupted and your data lost, or you just decided to delete it.
