How does non-ephemeral Diffie-Hellman key exchange become compromised in SSL when the RSA private key is leaked?
First let's be sure that we talk about the same thing. In SSL, there are "ephemeral DH cipher suites" (DHE) and "non-ephemeral DH cipher suites" (DH).
With DHE, the server private key (the permanent one, the one which is stored in a file, and whose public key is in the server certificate) is of type RSA (DHE_RSA cipher suites) or DSS (DHE_DSS cipher suites), and is used only for signatures. The server generates a new random DH key pair (the private key will not be stored, which is how perfect forward secrecy is achieved: a private key cannot be stolen afterwards if it has never been stored), and sends the public key to the client, in a message which the server signs with its RSA or DSS private key.
With DH cipher suites, the permanent server private key is a DH private key. The server certificate contains the DH public key. The server cannot see its RSA key be stolen because the server does not have a RSA key. The server only has a DH key. When a cipher suites is called "DH_RSA", it means "the server key is a DH key, and the server certificate was issued (i.e. signed) by a Certification Authority who uses a RSA key".
Stealing the DH private key of one party involved in a DH key exchange allows ulterior reconstruction of the shared secret, just like RSA. In "ephemeral DH", the PFS is obtained through "ephemeral", not through "DH". Technically, it would be possible to have "ephemeral RSA" but it is not done in practice(*) because generating a new RSA key pair is kinda expensive, whereas producing a new DH key pair is cheap.
(*) Ephemeral RSA keys were possible with old versions of SSL as part of the "export" cipher suites, meant to comply with the pre-2000 US export regulations: the server could have a 1024-bit signature RSA key, and generate an ephemeral 512-bit RSA key pair for key exchange, used in encryption mode. I don't recall having ever seen that in the wild, though, and it is a moot point since US export regulations on key sizes were lifted.
Non-ephemeral DH cipher suites exist in order to allow servers with DH certificates to operate. DH keys in certificate exist because in older times, RSA was patented but DH was not, so standardization bodies, in particular NIST, were pushing DH as the must-implement standard.
Reality caught up with that, though. I have never seen a SSL server using a DH certificate. Everybody uses RSA. The RSA patent expired a decade ago anyway.
For SSL/TLS, we need 2 things:
1) client needs to authenticate the server.
2) client and server need to compute a symmetric session key.
A few ways of doing both:
Most common: TLS_RSA_WITH_AES_...
RSA is used for both 1 (authentication) and 2 (computing symmetric key).
Preferred: TLS_DHE_RSA_WITH_AES_... or TLS_ECDHE_RSA_WITH_AES_...
RSA is used for 1 (authentication) and for signing the DHE keys.
DHE is used for 2 (computing symmetric key).
Preferred, because you get Perfect Forward Security (PFS)
Not common: DH_RSA_... (this is the non-ephemeral DH in OP's question)
DH is used for both 1 (Authentication) and 2 (computing symmetric key).
The case you are referring to is the 3rd ("Not common") and as you can see, RSA is used neither for 1 (Authentication) nor for 2 (computing symmetric key) and so there is no question of RSA private key being leaked. The RSA in DH_RSA could be misleading but as Tom Leek mentioned, the Administrator of the server will provide credentials and their DH public key to a CA (Certificate Authority) who will then sign the DH public key with the CA's RSA private key.