Getting the Most Out of SSH

jfruh writes "If you have to administer a *nix computer remotely, you hopefully ditched Telnet for SSH years ago. But you might not know that this tool does a lot more than offer you a secured command line. Here are some tips and tricks that'll help you do everything from detect man-in-the-middle attacks (how are you supposed to know if you should accept a new hosts public key, anyway?) to evading restrictions on Web surfing." What are your own favorite tricks for using SSH?

Comments

InfoWorld at it again

[MasterMan]

Seriously, anyone who uses SSH knows about things like proxying your connection via the connection and X11 forwarding. This is nothing new. This is just InfoWorld getting backlinks and traffic from Slashdot once again. Hell, I knew about these things when I was 16 and so did every other guy I knew who ever had used SSH.

Re:InfoWorld at it again

[buchner.johannes]

My favorite trick is
1) have a server on the internet, let someone ssh -R their port 22 there
2) connect to that server too with ssh -L putting their port 22 on the local port 8022
3) Now you have a peer-to-peer ssh (with -Y), and you can run graphical applications remotely.

Re:InfoWorld at it again

[Anrego]

Indeed. And that was the closest thing to an "ultimate hack". Everything else was basic intro to Linux type stuff.

That and the randomart stuff was very poorly explained. Personally I think that feature is pointless anyway. If you are in a position where you feel you might actually get a MiM attack.. copy the key onto a USB stick.

Re:InfoWorld at it again

[Dwedit]

It does matter though. Didn't use screen? Lost a connection? Your processes are terminated. Linux sucks in that regard, you need to know about the hangup "feature" that immediately kills your processes when the terminal dies.

Re:InfoWorld at it again

[tangent3]

That's what nohup is for

Re:InfoWorld at it again

[jellomizer]

Well to be fair not everyone had SSH when they were 16 years old...

I was 16 once, and I would try to figure out how to do all the cool new trick that my new systems has... As we get older we get in a groove (mostly due to the fact that we are paid to do a particular job, and if we spend too much time finding something new and cool would prevent us from getting things done by are estimated time)

And after 8+ hour of work when we get home the last thing we want to do is more work.

Re:InfoWorld at it again

[GameboyRMH]

Yep I shoulda looked before I clicked...nothing non-obvious here folks, move along.

Here's an actual handy tip: You can make your RSA keyfiles also act as shellscripts for the connection, so you only need to carry 1 file to open the connection from any *nix machine.

To do it, just prefix your keyfile (say it's called ssh_my_server) like this:

#! /bin/sh
ssh user@hostname -i ssh_my_server
exit

----------BEGIN RSA PRIVATE KEY--------
(key goes here, use 4096-bit key for extra l33tness)

Make the file executable and now you can open the connection just by cd'ing to it and running it.

Re:InfoWorld at it again

[syzler]

I generally prefer the apps on my desktop rather than the remote apps. "ssh -D 8080 " will start a SOCKS4/SOCKS5 server running on your local port 8080 and proxy the connections out the remote side. This allows all of your SOCKS enabled applications on your local workstation to make use of the tunnel without having to setup a one to one port mapping.

Re:InfoWorld at it again

[MasterMan]

It does matter though. Didn't use screen? Lost a connection? Your processes are terminated. Linux sucks in that regard, you need to know about the hangup "feature" that immediately kills your processes when the terminal dies.

Yes, but this isn't even explained in the article!

Re:InfoWorld at it again

[Albanach]

Hell, I knew about these things when I was 16 and so did every other guy I knew who ever had used SSH.

To be fair, I'm sure there are sixteen year olds reading /.

I don't expect every article to be useful to me. Not sure why you would expect that.

I haven't read the article - I think I'm familar enough myself with ssh - but as long as the info is accurate, I'd image it's a useful tutorial for folk getting into Linux.

Re:InfoWorld at it again

[icebraining]

Using sshuttle, the applications don't even need to support SOCKS; it proxies all traffic over SSH.

Re:InfoWorld at it again

[nschubach]

In my opinion, I think it might be a better idea to kill the errant job if the controller/user gets disconnected than to continue with a job that may need a followup command that may never come, possibly leaving the server in an unusable state. So you have a choice of trusting the user or having the user say explicitly, "trust me, this is what I want to happen (screen/nohup)... even if I get disconnected."

Re:InfoWorld at it again

[marcosdumay]

The GP is certainly asking for a default screen session evey time he does SSH, emulating what he gets on Windows.

Oh, well, most people prefer the option of choosing what session to use when they connect, thus things don't get linked the way he wants, but it is easy enough to set ssh to execute "screen -r" when one connects... The GP needs only to RTFM (the first line of it).

Re:InfoWorld at it again

[hcs_$reboot]

To be honest I don't know, but these man pages show
PermitRootLogin
Specifies whether root can log in using ssh(1). The argument must be "yes", "without-password", "forced-commands-only" or "no". The default is "yes".

Re:InfoWorld at it again

[Anrego]

Problem is the article is all over the place. It lists basic "intro to linux 101" stuff right next to "security paranoid enterprise server admin" stuff (which is does a very bad job of explaining anyway).

There are plenty of good "intro to SSH" articles and plenty of good "advanced SSH tricks" articles out there. This is just trash.

Re:InfoWorld at it again

[Sancho]

On the sshd_config which ships with FreeBSD has this disabled.

Re:InfoWorld at it again

[miknix]

What about unlimited encrypted storage?

you need TCP forwarding enabled in your sshd_config, then

ssh -L localhost:2222:localhost:2222 localhost
$ echo "data you wanna save" | nc localhost 2222

# or if you want to backup your hdd, try:
$ cat /dev/sda1 | nc localhost 2222

# the data will be forwarded forever in the loopback link at no cost until you read it back:
$ nc localhost 2222 > hdd-backup.bin

# profit!

Re:InfoWorld at it again

[dylan_-]

My mistake, then. I'd heard they'd gone the same route as OS X (incorrectly, it appears). Apologies to all.

Nope, you heard correctly. The bit you're mistaken about is that OS X also has a root user. In both cases, the account is "locked" (no matchable password is set). Set a password for the root user and it works as normal.

Re:InfoWorld at it again

[DarwinSurvivor]

tsocks can be used to add SOCKS support to anything.

Re:InfoWorld at it again

[Elrond, Duke of URL]

Even better is the screen/tmux wrapper called byobu (https://launchpad.net/byobu). It puts a nice face on screen (and now also tmux) and greatly simplifies basic usage. It also has a large selection of status notifications that can be displayed on the bottom one or two lines of your terminal which show things like the current screens, load, time, etc.

The default key mapping uses the function keys for the most common commands. For example, F2 for a new window, F3/F4 for previous/next window, and so on. It provides a wrapper around the session handling as well, so that, in general, you can almost always just run "byobu" and get your session back or start a new one if there is none existing. And if it finds that you have more than one session running, it will ask you which one to connect to.

In the configuration menu (F9), the last item allows you to toggle auto-launching at login. Select it and it will add a line to the end of your shell's profile file to start byobu when you login.

Development has been proceeding at a very rapid pace over the past year and the feature set it quite nice. Recently, the default backend was switched from screen to tmux, but because byobu is a wrapper on top of those programs, I didn't need to learn a new set of keys... though it did help to read up on tmux to see what it could/couldn't do as compared to screen. For the most part, the change was transparent, though tmux only does one status line at the bottom of the terminal versus the two that you had with screen. One of the nicest changes is that tmux can determine what command you are executing in a window and it shows this in place of a window's generic title in the status line. Screen could do this too, but you had to jump though some hoops, change your shell prompt, and it didn't always work.

Anyway, with the additions byobu brings to screen/tmux, I always have it running which has the added benefit that in the (these days, not very likely) event of SSH dropping my connection, nothing is lost. I usually use it in local terminals too, so if X or my terminal ever crashes for some odd reason, I'm saved there, too.

Re:InfoWorld at it again

[semi-extrinsic]

Personal favourite: If you have machines on a LAN that are only exposed to that LAN, but there is one "gateway" machine that you can ssh to from the internet: use ProxyCommand, and you can ssh "directly" to the machines on the LAN even from the internet! Put the following in your .ssh/config:

Host gate1
Hostname 128.141.81.163
User joe

Host local12
Hostname 192.168.1.12
User joe
ProxyCommand ssh -e none gate1 exec netcat -w 5 %h %p

You can now ssh to "local12" just by typing "ssh local12", whether you are on the LAN or not.

Hopefully?

[Enry]

If you're still using telnet to administer anything that offers SSH, you should probably choose another field to work in.

Re:Hopefully?

[hcs_$reboot]

well I occasionally use 'telnet host 25' to test the smtp port

Re:Hopefully?

[buchner.johannes]

Telnet has a protocol. Look at socat and netcat. Socat supports ssl, you can check your smtps server port.

Re:Hopefully?

[CubicleZombie]

I've worked in organizations where, because you can tunnel over SSH, it was banned and blocked over the network. Everything had to be done with Telnet instead. I'm not joking. That is probably what started my loathing of net admins.

Re:Hopefully?

[hcs_$reboot]

So, when I want to check if the port 25 is not blocked (firewall at ISP...) and is opened, instead of a simple 'telnet host 25' followed by ^D or ^C, I should write a C++ (may I use C for that, please?) program that does the same thing? You do know that some people already wrote some commands for that, right?

Re:Hopefully?

[Junta]

When I see someone testing port 25 or 80, it's usually nothing more than a liveness test. Not worth the overhead of writing a program to open a socket and read and write data. perl/python is a tad more accessible, but still for a once in a blue moon use is generally more trouble than it's worth.

Re:Hopefully?

[lcam]

There may be reasons to use telnet over SSH. Challenge the assumption that it's always better to encrypt communications rather then let someone listen in.

That being said, your presumption is normally right; ISP administrators who block SSH and only allow file transfer by FTP fall into the same category. They should be fired.

Re:Hopefully?

[Anonymous Coward]

MasterMan (2603851) - You do know that you can use real programming language like C++ for that, right?

C++ programmers are truly masters of the universe. I salute you sir for taking hours and object oriented wizardry to do what most programmers would do in 5 mins with a short script.

Re:Hopefully?

[Galactic Dominator]

Telnet isn't, it only works "by accident" because the protocol is similar enough to plain text to work sometimes.

Bullshit. It was designed that way. And I can prove it, unlike your assertion.

http://tools.ietf.org/html/rfc15

Re:Hopefully?

[kwark]

smtps was deprecated years ago (not that I agree). You should use:
openssl s_client -starttls smtp -connect host:(25|587)
Something socat doesn't appear to support (that's a first).

Re:Hopefully?

[bzipitidoo]

And in 2002, when I was contracting for the government, I needed some data that was stored on a government server. They set up a user account for me and rather than email the password to me, called to tell it to me over the phone, because they felt that was more secure than email.

The joke was that I was to connect via telnet. They didn't have ssh on that server. They didn't even have some kind of secure telnet that would at least try to encrypt the password. Just plain old telnet, with the password transmitted in the clear.

Re:Hopefully?

[steveb3210]

Telnet is wide open to a MITM attack - besides just sniffing the password, suppose you have a shell open - then a MITM hijacking your TCP session could write an arbitrary rlogin file.

My professor for the computer security class at my college demoed this exact scenario - its not a safe protocol.

Re:Hopefully?

[sydneyfong]

Emails are cached in a lot of intermediate servers and stuff. The logs are routinely backed up. Undelivered emails get forwarded to all sorts of addresses and admins. Even if nobody was maliciously scooping on you, the passwords could land on some random person's hands.

It *is* more secure over the phone in that sense.

And it's not a common practice to log down telnet traffic. Anyone who gets your telnet password is probably sniffing maliciously.

Not to say it's a sane policy to use telnet, but there are these differences in "levels" of safety (both levels are of course very very low). To a security conscious person it may be equivalent, but practically you have less chance a random John Doe will get your password this way. Maybe it matters, don't ask me....

Re:Hopefully?

[slimjim8094]

Not bullshit. A telnet client works best with a telnet server; while you can use it against other servers, it is not ideal. The client interprets certain byte sequences as commands.

Furthermore, I quote the wiki:

a Telnet client application may also be used to establish an interactive raw TCP session, and it is commonly believed that such session which does not use the IAC (\377 character, or 255 in decimal) is functionally identical. This is not the case, however, because there are other network virtual terminal (NVT) rules, such as the requirement for a bare carriage return character (CR, ASCII 13) to be followed by a NULL (ASCII 0) character, that distinguish the telnet protocol from raw TCP sessions.

The wiki lacks citations; I point you to RFC 854 (bottom of page 11).

Thus, the protocol is not plain text. It is very close, close enough that most things should work fine, but if you actually desire the ability to deal with raw TCP streams, you'd be much better off using a tool designed for it. Such as socat or netcat.

The protocol was designed to provide remote access similar to a terminal. As such, it includes escape characters and other terminal-control mechanisms. It was not designed to pass text exactly as entered, or display it exactly as sent. Given the common existence of tools that are, it seems like a poor choice to use the inferior one.

Re:Hopefully?

[Tassach]

Sounds like a case of throwing out the baby with the bathwater, but in a really secure environment, SSH *is* a huge can of worms, especially when combined with Corkscrew.

I once worked for a large company with a draconian firewall policy and no remote access solution. SSH connections were forbidden in both directions. So, I came up with a ssh reverse tunnel solution.

On a box inside the firewall, run this script as a daemon:

#!/bin/bash
while true
do
        nohup ssh -O ProxyCommand=/usr/local/bin/corkscrew \
                  -O TCPKeepAlive=1 \
                -R 2222:localhost:22 homeuser@homebox
done

This creates a persistent, automatically-restarting outbound ssh tunnel, inside a HTTP tunnel. For added obfuscation, I could run sshd on port 443 on homebox.

Now, (assuming proper corkscrew config), when I'm on homebox I can run:

ssh -p 2222 workuser@localhost

By running squid on homebox:3128 and modifying the corkscrewed connection with -L 3128:homebox:3128, When I'm at work I can set my browser's proxy settings to localhost:3218 and browse anonymously, incidentally bypassing their content filter.

SSH Tunnel

[slashgrim]

SSH Tunneling by far: http://www.debian-administration.org/article/38/Tunneling_connections_securely_with_SSH

Re:SSH Tunnel

[Ruzty]

Traffic pattern matching over SSL. A web session over an SSL connection looks very different than an ssh tunnel session over SSL, not to mention the length of life of the socket. It's trivial to have the firewall identify the ssh connection over port 443 and disconnect it in the first few seconds of the session based purely on the pattern of the traffic regardless of content.

Re:SSh tunnel

[manoweb]

But a PPP over SSH gives you a complete VPN, not only a bunch or redirected ports.

Re:SSh tunnel

[wertarbyte]

plus the problems of layering multiple TCP layers above each other. Also, PPP is not needed anymore: ssh can establish VPN connections using tun devices quite fine ("-w")

Re:SSH Tunnel

[hawkinspeter]

I didn't know this was feasible. How would I do that in a Cisco ASA firewall?

How's that again?

[93 Escort Wagon]

(how are you supposed to know if you should accept a new hosts public key, anyway?)

Seriously? If you don't know enough about what's going on with the machine at the other end to make that decision... that's the whole bloody point of the warning!

Most wanted feature which SSH lacks?

[garo5]

I'd always have liked that I could transfer a file or an stdout/stdin stream directly in the middle of an open ssh session. Also the file transfer / stream should be carried over nested ssh connections.
Imagine that you could just pipe the output from a command into some magical ssh command in a remote machine and your ssh client would ask where you would like to pipe the stream in your local machine.

Re:Most wanted feature which SSH lacks?

[allo]

this is possible.

first thing to look into:
[enter]~?
the ssh escape-key is ~, but only after a newline. and look out for deadkeys. ~? is a short help on this. There you can manage sub-connections and other stuff.
~. is very useful for terminating a ssh-process, which is still waiting for a network timeout.

And multiplexing a single ssh-connection: read the manpage of ssh for "ControlMaster". then a unix-socket which contains username and hostname in the filename is used to use a single ssh-connection for multiple streams (shells, transfers, etc.)

Wow

[frodo from middle ea]

Wow, ssh tunneling, and a few command line options , and screen, that's your ultimate SSH guide ?
I am impressed, not!

How about
- ssh master connection, for svn+ssh ?
- ssh agent forwarding
- opening ssh ports using knocking
- auto blacklisting with something like sshblack

I think the above are more advanced options than the ones mentioned in the article, no ?

Re:Wow

[mlts]

I'd love to see stuff like that as well as:

OpenSSH signed certificates (Not X.509) and TrustedUserCAKeys options and their usage. This way, I can hand a new cow-orker signed ssh host keys and assuming he or she knows enough not to just blindly replace a key if it isn't right, will minimize the chance of a MITM attack.

Revoking SSH keys.

Using SSHGuard to lock out brute force attempts.

Proper configuration of the sshd_config file. Stuff like only allowing root in via RSA keys (or blocking root access entirely.)

Auditing logs to know that key "A" ssh-ing to root is from user Alice, and key "B" is from Bob, so that one can tell who just wiped out the wrong filesystem come an inquiry.

Running sshd as a user, not as root.

Getting a backup program like NetBackup to form a ssh tunnel, do the backup, then close down the connection cleanly.

Really lame

[Anrego]

Tip 16 and friends (the keyart stuff) is very poorly explained. You don’t know that the key is secure, but you magically know that the randomart is? That’s the bit they forgot to mention. It’s a visual representation of the key that _you have to have seen before to be able to verify_. Personally if you are going to go to the trouble.. I say throw the key on a USB stick and be done with it.

The screen stuff maybe worth mentioning the more modern alternative tmux.

SSHFS is better than NFS

For quick one-off stuff .. maybe. Cryptographic overhead is still startlingly effective at slowing things down, even on fast hardware (random: can anyone explain why.. you’d think it shouldn’t make any difference at this point.. I’m guessing it has something to do with network framing?).

Tip 4 (logging in with server-specific keys ) seems like the kind of thing that very few people will ever need to do.. and if they do.. they’ll google it. Kinda silly putting it in an article like this.

Tip 2 (ssh tunnel) is probably the only thing in here that _might_ be considered an “ultimate” hack (everything else is pretty much Linux 101).

Tip 1 (Evading silly web restrictions) is great. Alternate title: “my job is important, but damnit I need my facebook/twitter fix”.

Re:Really lame

[Anonymous Coward]

Any clued network admin will eventually get wind of a ssh connection going to the same box from someone's workstation, especially if there is a lot of traffic going to and from it. Then, depending on how much they like/dislike the person with the tunnel, they will either ignore it, mention to be careful about PPP over SSH in passing, randomly kill the connection, block the destination IP at the router, block ssh from going outside from that workstation, or just sit there, watch statistics, then present HR with a case that a user is doing something they shouldn't by constantly sending encrypted traffic to a box that isn't owned by the company or anyone relevant. That right there is good enough to get someone sacked in most companies, especially ones with more paranoid and clueless PHBs.

Of course, one can ssh to a different port, but most IDS/IPS systems can detect a bunch of encrypted traffic over a TCP port and send a note to the admins, or just automatically lock the workstation out from the rest of the network.

So, the guide of using ssh as a tunnel is just plain stupid, and a good way to get fired for gross misconduct (which means no unemployment).

Re:Really lame

[Anonymous Coward]

I am the developper of libssh (www.libssh.org).
SSHFS is slow because it's a packet based TCP-encapsulated file transfer protocol. All requests are initiated by the client and somewhat replied to by the server in an asynchronous design, but in practice no sftp server really has an asynchronous implementation. Opening a file, querying its length and downloading 8KiB require at least 3 or 4 RTT.
Compare with NFS, UDP based and mostly kernel-land and fully asynchronous.
Crypto is the main overhead in libssh and I suspect in openssh too, mainly because the crypto libs used do not probe for AES extensions or accelerators by default. And last but not least, OpenSSH's Channel window handling (similar to TCP windows) is not optimal for bulk transfers at high speed.
There are also some remote filesystem features missing in SFTP, like server-send feedback, locks and friends.

Should have been titled "ssh basics".

[Anonymous Coward]

Also... screen? When there's tmux???

Re:Should have been titled "ssh basics".

[tscheez]

I'd never used tmux. i've officially learned more from /. comments than the actual articles. Thanks!

Connection Multiplexing

[igglepiggle]

Having multiple sessions over the same connection speeds up repeat connections: http://blogs.perl.org/users/smylers/2011/08/ssh-productivity-tips.html It's well worth setting up.

The MITM 'help' is worthless.

[Junta]

Basically they go into some detail about the ascii art representation, and at the end acknowledge that you need to securely get the keys to know what to expect. If you have a secure means of getting the ascii art, you have a secure means of getting the key. The only exception I can think of is if you have someone cell-phone picturing the local console, which could be helpful.

The real useful thing would be for people to do DNSSEC and SSHFP records.

My fav

[Anonymous Coward]

Rather than more complaining, I thought I'd say my favorite option. I like using the ~/.ssh/config file and the use of a master connection. In mine, I have:

host *
  controlmaster auth
  controlpath ~/.ssh/ssh-%r@%h:%p
  controlpersist yes

This creates a master socket on my client. When I first connect, I need to use my passphrase. But when I exit, the SSH tunnel stays up. Futher connections via SSH and sftp and scp use this connection, multiplexed. So no more asking from my passphrase. When I'm finished for the day, I close down the connection with

ssh -O exit host

replacing "host"

Re:My fav

[Barnoid]

one of my favorites, too. small correction for those who actually try it out: it should be controlmaster auto, not auth.

~/.ssh/config

host *
  controlmaster auto
  controlpath ~/.ssh/ssh-%r@%h:%p
  controlpersist yes

This creates a master socket on my client. When I first connect, I need to use my passphrase. But when I exit, the SSH tunnel stays up. Futher connections via SSH and sftp and scp use this connection, multiplexed. So no more asking from my passphrase. When I'm finished for the day, I close down the connection with

ssh -O exit host

replacing "host"

Comment removed

[account_deleted]

Comment removed based on user account deletion

Comment removed

[account_deleted]

Comment removed based on user account deletion

SSH Feature Wish: Server policy on SSH keys

[linuxtelephony]

I wish it was possible to require SSH keys for some (or even all) users to have a passphrase, and enforce this requirement on the server.

As it stands right now, even if you generate a key for someone with a pass phrase, they can remove it easily on the client side and the server has no way of knowing. This means you could have passwordless logins to remote systems. Not good.

At least with modern systems and key agents you can get passwordless ease of use once you log into your local account, and if someone happens to get your private key they don't immediately have instant access to the machines you can log into. You should have a little time to secure the machines. [Think lost/stolen laptop or backup drive.]

Re:I hope the list of tricks

[Wee]

Thank heavens for Ghostery.

You misspelled "NoScript".

This Article's True Purpose

[preaction]

Get real SSH tips from people complaining (rightly or not) that it doesn't contain any actual advice.

Re:2600 article

[CubicleZombie]

Okay.

There might be a story about how to do something INSIGHTFUL in a magazine I borrowed from someone a few months back in some place somewhere.

Karma bonus, here I come...

Re:I hope the list of tricks

[jojoba_oil]

I stopped taking NoScript seriously when they thought it was a good idea to deliberately disable AdBlock and obfuscate the code that did so.

Please sit down and shut up.

[suso]

OP should be -1 overrated. You jerks who keep saying things like "everyone is doing X because I am" or "this isn't knew" or "this isn't important" really need to STFU. There are people coming into the world all the time who haven't learned what you learned or had the same experiences that you do. Much of what you learned from is burried now under mountains of information and its very often not clear where people should start from. So sit down, shut up and let others learn, otherwise all you will do is scare them away so that they never will. Not everything is some conspiracy to generate ad revenue.

Personally I like

[Rich]

tar cf - somedir | ssh remote@remotehost 'tar xf -'

A nice way to get things moved around. a similar trick is:

tar cf - somedir | (cd /a/local/path; tar xf - )

Which lets you copy things around a local file system.

Comment removed

[account_deleted]

Comment removed based on user account deletion

my #1 hack

[no-karma-no-worries]

man ssh

Re:SSHFP records in your DNS zone

[stderr_dk]

Let me demonstrate the difference with some examples.

First a normal ssh connection to a new host. Without VerifyHostKeyDNS it doesn't matter if your SSHFP records are up-to-date, since they won't be checked.

$ ssh login@example.com
The authenticity of host 'example.com (127.0.0.1)' can't be established.
RSA key fingerprint is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
Are you sure you want to continue connecting (yes/no)?

With "VerifyHostKeyDNS yes" and up-to-date SSHFP records, it looks like this instead. Note the extra line of output.

$ ssh -o "VerifyHostKeyDNS yes" login@example.com
The authenticity of host 'example.com (127.0.0.1)' can't be established.
RSA key fingerprint is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

And this is what you get, if the SSHFP record ain't up-to-date:

$ ssh -o "VerifyHostKeyDNS yes" login@example.com
[Cut long line of @'s. Too many 'junk' characters for /.]
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
[Cut long line of @'s]
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:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
Please contact your system administrator.
Update the SSHFP RR in DNS with the new host key to get rid of this message.
The authenticity of host 'example.com (127.0.0.1)' can't be established.
RSA key fingerprint is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Compare that with the first case where you had absolutely no idea if the fingerprint was correct or not.

I'm not saying, you should just trust all SSHFP records, if you're paranoid. But even if you ain't paranoid, the warning about the mismatching SSHFP record should be enough to make you stop and think instead of just saying yes.