The thing is, I have four servers that are set up exactly the same way (copied from tape) and three of them work fine. This one does not. I have confirmed that the files in /etc/ssh are exactly the same size and date. I thought that was were the configuration info for SSH was stored but maybe not? Anyway, it's very puzzling. Of cousre it's not the server that is 45 minutes away that is problematic, it is the one that is 4+ hours away that is giving us grief :-(
The other thing that we have found (may be related) is that we cannot ping this server from our subnet but we can ping the other three. The firewall files are the same (well, local subnet numbers are differnt but essentially they are the same) and iptables -L yields similar results (the same except for one subnet number and the server's ip). From the troublesome server: workingsunserver ~ 209> ping troublesome.ces.state.nc.us ICMP Time exceeded in transit from 172.28.1.3 for icmp from workingsunserver.ces.state.nc.us (207.4.yyy.xxx) to troublesome.ces.state.nc.us (152.31.244.69) ICMP Time exceeded in transit from 172.28.1.3 for icmp from workingsunserver.ces.state.nc.us (207.4.yyy.xxx) to troublesome.ces.state.nc.us (152.31.244.69) ICMP Time exceeded in transit from 172.28.zzz.bbb for icmp from workingsunserver.ces.state.nc.us (207.4.yyy.xxx) to troublesome.ces.state.nc.us (152.31.yyy.xxx) ICMP Time exceeded in transit from 172.28.zzz.bbb for icmp from workingsunserver.ces.state.nc.us (207.4.yyy.xxx) to troublesome.ces.state.nc.us (152.31.yyy.xxx) ICMP Time exceeded in transit from 172.28.zzz.bbb for icmp from workingsunserver.ces.state.nc.us (207.4.yyy.xxx) to troublesome.ces.state.nc.us (152.31.yyy.xxx) Bret Hughes wrote: > > 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 -- Janyne Kizer CNE-3, CNE-4, CNE-5 Systems Programmer Administrator I NC State University, College of Agriculture & Life Sciences Extension and Administrative Technology Services Phone: (919) 515-3609 _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
