Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I dont understand the security in this statement: SSH does no user-name matching only public key to private key matching. This is in reference to a previous post of mine where I can be user "svn" but as long as I have a P/p key match of my own. Am I not just pretending to be someone I am not?

Here is my previous question with a valid answer. Linux permissions with svn and Syncro

Can someone explain?

share|improve this question
up vote 1 down vote accepted

So when you log in with a key pair for authentication, the server uses the public key stored in the authorized_keys file in the users home directory. as the other answer says, that's in the svn users home dir since that's the account you are using.

The key pair is not tied to your ID EXCEPT through the use of that file. Or more accurately - that key pair is tied to your account only through its presence in the authorized_keys file in the users home directory. There is nothing in the key itself that ties it to a particular account.

You could copy that file over to Bob's home dir and Bob could login using that key pair. (Assuming the permissions were set right).

Is it making sense yet?

share|improve this answer

The server that you are connecting to doesn't care what username you have on your own machine. That is, if your username is 'foobar' on your laptop, you can still connect as 'svn' on the server. ssh will default to using your username though, so you have to specify an alternative if needed.

In your situation I believe the flow is this:

foobar@yourcomputer -> ssh -> svn@server

In that case, the ssh client will look for a private key in your ~/.ssh/ directory (or equivalent) that matches a public key in the ~svn/.ssh/authorized_keys on the server. A common use-case in this situation if for there to be quite a few public keys in the svn user's authorized_key file, so that many different people can all connect as the svn user, without having to share the svn user's password around.

Or, to put it a different way, you aren't "pretending" to be the SVN user - you are becoming the SVN user on the remote server.

share|improve this answer

It's just that: you can log in as any user in the remote system as long as you have valid credentials - be it password or private key. Just in case - note sshd matches your private key to the authorized keys of the username you're trying to log in as, and not the one for your own username if you have one on that server.

Asking for the originating username to be the same would provide little or no security, as far as I can tell, as for example if you're the administrator of the originating server you may create any usernames you want.

share|improve this answer

SSH does no user-name matching only public key to private key matching.

That statement makes no sense and is patently false. SSHD needs to know your username so that it knows where to look on the sever for your public key.

share|improve this answer

If you have your own public/private ssh key pair you can give your public key to anyone. They can add that key to the $HOme/.ssh/authorized_keys file for any account that they wish to grant you access to.

When you ssh user@host.tld ssh will use your private key stored on the host you are sshing from and the public key on host.tld stored in ~user/.ssh/authorized_keys to confirm your identity. Your public key could also be in otherusers authorized_keys file so ssh otheruser@host.tld would also get you in.

share|improve this answer

Your Answer


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.