I have recently installed V3.4 on our test machines and now find that I can no longer scp files to accounts where the account has remote logins disabled. We use root account to do various management commands on remote machines and now find that this also no longer works. We use Public Key authentication and previously our key was accepted whether the account was disabled for remote logins or not but this is no longer the case. The debug output looks like this (Solaris8 OpenSSH V34 client to AIX43 openSSH V34 server) Connection from xxx.xxx.xxx.xxx port nnnn debug1: Client protocol version 2.0; client software version OpenSSH_3.4p1 debug1: match: OpenSSH_3.4p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.4p1 debug3: privsep user:group 323:4294967294 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug2: Network child is on pid 6280 debug3: preauth child monitor started debug3: mm_request_receive entering debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 2048 8192 debug3: mm_request_send entering: type 1 debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug1: dh_gen_key: priv key bits set: 119/256 debug1: bits set: 1552/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1613/3191 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_answer_sign: signature 20038b08(143) debug3: mm_request_send entering: type 5 debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent 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: KEX done debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow Login restricted for root: 3004-306 Remote logins are not allowed for this account. debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 0 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: mm_request_receive entering input_userauth_request: illegal user root debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug2: input_userauth_request: try method none Failed none for illegal user root from xxx.xxx.xxx.xxx port 45624 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 1 failures 1 debug2: input_userauth_request: try method publickey debug2: userauth_pubkey: disabled because of invalid user Failed publickey for illegal user root from xxx.xxx.xxx.xxx port 45624 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 2 failures 2 debug2: input_userauth_request: try method publickey debug2: userauth_pubkey: disabled because of invalid user Failed publickey for illegal user root from xxx.xxx.xxx.xxx port 45624 ssh2 debug1: userauth-request for user root service ssh-connection method keyboard-in teractive debug1: attempt 3 failures 3 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=root devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for illegal user root from xxx.xxx.xxx.xxx port nnnnn ssh2 Connection closed by xxx.xxx.xxx.xxx debug1: Calling cleanup 0x2002a790(0x0) debug1: Calling cleanup 0x2002a790(0x0)
what does "rlogin set to false" mean?
On an AIX system,if chuser rlogin=false <account> is set then it is no longer possible using PublicKeyAuthentication to issue ssh <command> or scp using that account. We need to be able to do this.
My suggestion is the following (since I'm not 100% up to speed on AIX). do sshd -d -d -d with rlogin=false then return it with rlogin=true. Diff the two and hopefully that will narrow down the differences. - Ben
Here's the reason from the log: "Login restricted for root: 3004-306 Remote logins are not allowed for this account." What version are you upgrading from? All versions I checked back to 2.1.1p4 contained the following test in auth.c: if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0) { [snip] log("Login restricted for %s: %.100s", pw->pw_name, loginmsg); } To me it seems to be working like it should: if you disable remote logins you can't log in remotely.
Ah, I think I know why you're seeing it now. Were your previous binaries compiled on AIX 4.2 perchance? The loginrestrictions() test is wrapped inside "#ifdef WITH_AIXAUTHENTICATE". Configure defines that if it can find the function "authenticate". On 4.2, authenticate it in libs.a. On 4.3, it's in libc.a. Configure didn't check in libs.a. The upshot is if you compile 3.4p1 or below on AIX 4.2, WITH_AIXAUTHENTICATE doesn't get defined and the loginrestrictions() test doesn't get compiled in. In -cvs, configure has been fixed to look in libs.a if necessary, so behaviour will be consistent between AIX versions. The quick way to get the behaviour you want is to set "#define WITH_AIXAUTHENTICATE 0" in config.h after running configure, then recompile. This is probably not a long-term solution as it also disables other things (eg lockout on bad logins and logging of succcesful logins). You may need to rethink your strategy.
We do not use password authentication for this account. On HP,OSF/1 and Solaris machines,if root account is set to only login on the console,then we authenticate in the normal way (using PublicKeyAuthentication) and can then issue ssh <command> or scp using root account on that machine. It is only with AIX that we see this being rejected. Is there a particular reason why AIX is unique in this behaviour ? Thanks.
This ist my Workaround: --- auth.c.orig Wed Oct 3 19:55:27 2001 +++ auth.c Mon Nov 12 10:43:49 2001 @@ -158,7 +158,7 @@ } #ifdef WITH_AIXAUTHENTICATE - if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0) { + if ((pw->pw_uid != 0) && (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0)) { if (loginmsg && *loginmsg) { /* Remove embedded newlines (if any) */ char *p; Not accepted by OpenSSH-developers, but what most AIX-Admins seem to need: Close out root by all AIX-means, but let him in by ssh-only...
The more I think about it, the more I like Jörg's uid != 0 patch. Other platforms implement their own login controls for root (eg /etc/securetty or /etc/default/login) and sshd ignores them in favour of its own mechanism (PermitRootLogin). I'm in favour of the patch. If required, you can still disable root logins via ssh by setting "PermitRootLogin no". What's the argument against it?
commited
Mass change of RESOLVED bugs to CLOSED