Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
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.	It can also be used to
       switch from one user to another at any time (most  modern  shells  have
       support for this	feature	built into them, however).

       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 Ac-
       cess 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  re-
       quested 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 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 current login is recorded).

       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	/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.

       The  file  /etc/securetty lists the names of the	ttys where root	is al-
       lowed 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

       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 ba-
       sis. 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
       stud	 myclass1 tty4

       This example specifies that members of group sys	may log	in on tty1 and
       from  hosts  in the 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  de-
       fined  in previous CLASSES sections.  If	no section header is specified
       at the top of the file, the first section defaults to be	a  USERS  sec-

       An example USERS	section:

       zacho	      tty1 @
       blue	 tty3 myclass2

       This  lets the user zacho login only on tty1 and	from hosts with	IP ad-
       dreses in the range	-, and user blue	is al-
       lowed  to  log  in from tty3 and	whatever is specified in the class my-

       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  al-
       lowed  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  al-
	      lows  the	user to	for example run	the command: xterm -e /bin/lo-

       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 -

       Any of the above	origins	may be prefixed	by a  time  specification  ac-
       cording 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 mo-
       ments 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. In-
       deed, for security reasons, login does a	vhangup() system call  to  re-
       move  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 (
       for HP-UX
       Ported to Linux 0.12: Peter Orbaek (

Util-linux 1.6			4 November 1996			      LOGIN(1)


Want to link to this manual page? Use this URL:

home | help