Let's have a look at how these are implemented:
RSA
RSA is probably the example, showing how prime numbers are used in cryptography. In order to calculate a private key, two prime numbers, $p$ and $q$ are "chosen". What that means in practice is that your computer will generate a random number (and set a few bits) and then check whether or not the generated random number is a prime.
Well...not exactly. Actually, the generated number is a "pseudo prime number", which is a number that is probably a prime number, but we can't know for sure. In order to be certain, we would have to divide the number by every prime number up to the square root of the prime candidate.
Why isn't this check done? As you can imagine, checking whether or not 13377216267221394781281321803240685565647633863945354245591337480581850892718220086347852930388186839929611014777408043323753186115505611255512212061593047 is a prime factor of 168581487233807662095985877892466382655984504887588184273878566402288131033127314863556248166230176818735604347430473403376658381900826700241919315590165489510028586594896744589808921429729412701596114362546978418049726172509111051384159129475101054095614648000575426731420406552789078218487162756487172295557 is a computationally expensive task. Especially if our current tests run magnitudes faster and can give us a $4^{-k}$ chance of a non-prime passing the test, with $k$ being the number of runs of the Miller-Rabin test.
You can even try this yourself by running openssl genrsa. You will see output like this:
Generating RSA private key, 2048 bit long modulus (2 primes)
................+++++
...............+++++
e is 65537 (0x010001)
Each . means a potential prime candidate was generated, and each + means a round of Miller-Rabin was passed. According to this answer, even three rounds of Miller-Rabin will be enough to make it very unlikely that a randomly generated non-prime passes the Miller-Rabin test. So as you can see, OpenSSL stops after five passed rounds and moves on to generating a new number.
Diffie-Hellman Key Exchange
In order for DH to work, there needs to be a public prime $p$, which can be a known default value. These can be generated on-the-spot by either the client or the server, but publicly known default values can be used. Since these are just transmitted over plain text, an attacker can intercept them.
It should be noted that you want to pick a $p$ for which $p-1$ has a large prime factor $q$.
The secret keys $a$ and $b$ generated in DH don't need to be primes, so any random number will suffice.
Are they supplied by the user?
Yes and no. Many protocols require a user's private key, which they supply in form of a key file. Nothing stops a user from generating their own key file with any prime number of their choosing.
However, most users won't do that, as there is really no benefit to that. Even an attacker has no benefit of supplying something like a semi-prime (a number that is the result of two prime numbers, e.g. 15), since that would not give them any advantage.
Definitely, no serious program will ever ask the user to enter a prime number, which is then used for cryptographic purposes, aside from demonstration tools.
