These are whitehat techniques, and most assume that you have complete control over both the client and server, and are able to make configuration changes necessary to do disrobed logging.

• SSL
  • all you need is the private key from the server
  • [Wireshark] use the -o ssl.keys_list option to pass it the private key. Wireshark will the decryption itself. :)
  
  
• SSH v2
  • Step 1) obtain the session key somehow (TODO: how?). Step 2) Once you have the session key, Wireshark will NOT decrypt it itself, you have to use another tool to process the .pcap file first. (TODO: how?)
  • cr0.org's ssh_decoder will decrypt a .pcap file
  • Sandstorm Communications’ NetIntercept product reportedly does it, though it costs $$
  • TODO: look into this more...
    • reference material
      • SSH2 architecture (what happens during initial SSH connection): RedHat, O'Reilly
      • this explanation of diffie-hellman key exchange
      • "neither side can fully determine the session key as an additional precaution" — woah, WTF?
        • "The chosen method produces a shared secret that isn't used directly as the session key, but rather is input to a further process that produces the session key." — huh, interesting
    • there are several numbers that exist by the end of key-exchange, that seem to be used for later encryption:
      • session identifier — used to prevent replay attacks
      • session key — a symmetric key, the key is known only to the server+client, and is used ONLY during this one session
        (note: neither side knows the full session key)
      • shared secret — a number that's used to derive the session key, but in a way that neither side knows the full session key
  • as a fallback, there are several MITM programs that can do it that way:
    • dsniff's sshmitm (step-by-step instructions for using it) (note: ONLY works for SSH-1)
    • mitm-ssh
  
  
• SSH v1
  • For SSH v1, it may be sufficient to obtain the server key instead of the session key, to decrypt packet logs.
  • you can use -c none to tell SSH-1 (but not SSH-2) to use "none" for the cipher
    • there are plenty [1][2] of caveats, however