Is it possible to somehow setup an ssh server that doesn't require a username,password or cert to login? If that's not possible, if I were to give all customers the same public key, would each connection be encrypted individually? (i.e. user A coudn't decrypt the payload of user B's connection)

I wish to provide access to a single program, which will prompt for a username and password.

Encryption is essential though, and users must not be able to snoop in on each other

If each client connects using the same key ( BTW they would be using the private key, the public key is on the server ) with no other credentials, how do you intend to tell them apart to stop them viewing each other. They will all be connecting as the same anonymous user,
–
Richard HollowayJun 23 '10 at 22:23

5 Answers
5

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.

Oops, I got the public/private thing the wrong way round! Thanks for clearing that up for me. Very good answer. So what I shall do is just ask customers to provide me with public keys then? Is there an "easy" way for people to do this? While I'm ok with doing ssh-keygen, some customers may find this daunting, or worse, may be using Windows :). Any ideas on a quick way of creating keys? Thanks
–
jtnireJun 22 '10 at 12:41

2

+1, What to take away from this: Setup SSH, have customers generate a public/private pair and provide their public key, pop those public keys in authorized_keys. Also, Putty provides a program to generate a key pair; do not use some random online webpage to generate key pairs. PuttyGen link: the.earth.li/~sgtatham/putty/latest/x86/puttygen.exe
–
Chris S♦Jun 22 '10 at 12:42

1

Like Chris S tells, yes just ask your customers for public keys, I don't know an easier way than ssh-keygen
–
radiusJun 22 '10 at 12:45

I don't think this is right. When using SSH2 (and everyone is), the session key is derived from a Diffie-Hellman key exchange. To decrypt a session, a client would need to man-in-the-middle the other; passive snooping is not sufficient even if the clients share a private key (but it makes MitM slightly easier by breaking authentication of the DH messages)
–
b0fhJun 3 '11 at 8:44

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.

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.

But does ssh support a "forced command" (i.e. only allowing the menu script to launch) by using username/password auth?
–
jtnireJun 22 '10 at 12:45

2

Having private key hardcoded in software is the worst things ever, in such case add a key generator in the software and ask customer to give you the public key (or automaticaly send it to an ssl webserver)
–
radiusJun 22 '10 at 12:47

It might not be the worst thing ever, but it certainly ranks up there. The biggest problem would be if the key got compromised (not difficult considering the number of people with a copy), you couldn't change the key without cutting everyone off and having to "update" all their copies of the program (with a new key). Embedding a key generator is definitely a step up, but it's still the best idea to have them use ssh-keygen or PuttyGen to make their key pair; and send in their public key.
–
Chris S♦Jun 22 '10 at 12:56