Thanks to everyone who has replied to my emails so far - to summarise: AIX allows setting of rlogin=false and and a su group, or a list of users that are permitted to "su" to root. ( or other functional ids ) This means with entries in /etc/ftpusers, it is possible to : 1/ Track who used root via sulog and or external logging 2/ Protect root even if the root password is compromised 3/ Limit to a list of users who can access root To acheive the functional equivalent of this in ssh we require: rlogin still false to stop telnet connections, but ssh still allowing connections A set of allowed_keys that effectively would be an su group A tracking by ssh of which key allowed access at connection time ( ie an sulog equivelent ) ie: "ssh: root access granted via key joeblow at jupiter at 12:34" It is then possible for me to demonstrate to management that we do not require every admin to have an account on every system ( every one represents a security problem ) but all we require ist ssh with a set of keys - we can then also centralise key managent for administrators, also that ssh respects security guidelines. IF I cannot solve this problem, then ssh is NOT PERMITTED on IBM systems and IBM Customers which IBM supports via service contracts - this would be a pity. rlogin=false is used by AIX systems to block only interactive sessions, ie rlogin and telnetd, but allows rsh and rcp as they are not interactive. Obvisously this makes NO sense at all, and anyway you can always use X or such to generate an interactive session, but that is the way AIX works, rightly or wrongly. Is there ANY way AROUND this ? SFTP Really needs to have a /etc/ftpusers file to provide a simple blocking mechnism for ftp. BUGS If rlogin=false then ssh still prompts for password, although it already knows access will be denied.
On Sun, 20 May 2001 mark.pitt at ch.ibm.com wrote: [snip]> "ssh: root access granted via key joeblow at jupiter at 12:34" > > It is then possible for me to demonstrate to management that we do not > require every admin to have an account on every system ( every one > represents a security problem ) but all we require ist ssh with a set of > keys - we can then also centralise key managent for administrators, also > that ssh respects security guidelines. > > IF I cannot solve this problem, then ssh is NOT PERMITTED on IBM systems > and IBM Customers which IBM supports via service contracts - this would be > a pity. > > rlogin=false is used by AIX systems to block only interactive sessions, ie > rlogin and telnetd, but allows rsh and rcp as they are not interactive. > Obvisously this makes NO sense at all, and anyway you can always use X or > such to generate an interactive session, but that is the way AIX works, > rightly or wrongly. > > Is there ANY way AROUND this ?Is PermitRootLogin=without-password not enough? Admittably that might still be holey if shosts.equiv, .shosts etc. logins are still allowed with SSHv1; before OpenSSH 2.9 when HostBased auth for v2 wasn't there yet, this was the case in general. Is there too big a difference to enhancing PermitRootLogin so that features in 'without-passwords' and 'forced-commands-only' would be mixed (ie: 'publickey-only').> SFTP > > Really needs to have a /etc/ftpusers file to provide a simple blocking > mechnism for ftp.Note that standard BSD ftpd also checks for /etc/ftpusers. Some might want to separate sftp and ftpd.> BUGS > > If rlogin=false then ssh still prompts for password, although it already > knows access will be denied.This is a feature, IMO. Else you could go scanning hosts with 'ssh root at somewhere' to check which ones have rlogin=false set. The authentication must look transparent until the user has been authenticated. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
On Sun, 20 May 2001 mark.pitt at ch.ibm.com wrote:> > > > Thanks to everyone who has replied to my emails so far - to summarise: > > AIX allows setting of rlogin=false and and a su group, or a list of users > that are permitted to "su" to root. ( or other functional ids ) > This means with entries in /etc/ftpusers, it is possible to : > > 1/ Track who used root via sulog and or external logging > 2/ Protect root even if the root password is compromised > 3/ Limit to a list of users who can access root > > To acheive the functional equivalent of this in ssh we require: > > rlogin still false to stop telnet connections, but ssh still allowing > connections > A set of allowed_keys that effectively would be an su group > A tracking by ssh of which key allowed access at connection time ( ie an > sulog equivelent ) ie: > > "ssh: root access granted via key joeblow at jupiter at 12:34" > > It is then possible for me to demonstrate to management that we do not > require every admin to have an account on every system ( every one > represents a security problem ) but all we require ist ssh with a set of > keys - we can then also centralise key managent for administrators, also > that ssh respects security guidelines. > > IF I cannot solve this problem, then ssh is NOT PERMITTED on IBM systems > and IBM Customers which IBM supports via service contracts - this would be > a pity. >I still don't get where "PermitRootLogin no" fails.. Give each admin a normal user account and the correct group privs for 'su'. Like every other UNIX in the world. I don't see how 'multiple private keys to an account where passwords are not accepted' is any more secure nor managable.> rlogin=false is used by AIX systems to block only interactive sessions, ie > rlogin and telnetd, but allows rsh and rcp as they are not interactive. > Obvisously this makes NO sense at all, and anyway you can always use X or > such to generate an interactive session, but that is the way AIX works, > rightly or wrongly. > > Is there ANY way AROUND this ? >Your going against what you said above. WHY allow interactice session via keys if you deny the password? I would personally feel (I'm not an AIX user/admin) if you set 'rlogin=false' you may as well do 'PermitRootLogin no'. And ban all forms of direct root login. How does IBM deal with cases where ssh or such tools don't exist?> SFTP > > Really needs to have a /etc/ftpusers file to provide a simple blocking > mechnism for ftp. >I'd like to see such a feature in the future, but I really don't like the idea of overload /etc/ftpusers proper. I can think of a few cases where ftp and ssh/sftp must live side-by-side. And one may wish to assign different restrictions to each.> BUGS > > If rlogin=false then ssh still prompts for password, although it already > knows access will be denied. >No.. This is *NOT* a bug. This is the correct thing. SSH should *ALWAYS* prompt for passwords. If it accepts them or not is a different story. Same is true for S/key and any password based system authentication systems. The same holds true for 'telnet' or any other such service. Let the non-authorized user spin his/her wheels trying to enter passwords until they are blue in their face. Don't give them a reason to think 'root' account is setup any differently. - Ben
On Sun, May 20, 2001 at 10:48:20AM +0200, mark.pitt at ch.ibm.com wrote:> rlogin=false is used by AIX systems to block only interactive sessions, ie > rlogin and telnetd, but allows rsh and rcp as they are not interactive. > Obvisously this makes NO sense at all, and anyway you can always use X or > such to generate an interactive session, but that is the way AIX works, > rightly or wrongly. > > Is there ANY way AROUND this ?for ssh there is no difference between rlogin and rsh. the only thing you could do is disallow allocation of pty's this is only possible with pubkey auth + options in .ssh/authorized_keys*> SFTP > > Really needs to have a /etc/ftpusers file to provide a simple blocking > mechnism for ftp.make people think sftp is something like ftp, but it is not. it's just some application running over ssh. ssh host /bin/date does not check /etc/ftpusers, too. sftp could me changed to behave like ftp, but currenlty it's no different from ssh host /bin/date> BUGS > > If rlogin=false then ssh still prompts for password, although it already > knows access will be denied.this is not a bug.
On Sun, May 20, 2001 at 10:48:20AM +0200, mark.pitt at ch.ibm.com wrote:> IF I cannot solve this problem, then ssh is NOT PERMITTED on IBM systems > and IBM Customers which IBM supports via service contracts - this would be > a pity.why don't you just set PermitRootLogin no ?