SSH: Can sniffers see where your traffic is tunneling to?

It depends on how the SSH tunnel is setup, but, generally speaking, there are ways to track things. Let's talk about the high-level scenario.

When I make an SSH connection to a server, the contents of my SSH conversation with that server are secure -- they're encrypted, so you have to break SSH to know what we're saying. However, the IP packets carrying that conversation cannot be encrypted, so if you were to look at one IP packet in that conversation, you'd know where I am (IP source address) and where the SSH server is (IP destination address).

In an SSH tunnel, the conversation I'm having with the server is another TCP/IP conversation to some other remote destination. So inside the tunnel, that second network connection is encrypted, but once it gets to the other end of the tunnel, it's unencrypted internet traffic.

Now. If you were to find that second conversation in the clear, all you'd see is the final destination of the conversation (IP destination address) and the SSH server (IP source address). There's not much in those packets (considering TCP/IP headers only) to differentiate it from some other internet traffic that was created on the SSH server machine; I don't believe there's anything specific in the packets that indicates SSH had anything to do with it.

That doesn't mean it can't be connected back to me -- just that you couldn't do that just by examining TCP/IP headers. For example, deep packet inspection (looking at the data payload in addition to packet headers) could certainly identify me if I'm using the tunnel to login to my Gmail account without SSL. As another example, someone who can root the SSH server hosting my tunnel can figure out what port the tunnel is operating on, and then they can track me by TCP/IP headers.

So no, SSH tunnelling by itself will not be sufficient to hide your e-footprints from a determined tracker.

Initially the packet will contain the next destination MAC on the route to the end destination, and the IP of the end (actually, we'll say final since it sounds better) destination. How the packet is constructed, this cannot be changed. Even though the data is encrypted, you can't encrypt the destination as each corresponding node needs to know where to route the packets.

As you can see in wireshark:

The destination MAC is that of the next hop (my router), and the destination IP is that of Google.

Note:

If the connection to the destination ip (eg. Google's ip) passes through the SSH tunnel, only the ip address of the SSH tunnel can be seen in the packet NOT the ip address of Google.