Does anyone know of a way to disable the ability of certain users from 
using telnet to access a server?

google for "TCP Wrappers"

On Mon, 23 May 2005, Robert Johnson wrote:

> Does anyone know of a way to disable the ability of certain users from
> using telnet to access a server?

Why not just disable telnet, period?  Telnet is evil!

-- 
Rich Teer, SCNA, SCSA, OpenSolaris CAB member

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

Rich Teer sez:
> On Mon, 23 May 2005, Robert Johnson wrote:
> 
>> Does anyone know of a way to disable the ability of certain users from
>> using telnet to access a server?
> 
> Why not just disable telnet, period?  Telnet is evil!

Telnet doesn't stop working when DNS server goes down,for one
thing. Telnet doesn't waste cpu cycles on encrypting traffic
that needn't be encrypted. With telnet you don't have to press
enter - ~ - . to logout if you ran a background job in the
terminal in some distant past. With telnet, applications that
remap their own stdout don't segfault. Etfc.

Dima
-- 
Riding roughshod over some little used trifle like the English language is not a
big deal to an important technology innovator like Microsoft. They did just that
by naming a major project dot-Net (".Net").  Before that, a period followed by a
capital letter was used to mark a sentence boundary. --T. Gottfried, RISKS 21.91

On Mon, 23 May 2005 22:29:14 +0000, Rich Teer wrote:

> On Mon, 23 May 2005, Robert Johnson wrote:
> 
>> Does anyone know of a way to disable the ability of certain users from
>> using telnet to access a server?
> 
> Why not just disable telnet, period?  Telnet is evil!

These Windose using people have a telnet client available within their
so-called OS but no SSH client.  Many of them also have a corporate policy
of disallowing the installation of FREE software such as PuTTY.  To them
your entirely correct recommendation is not an option.

Neither do these people recognize that assigning /usr/bin/false as the
shell for their selected users is the usual and correct method for
accomplishing their purpose.  Indeed, the last Windose user with the same
question told us to f**k ourselves after being given the answer.

Assigning a shell of /usr/bin/false to the undesirable users still permits
full ftp, smtp, nfs, pop3 and imap access by those users; i.e., they still
have full access to the server except for the ability to login to a shell.

In article <pan.2005.05.23.23.43.56.692371@yahoo.com>,
 Dave Uhring <daveuhring@yahoo.com> wrote:

> On Mon, 23 May 2005 22:29:14 +0000, Rich Teer wrote:
> 
> > On Mon, 23 May 2005, Robert Johnson wrote:
> > 
> >> Does anyone know of a way to disable the ability of certain users from
> >> using telnet to access a server?
> > 
> > Why not just disable telnet, period?  Telnet is evil!
> 
> These Windose using people have a telnet client available within their
> so-called OS but no SSH client.  Many of them also have a corporate policy
> of disallowing the installation of FREE software such as PuTTY.  To them
> your entirely correct recommendation is not an option.
> 
> Neither do these people recognize that assigning /usr/bin/false as the
> shell for their selected users is the usual and correct method for
> accomplishing their purpose.  Indeed, the last Windose user with the same
> question told us to f**k ourselves after being given the answer.
> 
> Assigning a shell of /usr/bin/false to the undesirable users still permits
> full ftp, smtp, nfs, pop3 and imap access by those users; i.e., they still
> have full access to the server except for the ability to login to a shell.

Since the original request was to just disable telnet access for 
specific users (no mention of ftp, smtp, nfs, pop3, imap or any other 
services), what's wrong with the standard solution proposed (/bin/false 
shell)?  There are ways to disable ftp, nfs, or ssh/sftp access.  I'm 
not familiar with pop3 or imap enough to know if they have separate 
authentication from /etc/passwd.

Since we can't disable connections based on IP address, login username 
is all that's left for authentication.  The /bin/false shell solves that 
problem.  Why isn't this acceptable as a solution?  Have I missed some 
unspoken requirement?

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

On Mon, 23 May 2005 23:45:53 -0700, Michael Vilain wrote:

> Since we can't disable connections based on IP address, login username 
> is all that's left for authentication.  The /bin/false shell solves that 
> problem.  Why isn't this acceptable as a solution?  Have I missed some 
> unspoken requirement?

The moron who told us to f**k ourselves gave no reason for rejecting that
solution to his problem.

u could use passwd -l username to lock the user for time being

Let me attempt to clarify what I am asking.

I have a database owner that is required by Informix, the database we 
use. To do certain things you have to become that user, so the account 
needs to be able to be logged in to.

My desire is to only allow that account to log in either on the console, 
like root is setup, or from an su command while someone else is logged 
in. Right now I can telnet to the server and login as the database user 
directly just like any other user. If I change their "shell" to 
/bin/false that account will not be allowed any access, just as if I had 
locked it. My preference, if possible, is to not have to lock and unlock 
the account, which takes my intervention every time it is needed.

I am looking at ownership/permissions to help, but removing remote 
telnet access, like root, would be even better.

Hope that clears up a bit more of what I am trying to accomplish.


Michael Vilain wrote:

> In article <pan.2005.05.23.23.43.56.692371@yahoo.com>,
>  Dave Uhring <daveuhring@yahoo.com> wrote:
> 
> 
>>On Mon, 23 May 2005 22:29:14 +0000, Rich Teer wrote:
>>
>>
>>>On Mon, 23 May 2005, Robert Johnson wrote:
>>>
>>>
>>>>Does anyone know of a way to disable the ability of certain users from
>>>>using telnet to access a server?
>>>
>>>Why not just disable telnet, period?  Telnet is evil!
>>
>>These Windose using people have a telnet client available within their
>>so-called OS but no SSH client.  Many of them also have a corporate policy
>>of disallowing the installation of FREE software such as PuTTY.  To them
>>your entirely correct recommendation is not an option.
>>
>>Neither do these people recognize that assigning /usr/bin/false as the
>>shell for their selected users is the usual and correct method for
>>accomplishing their purpose.  Indeed, the last Windose user with the same
>>question told us to f**k ourselves after being given the answer.
>>
>>Assigning a shell of /usr/bin/false to the undesirable users still permits
>>full ftp, smtp, nfs, pop3 and imap access by those users; i.e., they still
>>have full access to the server except for the ability to login to a shell.
> 
> 
> Since the original request was to just disable telnet access for 
> specific users (no mention of ftp, smtp, nfs, pop3, imap or any other 
> services), what's wrong with the standard solution proposed (/bin/false 
> shell)?  There are ways to disable ftp, nfs, or ssh/sftp access.  I'm 
> not familiar with pop3 or imap enough to know if they have separate 
> authentication from /etc/passwd.
> 
> Since we can't disable connections based on IP address, login username 
> is all that's left for authentication.  The /bin/false shell solves that 
> problem.  Why isn't this acceptable as a solution?  Have I missed some 
> unspoken requirement?
> 

> Michael Vilain wrote:
> 
> > In article <pan.2005.05.23.23.43.56.692371@yahoo.com>,
> >  Dave Uhring <daveuhring@yahoo.com> wrote:
> > 
> > 
> >>On Mon, 23 May 2005 22:29:14 +0000, Rich Teer wrote:
> >>
> >>
> >>>On Mon, 23 May 2005, Robert Johnson wrote:
> >>>
> >>>
> >>>>Does anyone know of a way to disable the ability of certain users from
> >>>>using telnet to access a server?
> >>>
> >>>Why not just disable telnet, period?  Telnet is evil!
> >>
> >>These Windose using people have a telnet client available within their
> >>so-called OS but no SSH client.  Many of them also have a corporate policy
> >>of disallowing the installation of FREE software such as PuTTY.  To them
> >>your entirely correct recommendation is not an option.
> >>
> >>Neither do these people recognize that assigning /usr/bin/false as the
> >>shell for their selected users is the usual and correct method for
> >>accomplishing their purpose.  Indeed, the last Windose user with the same
> >>question told us to f**k ourselves after being given the answer.
> >>
> >>Assigning a shell of /usr/bin/false to the undesirable users still permits
> >>full ftp, smtp, nfs, pop3 and imap access by those users; i.e., they still
> >>have full access to the server except for the ability to login to a shell.
> > 
> > 
> > Since the original request was to just disable telnet access for 
> > specific users (no mention of ftp, smtp, nfs, pop3, imap or any other 
> > services), what's wrong with the standard solution proposed (/bin/false 
> > shell)?  There are ways to disable ftp, nfs, or ssh/sftp access.  I'm 
> > not familiar with pop3 or imap enough to know if they have separate 
> > authentication from /etc/passwd.
> > 
> > Since we can't disable connections based on IP address, login username 
> > is all that's left for authentication.  The /bin/false shell solves that 
> > problem.  Why isn't this acceptable as a solution?  Have I missed some 
> > unspoken requirement?
> > 

In article <RKLke.1161$rr.1104@fed1read01>,
 Robert Johnson <robj@robspens.com> wrote:

> Let me attempt to clarify what I am asking.
> 
> I have a database owner that is required by Informix, the database we 
> use. To do certain things you have to become that user, so the account 
> needs to be able to be logged in to.
> 
> My desire is to only allow that account to log in either on the console, 
> like root is setup, or from an su command while someone else is logged 
> in. Right now I can telnet to the server and login as the database user 
> directly just like any other user. If I change their "shell" to 
> /bin/false that account will not be allowed any access, just as if I had 
> locked it. My preference, if possible, is to not have to lock and unlock 
> the account, which takes my intervention every time it is needed.
> 
> I am looking at ownership/permissions to help, but removing remote 
> telnet access, like root, would be even better.
> 
> Hope that clears up a bit more of what I am trying to accomplish.
> 
> 

Now this becomes clearer.  I'm not aware of a way to easily restrict 
login to just the console for a specific account.  You'd have to use a 
require the account (i.e. informix or oracle or ingres) to use a 
specific shell like /bin/sh and change /etc/profile to check for the 
account name.  If they're not logged in on /dev/console, display an 
error message, log the date/time + "who am i" info to a file, and exit.  
/etc/profile would have to trap control-c to prevent escaping out of it.

For remote access, configure and install sudo and configure it to allow 
various people run captive shell scripts to do stuff as the database 
account.  That way you don't give the database account password out to 
anyone but a select few.  People can do various controlled things as the 
database user and those select few can use the console or use "su 
informix" to login (warning: "su - informix" would run the shell script 
and kick you off if you're not on the console.)

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

Robert Johnson wrote:
> Let me attempt to clarify what I am asking.
> 
> I have a database owner that is required by Informix, the database we 
> use. To do certain things you have to become that user, so the account 
> needs to be able to be logged in to.
> 
> My desire is to only allow that account to log in either on the console, 
> like root is setup, or from an su command while someone else is logged 
> in. Right now I can telnet to the server and login as the database user 
> directly just like any other user. If I change their "shell" to 
> /bin/false that account will not be allowed any access, just as if I had 
> locked it. My preference, if possible, is to not have to lock and unlock 
> the account, which takes my intervention every time it is needed.
> 
> I am looking at ownership/permissions to help, but removing remote 
> telnet access, like root, would be even better.
> 
> Hope that clears up a bit more of what I am trying to accomplish.
> 
> 
> Michael Vilain wrote:
> 
>> In article <pan.2005.05.23.23.43.56.692371@yahoo.com>,
>>  Dave Uhring <daveuhring@yahoo.com> wrote:
>>
>>
>>> On Mon, 23 May 2005 22:29:14 +0000, Rich Teer wrote:
>>>
>>>
>>>> On Mon, 23 May 2005, Robert Johnson wrote:
>>>>
>>>>
>>>>> Does anyone know of a way to disable the ability of certain users from
>>>>> using telnet to access a server?
>>>>
>>>>
>>>> Why not just disable telnet, period?  Telnet is evil!
>>>
>>>
>>> These Windose using people have a telnet client available within their
>>> so-called OS but no SSH client.  Many of them also have a corporate 
>>> policy
>>> of disallowing the installation of FREE software such as PuTTY.  To them
>>> your entirely correct recommendation is not an option.
>>>
>>> Neither do these people recognize that assigning /usr/bin/false as the
>>> shell for their selected users is the usual and correct method for
>>> accomplishing their purpose.  Indeed, the last Windose user with the 
>>> same
>>> question told us to f**k ourselves after being given the answer.
>>>
>>> Assigning a shell of /usr/bin/false to the undesirable users still 
>>> permits
>>> full ftp, smtp, nfs, pop3 and imap access by those users; i.e., they 
>>> still
>>> have full access to the server except for the ability to login to a 
>>> shell.
>>
>>
>>
>> Since the original request was to just disable telnet access for 
>> specific users (no mention of ftp, smtp, nfs, pop3, imap or any other 
>> services), what's wrong with the standard solution proposed 
>> (/bin/false shell)?  There are ways to disable ftp, nfs, or ssh/sftp 
>> access.  I'm not familiar with pop3 or imap enough to know if they 
>> have separate authentication from /etc/passwd.
>>
>> Since we can't disable connections based on IP address, login username 
>> is all that's left for authentication.  The /bin/false shell solves 
>> that problem.  Why isn't this acceptable as a solution?  Have I missed 
>> some unspoken requirement?
>>
> 

If it is permissible that the only way a user would be able to become 
this account is via su (eg, not even console logins allowed), you 
could make the user that controls this database into a role.


-- 
Coy Hile
hile@cse.psu.edu

On Tue, 24 May 2005 13:01:54 -0700, Robert Johnson wrote:

> Let me attempt to clarify what I am asking.
> 
> I have a database owner that is required by Informix, the database we 
> use. To do certain things you have to become that user, so the account 
> needs to be able to be logged in to.

Then don't assign /bin/false as the Informix user's shell.  You do that
only for the "particular users" for which you wish to disable telnet (and
console) access.

> My desire is to only allow that account to log in either on the console, 
> like root is setup, or from an su command while someone else is logged 
> in. Right now I can telnet to the server and login as the database user 
> directly just like any other user. If I change their "shell" to 
> /bin/false that account will not be allowed any access, just as if I had 
> locked it. My preference, if possible, is to not have to lock and unlock 
> the account, which takes my intervention every time it is needed.

If the Informix user requires telnet and console access why would you even
consider assigning /bin/false as that user's shell?  Your Subject and OP
text referred only to certain particular, presumably undesirable, users,
not the ones which do require access.  See below.

You do not want to lock the accounts of those users if they require other
password protected services provided by that server.  Just take away their
shells.

The way to disable those undesirable users is, for each of them:

# usermod -s /bin/false badguy

>>>>On Mon, 23 May 2005, Robert Johnson wrote:
>>>>
>>>>>Does anyone know of a way to disable the ability of certain users from
>>>>>using telnet to access a server?

Robert Johnson wrote:
> Let me attempt to clarify what I am asking.
> 
> I have a database owner that is required by Informix, the database we 
> use. To do certain things you have to become that user, so the account 
> needs to be able to be logged in to.
> 
> My desire is to only allow that account to log in either on the console, 
> like root is setup, or from an su command while someone else is logged 
> in. Right now I can telnet to the server and login as the database user 
> directly just like any other user. If I change their "shell" to 
> /bin/false that account will not be allowed any access, just as if I had 
> locked it. My preference, if possible, is to not have to lock and unlock 
> the account, which takes my intervention every time it is needed.
> 
> I am looking at ownership/permissions to help, but removing remote 
> telnet access, like root, would be even better.
> 
> Hope that clears up a bit more of what I am trying to accomplish.
> 
> 
> Michael Vilain wrote:
> 

At the risk of flogging a dead horse, why don't you just
use ssh/sshd?  If you want to continue to provide telnet,
however insecure, to all users, just do it.  But why not
use have /bin/false as the shell in /etc/passwd for your
informix user, and grant assess to the specific processes
you want this user to be able to run by binding the
processes (or a wrapper process) to a specific ssh key
in the authorized_keys file?  Access won't be controlled
by a passwd at all, just by file system permissions for
access to the private keys.

I'd suggest:

  1) use /bin/false for shell in /etc/passwd for user informix
  2) have an informix group/roll with access to the ssh keys
     controlled by group informix perms.
  3) Create some number of ssh public/private key pairs for
     each process you want user "informix" to be able to run
     (even if one of them is /bin/sh).
  4) copy the public keys to authorized_keys, and modify to
     restrict their use to specific hosts/commands.  (You may
     want to copy the group readable private key somewhere
     outside of ~informix/.ssh to avoid problems related to
     ~informix/.ssh being too open).
  5) Have ALL access as informix be via ssh, whether initiated
     on the host where informix is run or from a remote host,
     eschewing console access completely.

- Bob

I seem to remeber from the the dim and distant past that 'su - user'
and 'su user' were slightly different, in the 'su - user' also switched
to the users shell.

I have no idea if disabling the shell with /sbin/nologin would enable
root and others to get a shell if they did not use the 'su -' option
but used a straight 'su'

hmmm... I think I will go lie down now.

P.

Now I think of it I'm not sure if that was Solaris or Linux...

P.

On Tue, 24 May 2005 15:47:30 -0700, mr_peter_stevenso wrote:

> Now I think of it I'm not sure if that was Solaris or Linux...

Linux.

Robert Johnson wrote:
> I have a database owner that is required by Informix, the database we 
> use. To do certain things you have to become that user, so the account 
> needs to be able to be logged in to.

The way we do it, we disable (lock) the password for that account
('*' in /etc/shadow).  Then only root can "su" to the account without
password.  For regular users, use "sudo"  (e.g. "sudo su informix")
(maybe rbac can be used too?)

Problem solved for now with a proposed short script at the end of 
/etc/profile sent directly to me. Here is is for everyones enjoyment.

Thanks to all for the responses.


# Force users in "/etc/nointlogin" to "su"

trap 'echo "\nControl-C Disabled"' 2
TTY=`tty | awk -F/ '{printf ($3"/"$4)}'`
USERID=`w | awk '(\$2=="'$TTY'"){print \$1}'`
for USER in `cat /etc/nointlogin`
do
    if [ "$USERID" = "$USER" ]
    then
       echo
       echo "--------------------------------------------------------------"
       echo Interactive logins for the user $USERID are disabled.
       echo
       echo If you are trying to login with a Generic User Id,
       echo please login with your own User Id and do a \"su - $USERID\".
       echo
       echo If you are trying to login with your own User Id and unable
       echo to access your account, please contact the System Administrator.
       echo "--------------------------------------------------------------"
       echo
       exit
    fi
done

trap 2 3


Robert Johnson wrote:

> Does anyone know of a way to disable the ability of certain users from 
> using telnet to access a server?
> 
> 

Robert Johnson <robj@robspens.com> wrote:
> Problem solved for now with a proposed short script at the end of 
> /etc/profile sent directly to me. Here is is for everyones enjoyment.
[...]
>       echo If you are trying to login with a Generic User Id,
>       echo please login with your own User Id and do a \"su - $USERID\".

This is _exactly_ what RBAC was designed for.

A "role" is unable to login directly - you first need to login as a
user (and more specifically, a user who is assigned to that role) and
then you can su to the role.

  Scott

Scott Howard wrote:
> This is _exactly_ what RBAC was designed for.
> 
> A "role" is unable to login directly - you first need to login as a
> user (and more specifically, a user who is assigned to that role) and
> then you can su to the role.

The problem with RBAC is that it only works on Solaris. As soon as you 
have a hetergenous UNIX environment like Solaris, HP-UX and IRIX, the 
whole RBAC thing becomes completely worthless and useless.

Lastly, RBAC implements functionality that careful/thoughtful design of 
/etc/sudoers could already solve.