On Sat, 2005-07-02 at 03:58 -0400, Nancy Merckle wrote:
On Sat, 2 Jul 2005, Ralf Corsepius wrote:
> On Fri, 2005-07-01 at 18:21 -0400, Nancy Merckle wrote:
>> On Fri, 1 Jul 2005, Ralf Corsepius wrote:
>>
>>>> "sftp -b <batch> user@somesite" refuses to connect:
>>>>
>>>> # sftp -b upload.ftp user@somesite
>>>> Permission denied (publickey,password,keyboard-interactive).
>>>> Couldn't read packet: Connection reset by peer
>>>>
>>>> While "sftp user@somesite", i.e. interactively using sftp,
works:
>>>> # sftp user@somesite
>>>> Connecting to somesite ...
>>>> Password: ...
>>>>
>>>> ssh and scp access to the same site also works.
>>
>> It looks to me like your keys are out of sync. You may need to
>> update/regenerate them.
> Which keys (key-files) are you referring to?
The password keys... the files that tell the system you are connecting to
that you are a trusted user on a trusted system.
Hmm.
Does "sftp user@somesite" require you to enter a password?
Yes, ...
.. but this set up has worked for years.
.. and it still works interactively.
What has changed with FC4 to cause this issue?
If it does, then system you are using doesn't recognize whatever
"password
file" has been set up for automatic connection. This "password file" can
be set up with ssh keys, or through .netrc. (And maybe other ways too,
these are the only ones I'm familiar with.)
Debugging has led me to this log:
/usr/bin/ssh \
-o "ForwardAgent no" -o "ClearAllForwardings yes" \
-o "batchmode yes" -o "Protocol 2" \
-luser \
-v -s \
somesite \
sftp
(This is the command internally being used by sftp):
OpenSSH_4.0p1, OpenSSL 0.9.7f 22 Mar 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to somesite [212.112.227.138] port 22.
debug1: Connection established.
debug1: identity file /users/user/.ssh/id_rsa type -1
debug1: identity file /users/user/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.8.1p1 Debian-8.sarge.4
debug1: match: OpenSSH_3.8.1p1 Debian-8.sarge.4 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.0
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 'somesite' is known and matches the RSA host key.
debug1: Found key in /users/user/.ssh/known_hosts:9
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: /users/user/.ssh/id_rsa
debug1: Offering public key: /users/user/.ssh/id_dsa
debug1: Authentications that can continue:
publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
Does this ring a bell to somebody?
To me it looks as if the remote site is searching for an rsa key, while
I am only offering a dsa key.
Ralf