Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

Thanks

share|improve this question
    
Sorry folks, I should have posted this question on ServerFault. Oops! –  jtnire Jun 22 '10 at 12:21
    
Sending it there now... ;-) –  Andrzej Doyle Jun 22 '10 at 12:22
    
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 Holloway Jun 23 '10 at 22:23

5 Answers 5

up vote 10 down vote accepted

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

share|improve this answer
    
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 –  jtnire Jun 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 –  radius Jun 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) –  b0fh Jun 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.

share|improve this answer

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"

share|improve this answer

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.

share|improve this answer
    
But does ssh support a "forced command" (i.e. only allowing the menu script to launch) by using username/password auth? –  jtnire Jun 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) –  radius Jun 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

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).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.