What are the risks of SSHing to an untrusted host?
Intercepting the "logout" commands is easy on the hostile server. Intercepting the "Ctrl-D" requires taking control of the terminal in raw mode, but that's not a big issue.
Reading back the terminal contents might prove difficult. Different terminals implement their own set of control sequences; xterm is notorious for implementing a lot of them. I don't see any sequence which allows reading back the terminal contents; however, some considerable messing up can still be done with the sequences, such as moving the window around, switching fonts, and so on. In older days, it was possible to actually make xterm create local files, albeit without much control on the file name (I don't remember the details, but it was probably with the "log files" feature which may be disabled at compile-time). Besides dancing, an xterm could be made to sing, too, with the "bell character" -- it is more a nuisance thing than an attack vector, though.
Speaking about nuisance: depending on the client system and its configuration and graphic drivers, a rogue terminal scrolling text at high speed may all but freeze the victim's console (in my experience, gnome-terminal and a compositing window manager can turn into a bad combination for that).
Still in xterm, there are sequences to manipulate the clipboard (search for "manipulate selection" in the reference page linked above). This can be nasty, both for reading and for writing. See this page for a discussion about the possible issues (an issue-tracking list of comments, from people discussing the possibility of importing that mechanism in a terminal emulator called mintty).
The overall conclusion is: do not SSH into insecure hosts. If you do, you may want to do that from rxvt-unicode, an rxvt fork where the author made (among other features) some effort at disabling "insecure" control sequences by default (they can be brought back with the "-insecure" command-line parameter).