Inclusion of the -i flag and the location of the private key solved the problem. Thanks Steve! -----Original Message----- From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of Steve Clark Sent: Wednesday, December 12, 2018 2:38 PM To: CentOS mailing list Subject: Re: [CentOS] SFTP - Private/Public Authentication Keysets Beyond The First Set On 12/12/2018 03:32 PM, Steve Clark wrote: > On 12/12/2018 03:28 PM, Gary Braatz wrote: >> Thanks for responding so quickly! No but I will try. Are you saying the >> first vendor connection worked because id_rsa and id_rsa.pub are the >> defaults if not specified? (I didn't use the -i flag for the first vendor.) >> >> >> -----Original Message----- >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of Steve Clark >> Sent: Wednesday, December 12, 2018 2:23 PM >> To: CentOS mailing list >> Subject: Re: [CentOS] SFTP - Private/Public Authentication Keysets Beyond >> The First Set >> >> On 12/12/2018 03:13 PM, Gary Braatz wrote: >>> I'm new to SFTP and using this mailing list was able to successfully >> create >>> my first Private/Public keyset for a vendor hosting the SFTP server (I'm >> the >>> client). I created the keyset by typing this: >>> >>> >>> >>> # ssh-keygen -t rsa >>> >>> >>> >>> When asked for the password/passphrase I hit <Enter> and afterwards >> "id_rsa" >>> and "id_rsa.pub" were created in "/root/.ssh/". I provided "id_rsa.pub" >> to >>> the vendor and when told they were ready I initiated an SFTP transfer. >>> During the first connection I was asked for the vendor-provided password >> and >>> after entering it was successfully connected to the vendor's sftp server. >>> During successive connections I was not again asked for the password. >> This >>> allowed me to create fully automated batch file transfers.my objective. >>> Setting up my second vendor is not going as smoothly. >>> >>> >>> >>> I did exactly the same thing for my second vendor with the exception of >>> typing "rsa_vendor2" during keyset generation (I assumed I had to use a >>> different name for the new keyset). >>> >>> >>> >>> # ssh-keygen -t rsa_vendor2 >>> >>> >>> >>> Files "id_rsa_vendor2" and "id_rsa_vendor2.pub" were created in >>> "/root/.ssh/" and I gave "id_rsa_vendor2.pub" to the second vendor. I >>> initiated the first connection with the second vendor and was asked for >> the >>> vendor-provided password which I entered and a successful connection was >>> made. The problem is unlike with the first vendor I am asked for the >>> password every time I connect to the second vendor's server. Because I am >>> being asked for the password I am unable to create fully automated batch >>> file transfers. >>> >>> >>> >>> The second vendor is telling me they added the public key to their server >> as >>> required. Did I miss a step or do something wrong on my end? Was I >> correct >>> using a different name for the new keyset or would the new keyset >>> information have been appended to the information already in id_rsa and >>> id_rsa.pub for the first vendor? >>> >>> >>> >>> Any help you can provide will be greatly appreciated. >>> >>> >>> >>> _______________________________________________ >>> CentOS mailing list >>> CentOS at centos.org >>> https://lists.centos.org/mailman/listinfo/centos >>> >> Are using the -i flag in your invocation of sftp to the second vendor? >> >From the sftp man page: >> >> -i identity_file >> Selects the file from which the identity (private key) for >> public key authentication is read. This option >> is directly passed to ssh(1). >> > In my experience - Yes. > To expand on my response - generally there is system wide default ssh_config file in /etc/ssh/ssh_config and by default: # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa -- Stephen Clark *NetWolves Managed Services, LLC.* Sr. Applications Architect Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com _______________________________________________ CentOS mailing list CentOS at centos.org https://lists.centos.org/mailman/listinfo/centos