On Wed, 2002-02-13 at 12:34, Janyne Kizer wrote: > The line "debug1: authentications that can continue: " was interesting > to me because the "good" server says "debug1: authentications that can > continue: publickey,password" the first time thate message is displayed. > > [root@firstserver root]# ssh -v servername > OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Seeding random number generator > debug1: Rhosts Authentication disabled, originating port will not be > trusted. > debug1: restore_uid > debug1: ssh_connect: getuid 0 geteuid 0 anon 1 > debug1: Connecting to servername [207.4.172.196] port 22. > debug1: temporarily_use_uid: 0/0 (e=0) > debug1: restore_uid > debug1: temporarily_use_uid: 0/0 (e=0) > debug1: restore_uid > debug1: Connection established. > debug1: read PEM private key done: type DSA > debug1: read PEM private key done: type RSA > debug1: identity file /root/.ssh/identity type -1 > debug1: identity file /root/.ssh/id_rsa type -1 > debug1: identity file /root/.ssh/id_dsa type -1 > debug1: Remote protocol version 2.0, remote software version 2.0.13 > (non-commercial) > debug1: match: 2.0.13 (non-commercial) pat ^2\.0\.1[3-9] > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_2.9p2 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client 3des-cbc hmac-md5 none > debug1: kex: client->server 3des-cbc hmac-md5 none > debug1: dh_gen_key: priv key bits set: 189/384 > debug1: bits set: 499/1024 > debug1: sending SSH2_MSG_KEXDH_INIT > debug1: expecting SSH2_MSG_KEXDH_REPLY > debug1: Host 'servername' is known and matches the DSA host key. > debug1: Found key in /root/.ssh/known_hosts2:4 > debug1: bits set: 522/1024 > debug1: len 40 datafellows 74335 > debug1: ssh_dss_verify: signature correct > debug1: kex_derive_keys > debug1: newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: waiting for SSH2_MSG_NEWKEYS > debug1: newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: done: ssh_kex2. > debug1: send SSH2_MSG_SERVICE_REQUEST > debug1: buggy server: service_accept w/o service > debug1: got SSH2_MSG_SERVICE_ACCEPT > debug1: authentications that can continue: > debug1: next auth method to try is publickey > debug1: try privkey: /root/.ssh/identity > debug1: try privkey: /root/.ssh/id_rsa > debug1: try privkey: /root/.ssh/id_dsa > debug1: next auth method to try is password > root@servername's password: > Authenticated with partial success. > debug1: authentications that can continue: > Permission denied, please try again. > root@servername's password: > Authenticated with partial success. > debug1: authentications that can continue: > Permission denied, please try again. > root@servername's password: > Authenticated with partial success. > debug1: authentications that can continue: > debug1: next auth method to try is keyboard-interactive > debug1: authentications that can continue: > debug1: authentications that can continue: > debug1: authentications that can continue: > debug1: no more auth methods to try > Permission denied (). > debug1: Calling cleanup 0x8063570(0x0) > [root@firstserver root]# > > > Edward Marczak wrote: > > > > On 2/12/02 2:45 PM, "Janyne Kizer" [EMAIL PROTECTED] pressed the keys > > forming the message: > > > > > hmmm, I am having a similar problem. > > > > > > What does "Authenticated with partial success" mean? > > > > Dunno - could it be failing it's first auth type, and falling back to the > > next (e.g. Trying ssh2, then falling back to 1). Could you throw this into > > verbose mode? > > -- > > Ed Marczak > > [EMAIL PROTECTED] > > > > _______________________________________________ > > Redhat-list mailing list > > [EMAIL PROTECTED] > > https://listman.redhat.com/mailman/listinfo/redhat-list >
I got curious and went googling. Apparently you can specify multiple authentication methods that must be completed sucessfuly before a session is initiated. AFAICT the state of the authentication process is partial success when one or more of the methods have been met but there is still more that are required. Now as to how to specify that more than on method is required (as opposed to allowed) I have not tried to figure that out yet. Has anyone looked in the man pages? from the openssh mailing list archive: List: openssh-unix-dev Subject: Re: PAM & several passwords From: Balazs Scheidler <[EMAIL PROTECTED]> Date: 2001-03-12 19:05:29 [Download message RAW] > Is there any hope getting openssh to support a sequence > of several authentication methods (requiring different > passwords) for one login? > I.e. take the standard static password, feed it into > pam_unix.so for verification, then ask the user for yet > another password (e.g. a one-time password) and verify > this one by a different PAM module > Currently, verifying either a static password or a one > time password both work nicely, but knowing the > weaknesses of both methods, I'd like to require both > static _and_ one time password... > Seems like quite a problem to get a message back to the > user and obtain some additional input from him, but > then, I'm not an ssh-expert, so I might be missing > something obvious. The SSH2 protocol has support for this in its authentication protocol: 2.2. Responses to Authentication Requests If the server rejects the authentication request, it MUST respond with byte SSH_MSG_USERAUTH_FAILURE string authentications that can continue boolean partial success ... "Partial success" MUST be true if the authentication request to which this is a response was successful. It MUST be false if the request was not successfully processed. _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
