1

Forgive the possibly simple question, but I cannot seem to find a good solution.

A backup job needs to rsync files to a destination host, over ssh. The only login available to me is username2@destination. I do not have access to the sshd logs on the destination.

I need to run this backup using username1@client username. I am very familiar with using ssh-keys, when username is the same on both ends.

Is it possible to use ssh-keys when usernames differ on either end?

thanks in advance.

Bernard Tyers
  • 111
  • 2

1 Answers1

1

If you use key based logins, the username doesn't get used at all. Logging in from user@host1 to user2@host2 with key based logins is quite a standard procedure. I do it dozens of time every single day.

You just have to make sure that the public key for user@host1 is present in the ~/.ssh/authorized_keys file of user2@host2.

Sven
  • 98,649
  • 14
  • 180
  • 226
  • Thanks. So I have scp'ed user@host1 .pub file up to .scp/authorized_keys2 file on host2: scp ~/.ssh/id_dsa.pub user2@host2:/user/.ssh/authorized_keys2 I logged out, and tried to ssh back to it: host1:.ssh user$ ssh -l user2 host2 user2@host's password: So something is up. Logs from client (ssh -vvv) show: debug1: identity file /Users/user/.ssh/identity type -1 debug1: identity file /Users/user/.ssh/id_rsa type -1 debug3: Not a RSA1 key file /Users/user/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' – Bernard Tyers Feb 05 '12 at 20:56
  • The error message says the home directory for `user2@host2` is `/Users/user`, yet you copy the public key to `/user/.ssh` instead of `/Users/user/.ssh`. Try with `scp ~/.ssh/id_da.pub user2@host2:~/.ssh/autorized_keys2`. – Sven Feb 05 '12 at 20:59
  • Sorry, that comment was badly formatted. Logs from client (ssh -vvv) show the following http://pastebin.com/uB8vmWKp – Bernard Tyers Feb 05 '12 at 21:03
  • I found the issue. I can't explain fully but the ssh daemon is running in an "unusual" location and I had to transfer the id_dsa.pub file to a different location other than user2/.ssh/authorized_keys. Also, it seem the host is running an older version of sshd. thanks. – Bernard Tyers Feb 05 '12 at 21:11