The cipher used depends on the client and server's SSL handshake; it is not dictated by the key pair itself. During this handshake, the client and server show what algorithms they support, and the server will typically choose the strongest available cipher.
The public/private keys can be used to accomplish three main goals; integrity, authentication, and confidentiality. However, it does not have to accomplish authentication as SSL/TLS can be implemented with total anonymity.
From page 34 of TLS 1.0 (RFC 2246):
The CipherSuite list, passed from the client to the server in the
client hello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first). Each CipherSuite defines a key
exchange algorithm, a bulk encryption algorithm (including secret key
length) and a MAC algorithm. The server will select a cipher suite
or, if no acceptable choices are presented, return a handshake
failure alert and close the connection.
From page 91 of TLS 1.2 (RFC 5246):
TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and
Also, see here for a simpler description of the SSL/TLS handshaking process.
It is also important to note that this cipher is only used when performing the handshake and exchanging the symmetric key which, after it is agreed upon, is used exclusively for the rest of the session UNLESS the secret key is set to be renegotiated.