It's complicated. What I'll present below is a dramatically simplified version of the details. (Because the real details are contained in hundreds of pages of RFCs.) There are essentially 3 cryptographic steps to a TLS connection:
- Key Exchange
- Encrypted Communications for the application
Authentication usually involves the server identifying itself to a client by presenting a certificate. This certificate validates that you are talking to a legitimate server: it has the hostname of the server embedded in, the expiration date, and is signed by a legitimate certificate authority. Additionally, it contains a public key -- possession of the matching private key is evidence that the certificate "belongs to you." Most often, this is an RSA keypair, though it's also possible to use DSA or ECDSA, or even another Public Key system (but on the open Internet, it's almost always 2048 or 4096 bit RSA). This is what gives clients certificate warnings (wrong hostname, bad CA, expired, etc.). This is the part that you generate a key for, and it needs to match your cipher specification.
Secondly is key exchange. If you're not looking for perfect forward secrecy, this can be as simple as the client encrypting a piece of data using the server's public key from its certificate. The server then decrypts this, and both sides use it to generate the connection key. On the other hand, if you want perfect forward secrecy (i.e., stealing the RSA key isn't enough to decrypt every previous connection) you use some variant of Diffie-Hellman key exchange: basically, a technique for arriving at a shared secret securely. Without an active man in the middle, a 3rd party can't get the shared key, and the authentication step ensured you don't have an active man in the middle. This DH step can be Diffie Hellman over an integer group (DHE) or over an elliptic curve (ECDHE). Whether you use RSA, DHE, or ECDHE for the key exchange, you now have a secret key shared between the client and server that nobody else should have.
Finally, you get the actual encrypted communication. Asymmetric crypo like RSA and DH are too slow for ongoing communications of large volumes, so we use symmetric crypto systems (like AES) for this. This uses the shared key exchanged in the previous step to communicate. Each packet is signed as well, either with an HMAC (so you might see SHA256 as part of your cipher specification) or a tag like GMAC from GCM (for AES-GCM). Additionally, AES (and other ciphers) can be run in several modes: GCM, CTR, CBC, etc.
ECDHE-RSA-AES128-SHA256 means to use Elliptic Curve Diffie-Hellman for key exchange, RSA for authentication, and AES128 with SHA256 signing of messages. (CBC mode is used, though not explicitly included.)
ECDHE-ECDSA-AES128-GCM-SHA256 is Elliptic Curve Diffie-Hellman for key exchange, Elliptic Curve DSA for authentication, AES 128 for crypto (GCM for signing packets, SHA256 for signing other data.)
AECDH-RC4-SHA is Anonymous Elliptic Curve Diffie Hellman for key exchange, no authentication (hence anonymous), RC4 for encryption, and SHA-1 for packet authentication. (Please don't use this. All of it is broken by modern standards. It's an example.)