That's weird. It's more or less what I did.
I'm running a BSD/OS 4.3 with OpenSSH 3.4p1.
Client is also an OpenSSH 3.4p1. If I try like you (connecting to localhost)
it leads to the same result.
Here is the debug log with id_dsa and id_dsa.pub.
[...]
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug3: start over, passed a different list
publickey,password,keyboard-interactive
debug3: preferred publickey,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /usr/home/jl/.ssh/id_rsa
debug3: no such identity: /usr/home/jl/.ssh/id_rsa
debug1: try pubkey: /usr/home/jl/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Remote: Forced command: ls
debug1: Remote: Pty allocation disabled.
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 0x100b4560 hint
1
debug2: input_userauth_pk_ok: fp [some key]
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type DSA
debug1: Remote: Forced command: ls
debug1: Remote: Pty allocation disabled.
debug1: ssh-userauth2 successful: method publickey
[executes ls and quits]
Here is the same log after having deleted id_dsa.
[...]
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug3: start over, passed a different list
publickey,password,keyboard-interactive
debug3: preferred publickey,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /usr/home/jl/.ssh/id_rsa
debug3: no such identity: /usr/home/jl/.ssh/id_rsa
debug1: try pubkey: /usr/home/jl/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Remote: Forced command: ls
debug1: Remote: Pty allocation disabled.
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 0x100b4560 hint
1
debug2: input_userauth_pk_ok: fp [same key as above]
debug3: sign_and_send_pubkey
debug3: no such identity: /usr/home/jl/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: next auth method to try is password
jl at marvin's password: [entered password]
debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: ssh-userauth2 successful: method password
[executes ls and quits]
The weird part is when the client is using send_pubkey_test since there is
no key file.
Since the client received the "remote: forced command" part, then the
server
executes it
but it seems it is done before the authentication is successful. I used a
password
so I get the remote command to work with password authentication.
The same happens when I try to connect to localhost.
If I'm mistaken somewhere please tell me.
Thanks.
> I can't mimic this.
>
> You have id_dsa.pub which is your public key and you have id_dsa which is
> your private key.
>
> if I do:
>
> keygen -t dsa
> echo -n "command=\"ls\""; cat id_dsa.pub >>
authorized_keys
> ssh localhost
>
> works as it should, runs the command=""
>
> rm id_dsa
> ssh localhost
>
> prompts for password and then drops me to a login prompt like it should.
>
> - Ben
>
> On Mon, 25 Nov 2002, Jean-Louis LY wrote:
>
> > Hello
> >
> > I think I've found a bug but since no one replied to me on
comp.security.ssh,> > I'll try my luck here.
> > On my client, PreferredAuthentications is set to publickey,password.
> > When using the commands option in authorized_keys file like
> > command="ls" ssh-dss <key>... it is supposed to
connect using the
private key> > associated with <key>, perform ls and then quits.
> > Until here everything is fine.
> > Then I tried to delete the private key file associated to <key>
on my cl
ient.> > Then if I connect, it asks for my password and once I'm logged in,
it
performs> > ls and quits again.
> > So why does it still read the authorized_keys file since I deleted the
key ?> > I looked into it a bit further and I found that the public key file on
my> > client is the one messing up. If I rename it (by default, it is
id_dsa.pub)> > then everything works fine (password authentication and then I'm
logged
in> > with a shell). It seems somehow that the public key file is read no
matter> > what and compares it to the keys found in authorized_keys.
> > So bug or not ?
> >
> > Thanks for your answers.
###########################################
This message has been scanned by Anti-Virus for Microsoft Exchange.