login(1) - phpMan

Command: man perldoc info search(apropos)  


LOGIN(1)                   Linux Programmer's Manual                  LOGIN(1)



NAME
       login - sign on

SYNOPSIS
       login [ name ]
       login -p
       login -h hostname
       login -f name

DESCRIPTION
       login is used when signing onto a system.

       If an argument is not given, login prompts for the username.

       If  the user is not root, and if /etc/nologin exists, the contents of this file are
       printed to the screen, and the login is terminated.  This is typically used to pre-
       vent logins when the system is being taken down.

       If  special  access  restrictions are specified for the user in /etc/usertty, these
       must be met, or the log in attempt will be denied and a syslog message will be gen-
       erated. See the section on "Special Access Restrictions".

       If  the  user  is  root,  then  the  login  must  be  occurring  on a tty listed in
       /etc/securetty.  Failures will be logged with the syslog facility.

       After these conditions have been  checked,  the  password  will  be  requested  and
       checked  (if  a  password is required for this username).  Ten attempts are allowed
       before login dies, but after the first three, the response starts to get very slow.
       Login failures are reported via the syslog facility.  This facility is also used to
       report any successful root logins.

       If the file ~/.hushlogin or /etc/hushlogins exists, then a "quiet"  login  is  per-
       formed  (this disables the checking of mail and the printing of the last login time
       and message of the day).  Otherwise, if /var/log/lastlog  exists,  the  last  login
       time is printed (and the current login is recorded).

       Note  that  if the /etc/hushlogins file exists then the last login message could be
       generated by PAM, for example by:

        session required pam_lastlog.so noupdate showfailed

       setting in the /etc/pam.d/login file. The PAM library provides more detailed infor-
       mation about failed login attempts.

       Random  administrative  things, such as setting the UID and GID of the tty are per-
       formed.  The TERM environment variable is preserved, if it exists  (other  environ-
       ment  variables  are  preserved  if  the  -p option is used).  Then the HOME, PATH,
       SHELL, TERM, MAIL, and LOGNAME environment variables are  set.   PATH  defaults  to
       /usr/local/bin:/bin:/usr/bin       for       normal       users,       and       to
       /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin for  root.   Last,  if
       this  is  not  a "quiet" login, the message of the day is printed and the file with
       the user's name in /var/spool/mail will be checked, and a message printed if it has
       non-zero length.

       The  user's  shell  is  then  started.   If  no  shell is specified for the user in
       /etc/passwd, then  /bin/sh  is  used.   If  there  is  no  directory  specified  in
       /etc/passwd,  then / is used (the home directory is checked for the .hushlogin file
       described above).

OPTIONS
       -p     Used by getty(8) to tell login not to destroy the environment

       -f     Used to skip a second login authentication.  This specifically does not work
              for root, and does not appear to work well under Linux.

       -h     Used by other servers (i.e., telnetd(8)) to pass the name of the remote host
              to login so that it may be placed in utmp and wtmp.  Only the superuser  may
              use this option.

              Note  that  the  -h  option has impact on the PAM service name. The standard
              service name is "login", with the -h option the name is "remote". It's  nec-
              essary  to  create  a  proper  PAM  config files (e.g.  /etc/pam.d/login and
              /etc/pam.d/remote ).


SPECIAL ACCESS RESTRICTIONS
       The file /etc/securetty lists the names of the ttys where root is  allowed  to  log
       in.  One  name  of  a tty device without the /dev/ prefix must be specified on each
       line.  If the file does not exist, root is allowed to log in on any tty.

       On most modern Linux systems PAM (Pluggable Authentication  Modules)  is  used.  On
       systems  that  do  not  use  PAM, the file /etc/usertty specifies additional access
       restrictions for specific users.  If this file does not exist, no additional access
       restrictions  are  imposed.  The file consists of a sequence of sections. There are
       three possible section types: CLASSES, GROUPS and USERS. A CLASSES section  defines
       classes  of  ttys  and hostname patterns, A GROUPS section defines allowed ttys and
       hosts on a per group basis, and a USERS section defines allowed ttys and hosts on a
       per user basis.

       Each line in this file in may be no longer than 255 characters. Comments start with
       # character and extend to the end of the line.


   The CLASSES Section
       A CLASSES section begins with the word CLASSES at the start of a line in all  upper
       case.  Each  following line until the start of a new section or the end of the file
       consists of a sequence of words separated by tabs or spaces. Each  line  defines  a
       class of ttys and host patterns.

       The  word  at  the beginning of a line becomes defined as a collective name for the
       ttys and host patterns specified at the rest of the line. This collective name  can
       be used in any subsequent GROUPS or USERS section. No such class name must occur as
       part of the definition of a  class  in  order  to  avoid  problems  with  recursive
       classes.

       An example CLASSES section:

       CLASSES
       myclass1       tty1 tty2
       myclass2       tty3 @.foo.com

       This  defines  the  classes  myclass1  and myclass2 as the corresponding right hand
       sides.



   The GROUPS Section
       A GROUPS section defines allowed ttys and hosts on a per Unix  group  basis.  If  a
       user is a member of a Unix group according to /etc/passwd and /etc/group and such a
       group is mentioned in a GROUPS section in /etc/usertty then  the  user  is  granted
       access if the group is.

       A  GROUPS  section  starts with the word GROUPS in all upper case at the start of a
       line, and each following line is a sequence of words separated by spaces  or  tabs.
       The  first word on a line is the name of the group and the rest of the words on the
       line specifies the ttys and hosts where members of that group are  allowed  access.
       These  specifications  may  involve  the use of classes defined in previous CLASSES
       sections.

       An example GROUPS section.

       GROUPS
       sys       tty1 @.bar.edu
       stud      myclass1 tty4

       This example specifies that members of group sys may log in on tty1 and from  hosts
       in  the bar.edu domain. Users in group stud may log in from hosts/ttys specified in
       the class myclass1 or from tty4.



   The USERS Section
       A USERS section starts with the word USERS in all upper case  at  the  start  of  a
       line,  and  each following line is a sequence of words separated by spaces or tabs.
       The first word on a line is a username and that user is allowed to log  in  on  the
       ttys and from the hosts mentioned on the rest of the line. These specifications may
       involve classes defined in previous CLASSES sections.   If  no  section  header  is
       specified at the top of the file, the first section defaults to be a USERS section.

       An example USERS section:

       USERS
       zacho          tty1 @130.225.16.0/255.255.255.0
       blue      tty3 myclass2

       This lets the user zacho login only on tty1 and from hosts with IP addreses in  the
       range  130.225.16.0  - 130.225.16.255, and user blue is allowed to log in from tty3
       and whatever is specified in the class myclass2.

       There may be a line in a USERS section starting with a username of  *.  This  is  a
       default rule and it will be applied to any user not matching any other line.

       If  both  a USERS line and GROUPS line match a user then the user is allowed access
       from the union of all the ttys/hosts mentioned in these specifications.


   Origins
       The tty and host pattern specifications used in the specification of classes, group
       and user access are called origins. An origin string may have one of these formats:

       o      The name of a tty device without the  /dev/  prefix,  for  example  tty1  or
              ttyS0.


       o      The  string  @localhost,  meaning  that the user is allowed to telnet/rlogin
              from the local host to the same host. This also allows the user to for exam-
              ple run the command: xterm -e /bin/login.


       o      A  domain  name  suffix  such  as  @.some.dom,  meaning  that  the  user may
              rlogin/telnet from any host whose domain name has the suffix .some.dom.


       o      A range of IPv4 addresses, written @x.x.x.x/y.y.y.y where x.x.x.x is the  IP
              address  in the usual dotted quad decimal notation, and y.y.y.y is a bitmask
              in the same notation specifying which bits in the address  to  compare  with
              the  IP  address of the remote host. For example @130.225.16.0/255.255.254.0
              means that the user may rlogin/telnet from any host whose IP address  is  in
              the range 130.225.16.0 - 130.225.17.255.


       o      An range of IPv6 addresses, written @[n:n:n:n:n:n:n:n]/m is interpreted as a
              [net]/prefixlen pair. An IPv6 host address is matched if prefixlen  bits  of
              net  is  equal  to  the  prefixlen  bits  of the address.  For  example, the
              [net]/prefixlen pattern [3ffe:505:2:1::]/64 matches  every  address  in  the
              range 3ffe:505:2:1:: through 3ffe:505:2:1:ffff:ffff:ffff:ffff.

       Any  of  the above origins may be prefixed by a time specification according to the
       syntax:

       timespec    ::= '[' <day-or-hour> [':' <day-or-hour>]* ']'
       day         ::= 'mon' | 'tue' | 'wed' | 'thu' | 'fri' | 'sat' | 'sun'
       hour        ::= '0' | '1' | ... | '23'
       hourspec    ::= <hour> | <hour> '-' <hour>
       day-or-hour ::= <day> | <hourspec>

       For example, the origin [mon:tue:wed:thu:fri:8-17]tty3 means that log in is allowed
       on  mondays  through  fridays  between 8:00 and 17:59 (5:59 pm) on tty3.  This also
       shows that an hour range a-b includes all moments between a:00 and b:59.  A  single
       hour specification (such as 10) means the time span between 10:00 and 10:59.

       Not  specifying  any time prefix for a tty or host means log in from that origin is
       allowed any time. If you give a time prefix be sure to specify both a set  of  days
       and  one  or  more  hours  or hour ranges. A time specification may not include any
       white space.

       If no default rule is given then users  not  matching  any  line  /etc/usertty  are
       allowed to log in from anywhere as is standard behavior.


FILES
       /var/run/utmp
       /var/log/wtmp
       /var/log/lastlog
       /var/spool/mail/*
       /etc/motd
       /etc/passwd
       /etc/nologin
       /etc/usertty
       /etc/pam.d/login
       /etc/pam.d/remote
       /etc/hushlogins
       .hushlogin

SEE ALSO
       init(8), getty(8), mail(1), passwd(1), passwd(5), environ(7), shutdown(8)

BUGS
       The  undocumented  BSD  -r  option  is not supported.  This may be required by some
       rlogind(8) programs.

       A recursive login, as used to be possible in the good old days,  no  longer  works;
       for most purposes su(1) is a satisfactory substitute. Indeed, for security reasons,
       login does a vhangup() system call to remove any possible  listening  processes  on
       the  tty. This is to avoid password sniffing. If one uses the command "login", then
       the surrounding shell gets killed by vhangup() because  it's  no  longer  the  true
       owner  of  the tty.  This can be avoided by using "exec login" in a top-level shell
       or xterm.

AUTHOR
       Derived from BSD login 5.40 (5/9/89) by Michael Glad (glad AT daimi.dk) for HP-UX
       Ported to Linux 0.12: Peter Orbaek (poe AT daimi.dk)

AVAILABILITY
       The login command is part of  the  util-linux-ng  package  and  is  available  from
       ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/.



Util-linux 1.6                  4 November 1996                       LOGIN(1)

Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache
Under GNU General Public License
2017-09-25 08:08 @127.0.0.1 CrawledBy CCBot/2.0 (http://commoncrawl.org/faq/)
Valid XHTML 1.0!Valid CSS!