login man page on Scientific

Man page or keyword search:  
man Server   26626 pages
apropos Keyword Search (all sections)
Output format
Scientific logo
[printable version]

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

       login - sign on

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

       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	prevent	 logins when the system is being taken

       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 generated. 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 success‐
       ful root logins.

       If  the	file  ~/.hushlogin  or	/etc/hushlogins exists, then a "quiet"
       login is performed (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  cur‐
       rent login is recorded).

       Note  that  if the /etc/hushlogins file exists then the last login mes‐
       sage 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 information about failed login attempts.

       Random  administrative  things,	such as setting the UID and GID of the
       tty are performed.  The TERM environment variable is preserved,	if  it
       exists  (other  environment 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).

       -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

       -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  necessary  to  create a proper PAM config files
	      (e.g.  /etc/pam.d/login and /etc/pam.d/remote ).

       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 con‐
       sists  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. Com‐
       ments 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 sec‐
       tion. 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:

       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	 sepa‐
       rated  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 specifica‐
       tions may involve the use of classes defined in previous	 CLASSES  sec‐

       An example GROUPS section.

       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	 sepa‐
       rated  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	speci‐
       fied  at	 the top of the file, the first section defaults to be a USERS

       An example USERS section:

       zacho	      tty1 @
       blue	 tty3 myclass2

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

       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

       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  tel‐
	      net/rlogin  from	the  local  host  to  the same host. This also
	      allows the user  to  for	example	 run  the  command:  xterm  -e

       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

       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 nota‐
	      tion,  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 @ means that
	      the user may rlogin/telnet from any host whose IP address is  in
	      the range -

       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	 spec‐
       ify  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 behav‐


       init(8), getty(8), mail(1),  passwd(1),	passwd(5),  environ(7),	 shut‐

       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  surround‐
       ing  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.

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

       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)

List of man pages available for Scientific

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net