SSH Keygen with Multiple network Interface

[AZayed]

Dears,
Good day,

I have a server with multiple IPs e.g. 10.11.72.141 , 10.11.72.142 & 10.11.72.143 this server going to SFTP files to one server. How can I create 3 RSA keys for each IP? Is there any recommendation about my case?

Thanks a lot.

[Matti_Kurkela · Accepted solution]

SSH keys are used for two purposes: user authentication or server identity verification.

The server identity verification keys are typically created when installing a SSH server, and having the same key on multiple IPs is not a problem.

The user authentication keys are created to identify a particular user: hostnames or IPs are not involved at all, unless you explicitly choose to accept a particular key from particular client IP(s) only.

If only one user account is used to transfer files, you'll need to login to that account, run "ssh-keygen -t rsa" or "ssh-keygen -t dsa" (whichever encryption algorithm you prefer), and arrange for the public part of the generated key pair to be copied to the ~/.ssh/authorized_keys file of the appropriate account on the target server.

By default, the target server should accept the correct authentication key from any host, so the fact that your server has three IPs should not be an issue. If it's desirable that the key will be accepted only if the connection is coming from your server, this restriction must be configured in target-server-specific way.

If the target server is OpenSSH-based, this is as simple as prefixing the public key in the authorized_keys file with a "from=" option, like this:

from="10.11.72.141,10.11.72.142,10.22.72.143"

MK

[AZayed]

Hi Matti,
Thanks for your reply. It didn't work :( I just tried to use simple authentication.

Is it because I'm doing it between Client "SUN Solaris 10 Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f" & Server "Linux redhat 5 OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008" ?

Or is it because the users ID's are different?

Thanks

[suvy12]

Different UserId does not make any difference to the ssh-key less authentication.

try with ssh -vvv user@destinationIP.
This will give you some information where are u going wrong.

[AZayed]

Sorry, I forget to attache the output.

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying public key: /export/home/inoperator/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /export/home/inoperator/.ssh/id_dsa
debug3: no such identity: /export/home/inoperator/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

[Matti_Kurkela]

Your SSH client sends the RSA key, but apparently the remote server won't accept it.

The most common reason for this is unsafe permissions on the remote server. If the remote user's home directory is writeable by someone other than the user, then sshd will ignore the authorized_keys file because it's possible that the keys are not placed by the legitimate user, but by another malicious person that has write access to the user's home directory. The same checks are made to the .ssh directory and the authorized_keys file.

To make sure the permissions are correct:
- login to the remote host using a password
- run "chmod go-w $HOME"
- run "chmod go-w $HOME/.ssh"
- run "chmod go-w $HOME/.ssh/authorized_keys"

You can still have other group- or world-writeable sub-directories in your home directory if you wish, but the home directory itself and the .ssh sub-directory must be protected.

If this does not help, check the remote server's system log: the sshd daemon won't tell to the client the reason why it rejects a particular authentication attempt (no sense helping a potential intruder!), but it will write the reason to the system log, so that the server's administrator can use the information to identify and fix legitimate users' login problems.

MK

[suvy12]

Append the id_dsa.pub (From source machine) to authorized_keys(Destination Machine)both are in .ssh directory of the user .
If id_dsa.pub not present in the Source machine then generate it with the command
#cd .ssh
#ssh-keygen -t dsa
Make sure in file /opt/ssh/etc/sshd_config line present as below in both source and destination
PubkeyAuthentication yes
Permission on .ssh directory should be 700
Permission on files under .ssh should be 600
also
Check for /var/adm/syslog/syslog.log file on destination server for any error message
If still not happen then try with
#/sbin/init.d/secsh stop
#/sbin/init.d/secsh start

[AZayed]

Thanks Matti, it was the owner of the directory