Sharing public key with ssh

I don't think you can remove authentication part of SSH because you alway need a username to open a session but you can set a blank password and set PermitEmptyPasswords to yes in your sshd configuration.
But this is not really safe, using keys authentication is better.

If you give your customers a public key it means that they can allow you to connect to their ssh server, not yours.
I think you want customers to connect to your ssh server. In this case customers need to give you their public key and you will allow them to connect. If all customers were using the same public key to connect to your ssh server it would mean that all customers use the same private key, and this is not an option (it's not your role to provide a private key and private key should not be shared)

Regarding encryption and snooping, encryption is done with session keys not public/private key, but to exchange session keys ssh use public/private key.
So if all your customers where using the same private keys, if they snoop a session from the begining they could decrypt the session, if they snoop the session after session keys exchange it would be very difficult to decrypt the session.

A good Article on how ssh works http://www.eng.cam.ac.uk/help/jpmg/ssh/ssh-detail.html

Bit late but you can force a user to run a particular program upon login (by any means) by setting their shell to that program in /etc/passwd. I believe there's a more complex way when using sshd using .sshrc files but I'm not presuming you're on OpenSSH - it's all in the man files though.

Think of the private key as the secret. When you are to prove something, like your identity in this case, you can claim you know a secret, in this case, the private ssh key. The public key is that: "public", and in that sense it can't be used to prove anything.

This goes along with the recommendation that don't give more than one user the same private key, ever. A huge amount of security holes origin in attempts to make security processes less burdening. There are secure ways to do that too. But you as the admin, will have to make the work, otherwise you are automatically letting your network and its users open to attack.

"Don't take shortcuts"

Stick with usernames and passwords if you're planning on asking customers for one anyway. You'll need to provide the same private key to all customers if you're embedding it in the client software, and so they'll have access to anything that key can - which means any account on the server.

You really want to be creating separate accounts for each user, and there's no real reason to use keys when customers are going to expect to have to enter usernames and passwords (they'll be confused how it's secure if they don't have to give a password every time).

To keep things simple to support, you'll want to have it really easy to change people's usernames and passwords - possibly a central directory server running LDAP with nice GUI interfaces for the helpdesk.

Users will be able to snoop on each other as they'll be able to access the memory space of other processes (assuming they can run arbitrary programs).