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.

Good day,

I have setup a server running Ubuntu 12.04 LTS. I have left the default SSH port as-is for now, and have set up a DynDNS.org account.

From a machine, running linux, on a separate network, I am able to query my server via SVN+SSH:

svn --username myName ls svn+ssh://myName@superdude.dyndns.org/usr/local/svn/repos/private

So far so good: I am queried for the user's password, and an SSH private/public key pair appears to be generated. However, I am concerned.

I thought the point of private/public keys was that I'd have to provide the client with the appropriate key in advance. I want to lock down this server so that the people connecting to my SVN server have both a keyfile I gave them in advance, and the password for user "myName". Is there something I'm missing? At this point, all someone appears to need is the URL to my SVN server, and the password for user "myName", and they are in.

How can I lock this down tighter?

Thank you!

share|improve this question

1 Answer 1

up vote 2 down vote accepted

In SSH, public key authentication and password authentication (or keyboard interactive authentication) are separate things. You can either use PAM, or passwords, or public keys (or any of the other available facilities like kerberos GSSAPI). Which one gets used is negotiated between the client and server based on capabilities.

Because of this, you cannot require both a public key and a password; you must use either. The key is also bound to a particular user by nature, of course. In theory you could accomplish this with PAM, but as it is no SSH client would support it.

If I recall you can encrypt the keys, so that a user needs a password to decrypt them, but the user could just decrypt the key with openssl and store it decrypted to avoid typing the password (if you're worried about them being stolen), and if you are really worried about them being cracked, the attacker can do that the same whether you provided the private key to the user encrypted or not (but this is very, very hard to do as it stands).

The other aspect to this is the server's fingerprint, which you should optimally publish in advance either by supplying it to the client or using the SSHFP RRtype in DNS. This allows the client to verify it's connecting to the right server, and is validated regardless of the authentication mechanism used. This is always important, though it is more important with password and keyboard-interactive authentication (to prevent credentials from being stolen).

share|improve this answer
    
So, how can I lock this down then, so that something more than just typing a password is required? –  Dogbert Sep 29 '13 at 4:05
    
You can permit only certificate-based authentication to the exclusion of password authentication, by disabling all other methods of authentication in your sshd_config file (eg. PasswordAuthentication no). However, you cannot authenticate the user using multiple methods, with the exception of PAM, which can, but there is no way to use PAM to take the SSH key. You could enable two-factor authentication with PAM using google authenticator, though, and disable all the authentication methods that don't use it. –  Falcon Momot Sep 29 '13 at 6:03
    
So, my final question then: What's to stop this person from giving a copy of the certificate file to another user? It seems that it would suffer the same vulnerabilities as someone giving out their password. –  Dogbert Sep 29 '13 at 15:11
    
When using certain keys on my server, I notice that I have to enter a passphrase before they can be used. Would this make sense for an SVN+SSH setup: key based authentication, but the user needs to enter the passphrase each time they want to use the private key? –  Dogbert Sep 29 '13 at 15:24
    
I just figured it out. Thanks. BTW, this URL helps with the implementation: lebkowski.name/svn-key –  Dogbert Sep 29 '13 at 15:26

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.