× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Scott,

Absolutely right! I was generating the key pair on the server under the
belief that was the location of the private key but, based on your comments
above, I can now see that was a misconception. So instead I'll generate the
keys on the client and then ship the .pub file.

Many thanks

Keith


On 16 June 2014 20:31, Scott Klement <midrange-l@xxxxxxxxxxxxxxxx> wrote:

Hi Keith,

I think you might be copying the keys backward. The keys should be
generated on the _client_ box. the .pub file should be copied to the
server and installed in the authorized_keys file there.

It sounds like you are doing the opposite (putting the public key on the
client, and adding it to the client's authorized_keys file) which is
backward.

Since the client is where you're running the commands, you're already
authenticated (signed-on) before you run SSH there. You don't need to
authenticate to the client... so that's why you must install the public
key into the "authorized keys" file on the server.

-SK



On 6/16/2014 2:13 PM, Keith McCully wrote:

This is part of a proof of concept exercise aimed transferring a file from
the IBM i to a windows server via SSH (SFTP). However, as a first stage, I
want to run some SSH tests between 2 IBM i LPARS residing in the same
enclosure so as to avoid firewall issues for now.



So far I’ve done the following:



1. Created 2 user profiles: one on the client and the other on the

server – both 6 characters in length.
2. Created /home/UserProfile/.ssh folders on both client and server

using profile name in each case
3. Amended permissions on UserProfile and .ssh folders to exclude
public
access
4. Set home directories to /home/UserProfile for client and server
user
profiles
5. Within Qshell, generate an RSA key pair using: : ssh-keygen -t rsa
-N
""
6. Copy the public key, id_rsa.pub, from server to client .ssh
directory
7. On the client, add the public key to the authorized_keys file in
.ssh

directory using: using: cat /home/userprofile/.ssh/id_rsa.pub >>
/home/userprofile/.ssh/authorized_keys



Next I attempt to authenticate the public key which is where it fails …



Within Qshell on the client and logged on as the ClientUser



ssh –T ServerUser@serverHost



I get the first-time enquiry message regarding the authenticity of the
host
but when I respond ‘yes’, I get prompted for the password indicating that
the key authentication has failed.

If I key the password, the known_hosts file gets created and I can log on
via SSH ok but I want to use certificates instead of passwords.



Also, I get the following SFTP log (part displayed below) :



sftp -vvv sshxxx@xxxxxxxxxxxxx

Connecting to xx.xx.xxx.xxx

---------------



debug1: Connecting to xxx.xxx.xxx.xxx ^xxx.xxx.xxx.xxx] port 22.

debug1: Connection established.

debug1: identity file /home/sshxxx/.ssh/id_rsa type 1





----------





debug1: SSH2_MSG_SERVICE_ACCEPT
received

debug2: key: /home/sshxxx/.ssh/id_rsa
(200381f0)

debug2: key: /home/sshxxx/.ssh/id_dsa
(0)

debug1: Authentications that can continue:
publickey,password,keyboard-interactive

debug3: start over, passed a different list
publickey,password,keyboard-interactive

debug3: preferred
publickey,keyboard-interactive,password

debug3: authmethod_lookup
publickey

debug3: remaining preferred:
keyboard-interactive,password

debug3: authmethod_is_enabled
publickey

debug1: Next authentication method:
publickey

debug1: Offering public key:
/home/sshxxx/.ssh/id_rsa

debug3:
send_pubkey_test

debug2: we sent a publickey packet, wait for
reply

Connection closed by
xx.xxx.xxx.xxx

Connection closed







Any thoughts?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.