R
First of all, a few misconceptions:
You've got the way public key crypto (which is in fact called "public key" or "asymmetric", not "private key") works a bit wrong. The public key can encrypt and verify but can't sign or decrypt. The private key is the reverse. The sensitive operation in both cases - the one that only an authorized person should be able to do - requires the private key (anybody can encrypt, but only one can decrypt and reveal whatever secrets were encrypted; anybody can verify a signature if they get one, but only one is able to say "I hereby attach my seal to this message, that it may be known to come from me and not get tampered with en route").
Hashing isn't encryption, in any useful sense. Not only is there no corresponding decryption routine, but also, hash functions produce an output with a fixed length, regardless of the input length (encryption functions always product an output at least as long as the input, and many can't actually take an arbitrary length input at all without some way to repeatedly apply the basic operation to each data chunk in sequence, known as a "block cipher mode of operation").
Hashing also usually does not use any form of "key". You don't specify why you'd need a keyed hash at all in your actual question, but I'm going to assume it's for the usual reasons you might want one: to generate a message authentication code (MAC) of some kind, such as an HMAC (Hash-based MAC).
With that said:
While there are no cryptographic primitives (algorithms that can implement a single cryptographic operation) that can both encrypt and hash but use two different keys, there are cryptographic "constructions" or "suites" that do this. For example, TLS (the security protocol behind HTTPS and some other protocols) can use two symmetric keys in some cases, one for bulk data encryption and decryption, and the other for computing MACs of that data.
Alternatively, TLS (and other cryptosystems) can extend various ciphers in ways that add message authentication on top of encryption using the same key, and usually it's also possible to MAC some data without encrypting it. This is known as "Authenticated Encryption with Associated Data" (AEAD), and there are a few common ways to do it (Galois/Counter Mode, a block cipher mode of operation that adds AEAD to any block cipher, is commonly used with AES in, among many other things, securing your communication to this very website). However, while AEAD can both encrypt/decrypt and MAC (sort of like signing)/verify, and can MAC data that is not actually encrypted as well as data that is, AEAD uses the same key for everything.
Finally, and included only for completeness' sake, you can build something not entirely unlike a hashing algorithm using a cipher (encryption algorithm). If you take the message to "hash" and use it as the encryption key for some cipher, and use them (either without any initialization vector or nonce, or with a fixed one which thus technically is not a nonce) to encrypt a message already known to both parties (typically publicly known, or at least not really secret), you can produce something that is technically a ciphertext but which is used like a hash digest. Please don't do this; secure hash algorithms are as good or better at everything you might want to use this approach for.
Like a hash, this process is deterministic: assuming the cipher and message are held constant, any given secret will produce the same ciphertext.
Like a hash, this process is irreversible; assuming the cipher is secure, there's no way to derive the key used (except by brute force, which should be impractical) even though you know both the plaintext message and the ciphertext (and indeed know many such pairs for different keys).
In a secure hash, the process is collision-resistant; that is hopefully the case here too (it is only possible via brute force to find two different keys such that they encrypt the same message to the same ciphertext). However, that's not necessarily something one specifically tests ciphers for.
In a secure hash, the algorithm is resistant to pre-image attacks (given any digest, it's only possible by brute force to find an input that produces it); this is probably also true for these cipher-based "hashes".
Unlike a typical secure hash algorithm, the length of the secret is strictly restricted (ciphers typically only accept a small range, or single value, key size).