SFTP Login Prompt

[UNIX_WIZ]

Hello all,

I am kinda stuck here. We've been doing wonderful all these days and something happened all of a sudden that caused SFTP to prompt for a password.

To give some background, We use SFTP to connect our partners. As we use RSA key authentication, to automate the SFTP script, we ask our partners to create user IDs without password. So, when I login for the first time, it always asks me if I want to add the foot print of our partner's server and once I hit 'yes', it takes me to the SFTP> prompt.

But, today, when I login to a new SFTP connection, it asks for adding footprint. If I say 'yes', it says footprint successfully added and then it asks for password for my own userID@partners-ftp-site.com. Now, it asks for all the partners. Not only new ones but to already existing connections that were working perfectly all these days.

Help me here, please.

Thank you.

[Mel Burslan]

assuming you are on a HPUX server, let's say logged in as user1

ls -ld ~user1/.ssh

does it have the right ownership and permissions ? It needs to be owned by user1 and group should be user1's default group

cd ~user1/.ssh

do you have your RSA private key file in there and it only has permissions for you and nobody else, i.e., 400, 600 or 700 permissions are allowed nothing more. Also make sure user1 is the owner of these files.

[Steven Schweda]

As usual with SSH/SFTP problems, it can be
helpful to get some information from the
client program by adding "-v" to its command
line.

Also as usual, showing actual commands with
their actual output can be more useful than
vague descriptions and interpretations.

[UNIX_WIZ]

Hello... thank you for the prompt response. You can find below the output from SFTP with -v option. Just to protect the identity, I had to change the actual IP address to 'IPAddress' and also the actual user ID to 'UserID'. Everything else remains the same. Just for your information, we have two SFTP systems one for TEST and the other for Live Production environment. Everything was working fine until yesterday and all of a sudden today, this problem showed up with all the partners setup in both the TEST and Production environments.

Hostname:UserID 8> sftp -v IPAddress
Connecting to IPAddress...
OpenSSH_3.8, OpenSSL 0.9.7d 17 Mar 2004
HP-UX_Secure_Shell-A.03.81.002, HP_UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to IPAddress [IPAddress] port 22.
debug1: Connection established.
debug1: identity file /usr/sap/users/UserID/.ssh/id_rsa type 1
debug1: identity file /usr/sap/users/UserID/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8
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 'IPAddress' is known and matches the RSA host key.
debug1: Found key in /usr/sap/users/UserID/.ssh/known_hosts:8
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: Offering public key: /usr/sap/users/UserID/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: /usr/sap/users/UserID/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:

[Steven Schweda]

> [...]
> debug1: Next authentication method: publickey
> debug1: Offering public key: /usr/sap/users/UserID/.ssh/id_rsa
> debug1: Authentications that can continue: publickey,password,keyboard-interactive
> debug1: Offering public key: /usr/sap/users/UserID/.ssh/id_dsa
> debug1: Authentications that can continue: publickey,password,keyboard-interactive
> debug1: Next authentication method: keyboard-interactive
> [...]

Apparently (to me), this says that UserID has
both ~/.ssh/id_rsa and ~/.ssh/id_dsa keys,
and the other guy doesn't like either of
them.

> [...] Not only new ones but to already
> existing connections that were working
> perfectly all these days.

Bad/wrong/different key files on your end
could account for problems with all the
remote systems. Any chance that you had been
specifying some non-default identity before?

ls -l /usr/sap/users/UserID/.ssh

[UNIX_WIZ]

Hi Steven,

Thank you for your quick response. Yes, recently a week ago generated the DSA key pair as well. Even after that everything was working fine till yesterday. We didn't make any changes since yesterday. Infact, DSA keys are not generated in production box. Till a week ago all our partners were communicating with us only using the RSA pair. We haven't distributed the DSA version to anybody yet. So, we can rule out the DSA.

Now, my other question is, is by any chance can there be expiration date to ssh keys like we have for the PGP keys? Could any changes to the network might cause this? There were no changes but, just wanted to confirm. What other possibilities do you think that could affect both the boxes at the same time? What surprises me is that, both boxes are completely separated. I don't see anything common between them. They don't share common resources. I am completely confused here. Is there any other log that could give better picture of the problem? Let me know. Thank you.

[UNIX_WIZ]

Guys... here's an update with little more background. The solution to this could be really silly. Let me know if something rings a bell in you.

The problem seems to occur only when trying interactively at command prompt. To give you some more background. We run scripts to get files from our partner sites through SFTP. This script again uses the same UserID that I use interactively. So, there is no change in the user ID between trying interactively and trying through scripts. But, I have no idea why. When I try at the command prompt, I only see that it asks for password (which I sent you before as a verbose output) but, when I try the same with scripts, it works like a charm.

If this rings a bell in any of you, please let me know.

Once again thank you for all the efforts and help.

[Steven Schweda]

> [...] So, we can rule out the DSA.

Then you might move "id_dsa" out of the way.
(So things can fail slightly faster.)

> [...] is by any chance can there be
> expiration date to ssh keys like we have
> for the PGP keys?

It'd be news to me. "man ssh-keygen"?

> [...] a week ago generated the DSA key pair
> as well. [...]

> ls -l /usr/sap/users/UserID/.ssh

I'd be happier if I knew that the RSA key
data were old. If you regenerated them, too,
then ...

> [...] Is there any other log that could
> give better picture of the problem?

Perhaps some log file on the server end would
say something.

Can you set up one of your own systems to act
as a pseudo-partner system? That would let
you look more easily at both ends of the
transaction.

If you do a forum search for SSH problems,
you can find lots of examples of totally
defective key files (SSH2 format instead of
OpenSSH, and so on), bad ownership, bad
permissions, and so on, but everything on the
client here looks good, except that the key
data are not being accepted by the server, so
it moves on to ask for a keyboard-interactive
password. Easiest explanation is that the
client's key data differ from those on the
server(s).

[UNIX_WIZ]

Regenerating the keys resolved the issue. Thank you all (Steven in particular) for your time and help.

[UNIX_WIZ]

Regenerating keys resolved the problem.