18

Suppose I have a remote system named "remotesystem", and a user account "foouser" on that system.

I know that on my local system, I can generate an SSH key pair as local user "foouser", put the public key in the "/home/foouser/.ssh/authorized_keys" file on "remotesystem". When I SSH as "foouser" from my local system to "remotesystem", SSH uses the key pair to authenticate me.

But what if my local username is not the same as the username on the remote system? That is, what if I want to SSH as local user "baruser" to "remotesystem"? Obviously, I will need to generate a key pair for "baruser" and add the public key to "/home/foouser/.ssh/authorized_keys". Then, I should be able to "ssh foouser@remotesystem" while logged in as "baruser" locally, and SSH will use the key pair to authenticate, right?

I'm asking because I am trying to get the key authentication working in this scenario, without success. I'm not sure if its due to the username mismatch, or a configuration issue with the SSH server on the remote system.

Matt
  • 283
  • 1
  • 2
  • 6
  • I cranked up the logging server-side, and it proved to be a problem with the permissions on the remote user's home directory. Problem solved! Thanks to all who gave answers. – Matt Jun 04 '09 at 14:27

7 Answers7

11

Yes, you can do this, just as you described it.

baruser@here ~$ ssh-add -l
4096 10:b3:fd:29:08:86:24:a6:da:0a:dd:c6:1e:b0:66:6a id_rsa (RSA)
baruser@here ~$ ssh foouser@remotesystem
motd message, etc.
foouser@remotesystem ~$
skierpage
  • 103
  • 3
user1686
  • 8,717
  • 25
  • 38
  • Thanks for the answer. I knew I wasn't crazy... :-) There must be something wrong with the remote system's SSH server configuration, preventing key authentication to work altogether. – Matt Jun 03 '09 at 18:57
  • 4
    If you do "ssh -V foouser@remotesystem" you can get some information on what's going wrong. Oftentimes it's a permission error on ~/.ssh. – Paul Tomblin Jun 03 '09 at 19:01
  • 4
    not -V (shows version number) but -vvv (max verbosity) – Leven Mar 01 '13 at 22:03
10

It's a bit of an aside, but.....

If you're always using the same username for a remote server, you may also find it useful to add a host into your ssh config:

Host remotesystem
    User baruser

That way you don't need to remember to specify user name when logging in, and you rule that out when having issues with keys in future.

Mark
  • 101
  • 2
5

Your local username doesn't really matter (aside from the private key having to reside inside your local user's home directory). Just copy the key to the remote user's authorized_keys section and it will work.

Sören Kuklau
  • 25
  • 2
  • 9
3

The permissions on the .ssh directories on both machines much be correct. Generally, that means 700 on the .ssh directory and at most 755 on the home directory. In addition to 600 on all the files in the .ssh directories.

If the user on the remote system is root, make sure that root can ssh. (PermitRootLogin in sshd_config) and that public key (PubkeyAuthentication) and if necessary RSA (RSAAuthentication) are enabled.

Alexandre Carmel-Veilleux
  • 489
  • 2
  • 6
3

With any ssh related problems, the first thing to do is turn up the client verbosity:

ssh user@machine -vvv

If this fails to give you any insights as to what is wrong, you need to change the log level on the server and restart the daemon.

LogLevel DEBUG3

You should find the debug output in /var/log/auth.log (or where ever ssh is configured to log to). Once you've found the problem, remember to set it back to how you found it.

David Pashley
  • 23,151
  • 2
  • 41
  • 71
2

If you have SE Linux enabled, you will also need to do the following.

Add the SELinux label to authorized_keys so that it could be accessed by sshd.

semanage fcontext -a -t sshd_key_t ~foo/.ssh/authorized_keys
restorecon -Rv ~user/.ssh
chicks
  • 3,639
  • 10
  • 26
  • 36
Prof Mo
  • 121
  • 1
1

Sounds like you're doing things correctly, but make sure that the permissions are correct on authorized_keys. They should be set to 600.

Michael Gorsuch
  • 2,358
  • 1
  • 21
  • 24