I was looking at the "OpenSSH on AIX" project patches on sourceforge, and was interested to see this issue: On AIX, you can set 'rlogin=false' on particular users and deny them remote shell access. OpenSSH supports that. However, sftp is still a desirable service to access, and is not considered a remote shell. Currently, openssh denies any user with rlogin=false set. The abbreviated patch below shows how the check was changed in the openssh-aix project to support session and not subsystem denial. (not shown is the global int rlogin): --- openssh-4.3p2/openbsd-compat/port-aix.c Sat May 28 19:54:28 2005 +++ 52/openbsd-compat/port-aix.c Sun May 14 05:19:43 2006 @@ -231,231 +231,234 @@ debug3("%s: not checking", __func__); return 1; } + if (getuserattr(pw->pw_name, S_RLOGINCHK, &rlogin, SEC_BOOL) == -1) + rlogin=1; - result = loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &msg); + result = loginrestrictions(pw->pw_name, 0, NULL, &msg); if (result == 0) permitted = 1; /* --- openssh-4.3p2/session.c Tue Feb 7 17:18:55 2006 +++ 52/session.c Sun May 14 05:19:16 2006 @@ -660,532 +666,672 @@ debug("Forced command '%.900s'", command); } + /* if remote login is set to false in "/etc/security/user", + you should still be able to "sftp" but not "ssh" */ + if (!rlogin) { + if (!s->is_subsystem) + packet_disconnect("Remote login for account %.100s is not allowed.", s->pw->pw_name); + } + #ifdef SSH_AUDIT_EVENTS if (command != NULL) PRIVSEP(audit_run_command(command)); (Source: http://sourceforge.net/project/showfiles.php?group_id=127997&package_id=144624&release_id=482265 ) I know that the above is an ugly solution and doesn't consider other subsystem types (that may be session-like), but thought it would be worth adding into bugzilla ... maybe someone can see a clean way of supporting this. (openssh-aix's patch is actually buggy as described at: "Bypasses rlogin=false" at http://sourceforge.net/tracker/index.php?func=detail&aid=1346058&group_id=127997&atid=710254 and "sftp login allowed when rlogin=false" at http://sourceforge.net/tracker/index.php?func=detail&aid=1552074&group_id=127997&atid=710254 )
Just thought it could be useful to review the current situation. re: (openssh-aix's patch is actually buggy as described at: "Bypasses rlogin=false" at http://sourceforge.net/tracker/index.php?func=detail&aid=1346058&group_id=127997&atid=710254) This is not an openssh (aix patch bug) - it works as designed. a) by default, for all users other than root "rlogin=false" blocks a user from logging in using openssh. b) by design, the default behavior for root is to look at the combination of PermitRootLogin (default yes) and UseLogin (default no) * When both are at default, root login is permitted. * When rlogin=false (for root) and UseLogin=true - login is not permitted * When PermitRootLogin=no - login by root is not permitted So, perhaps a documentation update in the AIX section, if it exists, reminding/pointing at UseLogin is an improvement. re: "sftp login allowed when rlogin=false" at http://sourceforge.net/tracker/index.php?func=detail&aid=1552074&group_id=127997&atid=710254 This could still be considered a bug. If you follow the link - a successful connection via sftp is permitted IF an active ftp connection would also be successful. On AIX, ftp does not look at /etc/security/users rlogin setting - instead it is looking at /etc/ftpusers. Currently on AIX, when /etc/ftpusers contains "root", root is not permitted to connect. Not even the password is requested. Denial is immediate. Using sftp - * when PermitRootLogin=no - connection is denied - per design * when PermitRootLogin=yes, regardless of UseLogin setting and /etc/ftpusers content - root access is permitted. The "bug" is that sftp is not (also) examining /etc/ftpusers - to mimic ftp behavior - which seems to be the expectation of the aix-patch discussion from the link above.
p.s. re: sftp ignoring /etc/ftpusers. Question: is this by design? If not, is this something unexpected for all systems?
It seem that the remaining item of this report is OpenSSH not honouring FTP-specific control files in /etc. IMO this is a misconception because OpenSSH sftp is not related to FTP being being a file transfer protocol. We do not intend to implement support for legacy-FTP related control files in OpenSSH, though administrators may chose to do so via PAM or other similar mechanisms.
closing resolved bugs as of 8.6p1 release