Unable to connect using SFTP

I shall explain the situation that I am facing to the best extent possible. I require some help, as this situation is an urgent one.
I am trying to automate sending data from one AIX machine to another. A script runs that tries to push data received from an upstream application to another AIX system. However, it fails, as SFTP is failing.
To ensure that it is the SFTP step that's failing, I tried to replace the test server with the development server IP, and the SFTP connects, and the data is also transmitted.
Looks like it is something to do with the public/private key exchange. Can anyone help me, to figure out how to resolve this issue.

---------- Post updated 07-11-10 at 01:06 AM ---------- Previous update was 07-10-10 at 08:55 PM ----------

More details on the above scenario

Connecting to <the ip address>
OpenSSH_4.1p1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /home/uvstart/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so): Could not load module /usr/krb5/lib/libkrb5.a(libkrb5.a.so).
System error: No such file or directory

debug1: Error loading Kerberos, disabling Kerberos auth.
debug1: Connecting to <the host name> port 22.
debug1: Connection established.
debug1: identity file /home/uvstart/.ssh/id_rsa type -1
debug1: identity file /home/uvstart/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'host name' is known and matches the RSA host key.
debug1: Found key in /home/uvstart/.ssh/known_hosts:19
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/uvstart/.ssh/id_rsa
debug1: Offering public key: /home/uvstart/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
uvstart@<host name's> password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Connection to <host name> closed by remote host.
debug1: Transferred: stdin 0, stdout 0, stderr 70 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 5106.9
debug1: Exit status -1
Connection closed

Check the remote contents of the authorized_keys file. It should contain a line with the contents of the /home/uvstart/.ssh/id_rsa.pub file on the local side.

Did you login using ssh first there is a key exchange that has to be completed. If that does not work I would look at the user set up and permissions

Did you try manual SFTP to that machine?
If it asks for password, then you must do the key exchange.
Configure the public key of source machine in the destination machine.

I tried that and yes, it asks for the password. Any tip on how to configure the keys would be really helpful. Thanks in advance.

to configure rsa

# ssh-keygen -t rsa

to configure dsa
#ssh-keygen -t dsa

Check this link to setup keys.
HOWTO: set up ssh keys

After setting up you private/public keypair and things still don't work : check the permissions on authorized_keys and the .ssh directory. Make sure the owner matches the user who is logging on and such.