ssh keys

[Graham Van der vaart_1]

Hi,
I have server A to sftp file to server B.
Both A and B have a user SECFTP.
A has private and public key for user SECFTP. A gave B the public key.
I can sftp from A to B OK as user SECFTP.

A has a SAP user called sp2adm that must execute the script owned by SECFTP to sftp the file.
I tried copying SECFTP private key to sp2adm's .ssh directory but I'm still prompted for a password.
Can I use chroot for user sp2adm to enavble that user to execute the sftp script without password prompt?
If so how?
I'm only a part time HP-UX admin so any help would be greatly appreciated.
I don't want to change the default settings in /opt/ssh/etc/sshd_config unless I abolutely have to.
Kind Regards
Graham

[Steven E. Protter]

Shalom,

Check this document.
http://www.hpux.ws/?p=10

These problems are almost always caused by ownership and permissions problems on the home and .ssh directory or the files within .ssh directory

SEP

[Matti_Kurkela]

I see you're a bit confused about SSH keys. Don't worry, that's surprisingly common with seasoned admins too.

So the user sp2adm@serverA must copy a file to SECFTP@serverB, right?

in that case, secftp must run ssh-keygen at serverA to create a SSH keypair. The _public_ key of that keypair should then be copied to the ~/.ssh/authorized_keys file of the SECFTP user on serverB. The home directory of SECFTP@serverB, its .ssh sub-directory and the authorized_keys file must not be writable by anyone other than SECFTP.

Think of it this way: the SSH public and private keys correspond to a physical lock and a key that fits that lock only, respectively. If you need to have access to a particular door but are afraid that the owner of the door might copy your key if s/he sees it, you can buy a lock and a matching key from a locksmith, then give the lock (=the public key) to the door owner so that s/he can install it to the door. You can then open the door with your key whenever you wish, without showing your key to anyone else at any point.

Making copies of the lock and installing them to other doors is not very useful, assuming that you cannot be tricked to go to a wrong door. This particular lock is constructed in such a way that it's extremely difficult to examine the lock to find out information about the key that opens it.

MK

[Tingli]

Actually, Graham's way should work.

How about running in sp2adm from A by:

ssh SECFTP@B

and see what happens.

[OldSchool · Accepted solution]

"Actually, Graham's way should work.

How about running in sp2adm from A by:

ssh SECFTP@B

and see what happens."

yep, but
a) verify the permissions on .ssh in sp2adm's home directory are correct.
b) you might also need to specify "-i " to tell it which key to "send".

[Graham Van der vaart_1]

Thanks for all the great insight.

I finally got it working by setting the permissions of the copy of SECFTP's id_dsa private key in the sp2adm's .ssh directory to 644.

Kind Regards
Graham

[Bill Hassell]

> I finally got it working by setting the permissions of the copy of SECFTP's id_dsa private key in the sp2adm's .ssh directory to 644.

YIKES! The directory for .ssh should be 700 owned by sp2adm, and all the files in .ssh must be 600. The whole purpose of ssh is security. If the public and private keys can be read by anyone (ie, 644) then the auditors (and possible intruders) will be able to bypass security.

[Tingli]

Also, the permission of home directory can not be higher than 755.

[Tingli]

Missed something in previous post. The home directory should be the server's home directory.

[Graham Van der vaart_1]

>YIKES! The directory for .ssh should be 700 >owned by sp2adm, and all the files in .ssh >must be 600. The whole purpose of ssh is >security. If the public and private keys >can be read by anyone (ie, 644) then the >auditors (and possible intruders) will be >able to bypass security.

Any ideas on how I should proceed?

Graham