ssh - NO SALE or NO GIVE ?

[mouring at etoh.eviladmin.org]

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