I want to do a passwordless ssh connection for a subversion project. Right now I'm using ssh+svn, and it's a little annoying, because I have to type the password any time I want to transact with the server.

I've found several tutorials on the web about how to generate a key for passwordless ssh, but they all seem to assume that I'm using the same username on the remote system as I am for my home system. However, the username that I use for ssh+svn is different that the user account name on the system that I'm running. How do I set this up properly? I haven't had luck with just changing the name in the key file.

4 Answers 4


You just have to supply the other system's username in the svn command:

$ svn co svn+ssh://otheruser@othersystem/path/to/repo

To answer your question's title, too:

$ ssh otheruser@othersystem

This causes sshd on the remote machine to look in ~otheruser/.ssh/authorized_keys for the public key corresponding to the private key on the machine you're typing the command on.

  • 1
    So part of the instructions were to make a file .ssh/id_rsa.pub, and upload it to the remote server. When I made it, it ended with localusername@localsystem. That should be changed to remoteusername@remotesystem, right? Both locally and remotely?
    – user394
    Aug 19, 2010 at 14:05
  • 5
    No. Just append the contents of your local id_rsa.pub to authorized_keys on the remote system. It'll work. Aug 19, 2010 at 14:33
  • 2
    alternately, many systems have ssh-copy-id to solve this problem: "ssh-copy-id -i ~/.ssh/id_rsa.pub username@remote-machine" Aug 19, 2010 at 15:12
  • Unfortunately, many do not, and it seems this is not a standard part of OpenSSH, so there are at least a couple of different implementations of this script floating around. Aug 19, 2010 at 15:29
  • If you are using gnome seahorse have automated deployment of keys. Aug 19, 2010 at 16:29

There are two ways to do this:

1) put user@ into the svn url ; this tells svn+ssh to login as that user. I think it's kind of a bad idea from a maintenance perspective because things like externals that point at other parts of the repository won't work correctly.

2) make a ~/.ssh/config (documented as ssh_config) that says something like:

Host othersystem
  User otheruser

this way any attempt to ssh to othersystem will default to using otheruser. Which is handy for you when do ssh manually as well as when you're using svn.


You don't have to have the same username on both mashines. As long as you generate the key (ssh-keygen) you have to copy line from ~/.ssh/id_rsa.pub or ~/.ssh/id_dsa.pub (depending on type of key) from local server and append it to ~/.ssh/authorized_keys on remote.

% ssh-keygen
% cat ~/.ssh/id_*.pub | ssh remoteuser@remoteserver 'cat > .ssh/authorized_keys'

If you don't want to type remoteuser each time append to ~/.ssh/config:

Host remoteserver
    User remoteuser

PS. The name of key may be in form of localuser@localhost but it is only a name. It can be just as well myfavouritekey@myfavouritecomputer and noone would care.

  • The "cat" command above is the core of the common but nonstandard ssh-copy-id script mentioned above. I recognize it because not all the systems I use come with ssh-copy-id, so I've typed something like that more than a few times. :) Aug 19, 2010 at 17:06
  • I've never heard about ssh-copy-id. I usually use vim or seahorse ;) Aug 19, 2010 at 17:40

After I create .ssh/config, and run :

cat ~/.ssh/id_*.pub | ssh remoteuser@remoteserver 'cat > .ssh/authorized_keys'

I get error :

Bad owner or permissions on /usr/share/eprints3/.ssh/config

then I add chmod 600 .ssh/config, and after that, it running smooth.

enter code here
  • 1
    Its better if you append it in the authorized_keys file, otherwise it will remove other's pub keys as well. So better if you edit your answer with 'cat >> .ssh/authorized_keys' Jan 12, 2018 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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