Questions regarding SFTP and SSH certificates

[Paul Maglinger]

I'm running into what I see to be a mess with SFTP to another company.  We want to be able to use SFTP without authentication, so I created public keys and sent those over to them.  Everything worked for awhile and then stopped.  It began asking for a password again and the other company asked that I resend the public keys.  I did, but it made no difference.  It's still prompting for password.  Searching around, I found reference where I could delete the entry from the known_hosts file and it would prompt for the key again.  The trouble is that there are more than one entries in the known_hosts file and I don't see a way to determine which is the offending entry.  I have thought about generating another key, but don't understand if the new key would be the same as the old one, or completely different.  My fear is that if I generate another key that the other SFTP sites that we are using would stop working.  Can someone shed some light on SSH certificates and SFTP?

[Jeff_Traigle]

The key that is inserted in known_hosts is the host key. From the description you've given, that doesn't appear to be the problem. It sounds like a server-side issue. They've done any number of things that could result in the key authentication failure, reverting back to keyboard-interactive. Permissions could be too lax on the .ssh directory or on the authorized_keys file... they could have changed the configuration to look for authorized keys in a different file than where they are saving the keys... they could have disabled public key authentication entirely in sshd_config...

Some clues might be obtained by getting verbose output from sftp with the -v option.

[Paul Maglinger]

-v gives the following:

(server:myuser)[/user01/myuser] sftp -v mycompany@ftp.theircompany.com
Connecting to ftp.theircompany.com...
OpenSSH_4.5p1+sftpfilecontrol-v1.1-hpn12v14, OpenSSL 0.9.7l 28 Sep 2006
HP-UX Secure Shell-A.04.50.021, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to ftp.theircompany.com [###.###.###.###] port 22.
debug1: Connection established.
debug1: identity file /user01/myuser/.ssh/id_rsa type 1
debug1: identity file /user01/myuser/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Remote is NON-HPN aware
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5p1+sftpfilecontrol-v1.1-hpn12v14
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 'ftp.theircompany.com' is known and matches the RSA host key.
debug1: Found key in /user01/myuser/.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,gssapi-keyex,gssapi-with-mic,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /user01/myuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive
debug1: Offering public key: /user01/myuser/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:

So what I'm seeing is that it's trying the id_rsa.pub key, then the id_dsa.pub key, and both of them failing then asking for the password from the keyboard?  I have resent those keys to them, but this still fails.  So it's a problem on their side, correct?

[boukari]

Hello,

Do you using ' Passphrase ' when u creating the ssh key ?

generally , when we use passphrase, even authentification succeed u need anytime to type passphrase to access.

for more information take a look in attached doc .

automated SFTP

Regards,

[Paul Maglinger]

No passphrase was used in the generation of these keys.

[Paul Maglinger]

Yep.  Sent both files to them.  So...  If I generate new keys on my end they will be different that the first keys, or is key generation based on some system constant and will be the same as the first?

[Patrick Wallek]

Have them check the logs on the remote system.  That should also provide some clues.  From what has been described, I don't think the problem is with your keys.

[Paul Maglinger]

Initially when we were setting this up we had problems.  We tried rsa and then dsa.  We just left them in place.

Thanks for the help Steven.

On another note, why are your responses showing up as attachments?

[Dennis Handly]

>And the the wizards at HP get all trendy and stuff.

I would expect these aren't wizards but accountants.  ;-)

[Paul Maglinger]

As none of our other vendors seem to be having a problem except this one, and based on the information gathered from above, I'm saying the problem is definitely on their end. I'm still wondering if I create new keys are they truly "new" as in "different", or will it just regenerate the same keys as before?

[Paul Maglinger]

Might be awhile before I could free up a test system to try it on.  Just thought someone might know off the top of their head.

[Dennis Handly · Accepted solution]

>Might be awhile before I could free up a test system to try it on.

It shouldn't take up that much time, even on a production server.

Also Steven's comment about 'some "random" number stuff' rings true.

[Paul Maglinger]

Thanks to all for the clarification on this subject.