Remote Logins – Telnet

An answer found from Linux Gazette for the question on Remote Logins and su.

Q. i am running red hat linux 6.1 and am encountering some problems i can login as root from the console but not from anywhere else i have to login as webmaster on all other machines on ntwk from nowhere, including the console, can i su once logged in as webmaster any help would be appreciated

Ans. :
Any of these should allow you to access your system through cryptographically secured authentication and session protocols that protect you from a variety of sniffing, spoofing, TCP hijacking and other vulnerabilties that are common using other forms of remote shell access (such as telnet, and the infamous rsh and rlogin packages).

If you really insist on eliminating these policies from your system you can edit files under /etc/pam.d that are used to configure the options and restrictions of the programs that are compiled against the PAM (pluggable authentication modules) model and libraries. Here’s an example of one of them (/etc/pam.d/login which is used by the in.telnetd service):

#
# The PAM configuration file for the Shadow `login' service
#
# NOTE: If you use a session module (such as kerberos or NIS+)
# that retains persistent credentials (like key caches, etc), you
# need to enable the `CLOSE_SESSIONS' option in /etc/login.defs
# in order for login to stay around until after logout to call
# pam_close_session() and cleanup.
#

# Outputs an issue file prior to each login prompt (Replaces the
# ISSUE_FILE option from login.defs). Uncomment for use
# auth required pam_issue.so issue=/etc/issue

# Disallows root logins except on tty's listed in /etc/securetty
# (Replaces the `CONSOLE' setting from login.defs)
auth requisite pam_securetty.so

# Disallows other than root logins when /etc/nologin exists
# (Replaces the `NOLOGINS_FILE' option from login.defs)
auth required pam_nologin.so

# This module parses /etc/environment (the standard for setting
# environ vars) and also allows you to use an extended config
# file /etc/security/pam_env.conf.
# (Replaces the `ENVIRON_FILE' setting from login.defs)
auth required pam_env.so

# Standard Un*x authentication. The "nullok" line allows passwordless
# accounts.
auth required pam_unix.so nullok

# This allows certain extra groups to be granted to a user
# based on things like time of day, tty, service, and user.
# Please uncomment and edit /etc/security/group.conf if you
# wish to use this.
# (Replaces the `CONSOLE_GROUPS' option in login.defs)
# auth optional pam_group.so

# Uncomment and edit /etc/security/time.conf if you need to set
# time restrainst on logins.
# (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs
# as well as /etc/porttime)
# account requisite pam_time.so

# Uncomment and edit /etc/security/access.conf if you need to
# set access limits.
# (Replaces /etc/login.access file)
# account required pam_access.so

# Standard Un*x account and session
account required pam_unix.so
session required pam_unix.so

# Sets up user limits, please uncomment and read /etc/security/limits.conf
# to enable this functionality.
# (Replaces the use of /etc/limits in old login)
# session required pam_limits.so

# Prints the last login info upon succesful login
# (Replaces the `LASTLOG_ENAB' option from login.defs)
session optional pam_lastlog.so

# Prints the motd upon succesful login
# (Replaces the `MOTD_FILE' option in login.defs)
session optional pam_motd.so

# Prints the status of the user's mailbox upon succesful login
# (Replaces the `MAIL_CHECK_ENAB' option from login.defs). You
# can also enable a MAIL environment variable from here, but it
# is better handled by /etc/login.defs, since userdel also uses
# it to make sure that removing a user, also removes their mail
# spool file.
session optional pam_mail.so standard noenv

# The standard Unix authentication modules, used with NIS (man nsswitch) as
# well as normal /etc/passwd and /etc/shadow entries. For the login service,
# this is only used when the password expires and must be changed, so make
# sure this one and the one in /etc/pam.d/passwd are the same. The "nullok"
# option allows users to change an empty password, else empty passwords are
# treated as locked accounts.
#
# (Add `md5' after the module name to enable MD5 passwords the same way that
# `MD5_CRYPT_ENAB' would do under login.defs).
#
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs. Also the "min" and "max" options enforce the length of the
# new password.

password required pam_unix.so nullok obscure min=4 max=8

# Alternate strength checking for password. Note that this
# requires the libpam-cracklib package to be installed.
# You will need to comment out the password line above and
# uncomment the next two in order to use this.
# (Replaces the `OBSCURE_CHECKS_ENAB', `CRACKLIB_DICTPATH')
#
# password required pam_cracklib.so retry=3 minlen=6 difok=3
# password required pam_unix.so use_authtok nullok md5

This is from Debian machine (mars.starshine.org) and thus has far more comments (all those lines starting with “#” hash marks) than those that Red Hat installs. It’s good that Debian comments these files so verbosely, since that’s practically the only source of documentation for PAM files and modules.

In this case the entry that you really care about is the one for ‘securetty.so’ This module checks the file /etc/securetty which is classically a list of those terminals on which your system will allow direct root logins.

You could comment out this line in /etc/pam.d/login to disable this check for those services which call the /bin/login command. You can look for similar lines in the various other /etc/pam.d files so see which other services are enforcing this policy.

This leads us to the question of why your version of ‘su’ is not working. Red Hat’s version of ‘su’ is probably also “PAMified” (almost certainly, in fact). So there should be a /etc/pam.d/su file that controls the list of policies that your copy of ‘su’ is checking. You should look through that to see why ‘su’ isn’t allowing your ‘webmaster’ account to become ‘root’.

It seems quite likely that your version of Red Hat contains a line something like:

# Uncomment this to force users to be a member of group root
# before than can use `su'. You can also add "group=foo" to
# to the end of this line if you want to use a group other
# than the default "root".
# (Replaces the `SU_WHEEL_ONLY' option from login.defs)
auth required pam_wheel.so

Classically the ‘su’ commands on most versions of UNIX required that a user be in the “wheel” group in order to attain ‘root’ The traditional GNU implementation did not enforce this restriction (since rms found it distasteful).

On my system this line was commented out (which is presumably the Debian default policy, since I never fussed with that file on my laptop). I’ve uncommented here for this exa
mple.

Note that one of the features of PAM is that it allows you to specify any group using a command line option. It defaults to “wheel” because that is an historical convention. You can also use the pam_wheel.so module on any of the PAMified services --- so you could have programs like ‘ftpd’ or ‘xdm’ enforce a policy that restricted their use to members of arbitrary groups.

Finally note that most recent versions of SSH have PAM support enabled when they are compiled for Linux systems. Thus you may find, after you install any version of SSH, that you have an /etc/pam.d/ssh file. You may have to edit that to set some of your preferred SSH policies. There is also an sshd_config file (mine’s in /etc/ssh/sshd_config) that will allow you to control other ssh options).

In generall the process of using ssh works something like this:

  1. Install the sshd (daemon) package on your servers (the systems that you want to access)
  2. Install the ssh client package on your clients (the systems from which you’d like to initiate your connections).
  3. Generate Host keys on all of these systems (normally done for you by the installation).

…. you could stop at this point, and just start using the ssh and slogin commands to access your remote accounts using their passwords. However, for more effective and convenient use you’d also:

  1. Generate personal key pairs for your accounts.
  2. Copy/append the identity.pub (public) keys from each of your client accounts into the ~/.ssh/authorized_keys files on each of the servers.

This allows you to access those remote accounts without using your passwords on them. (Actually sshd can be configured to require the passwords AND/OR the identity keys, but the default is to allow access without a password if the keys work).

Another element you should be aware of is the “passphrases” and the ssh-agent. Basically it is normal to protect your private key with a passphrase. This is sort of like a password --- but it is used to decrypt or “unlock” your private key. Obviously there isn’t much added convenience if you protect your private key with a passphrase so that you have to type that every time you use an ssh/slogin or scp (secure remote copy) command.

ssh-agent allows you to start a shell or other program, unlock your identity key (or keys), and have all of the ssh commands you run from any of the descendents of that shell or program automatically use any of those unlocked keys. (The advantage of this is that the agent automatically dies when you exit the shell program that you started. That automatically “locks” the identity --- sort of.

There are alot of other aspects to ssh. It can be used to create tunnels, through which one can use all sorts of traffic. People have created PPP/TCP/IP tunnels that run through ssh tunnels to support custom VPNs (virtual private networks). When run under X, ssh automatically performs “X11 forwarding” through one of the these tunnels. This is particularly handy for running X clients on remote systems beyond a NAT (IP Masquerading) router or through a proxying firewall.

In other words ssh is a very useful package quite apart from its support for cryptographic authentication and encryption.

In fairness I should point out that there are a number of alternatives to ssh. Kerberos is a complex and mature suite of protocols for performing authentication and encryption. STEL is a simple daemon/client package which functions just like telnetd/telnet --- but with support for encrypted sessions. And there are SSL enabled versions telnet and ftp daemons and clients.

How do I lock out a user after a set number of login attempts?

The PAM (Pluggable Authentication Module) module pam_tally keeps track of unsuccessful login attempts then disables user accounts when a preset limit is reached. This is often referred to as account lockout.

To lock out a user after 4 attempts, two entries need to be added in the /etc/pam.d/system-auth file:

auth        required        /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
account required /lib/security/$ISA/pam_tally.so deny=3 no_magic_root reset

The options used above are described below:

  • onerr=fail
    If something strange happens, such as unable to open the file, this determines how the module should react.
  • no_magic_root
    This is used to indicate that if the module is invoked by a user with uid=0, then the counter is incremented. The sys-admin should use this for daemon-launched services, like telnet/rsh/login.
  • deny=3The deny=3 option is used to deny access if tally for this user exceeds 3.
  • reset
    The reset option instructs the module to reset count to 0 on successful entry.

See below for a complete example of implementing this type of policy:

auth        required      /lib/security/$ISA/pam_env.so
auth required /lib/security/$ISA/pam_tally.so onerr=fail
no_magic_root
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so
account required /lib/security/$ISA/pam_tally.so deny=5
no_magic_root reset
password requisite /lib/security/$ISA/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/$ISA/pam_unix.so nullok use_authtok md5 shadow password
required /lib/security/$ISA/$ISA/pam_deny.so session
required /lib/security/$ISA/$ISA/pam_limits.so session
required /lib/security/$ISA/$ISA/pam_unix.so

For more detailed information on the PAM system please see the documentation contained under /usr/share/doc/pam-

For information on how to unlock a user that has expired their deny tally see additional Knowledgebase articles regarding unlocking a user account and seeing failed logins with the faillog command.

contributed by David Robinson

I miss them all do u???

When gulli-danda and kanche (marbles) were more
popular than cricket …

When we always had friends to play aais-paais (I Spy),
chhepan-chhepai and pitthoo anytime …

When we desperately waited for ‘yeh jo hai jindagi’

When chitrahaar, vikram-baitaal, dada daadi ki
kahaniyaan were so fulfilling …

When there was just one tv in every five houses and

When bisleris were not sold in the trains and we were
worrying if papas will get back into the train in time
or not when they were getting down at stations to fill
up the water bottle …

When we were going to bed by 9.00pm sharp except for
the ‘yeh jo hai jindagi’ day …

When Holis & Diwalis meant mostly hand-made pakwaans
and
sweets and moms seeking our help while preparing them

When Maths teachers were not worried of our mummys and
papas while slapping/beating us …

When we were exchanging comics and stamps and
chacha-chaudaris and billus were our heroes …

When we were in nanihaals every summer and loved
flying kites and plucking and eating unripe mangoes
and leechis …

When one movie every Sunday evening on television was
more than asked for and ‘ek do teen chaar’ and
‘Rajni’ inspired us …

When 50 paisa meant at least 10 toffees …

When left over pages of the last years notebooks were
used for rough work or even fair work …

When ‘chelpark’ and ‘natraaj’ were encouraged against
‘reynolds and family’ …

When the first rain meant getting drenched and playing
in water and mud and making ‘kaagaj ki kishtis’ …

When there were no phones to tell friends that we will
be at their homes at six in the evening …

When our parents always had 15 paise blue colored
‘antardesis’ and 5 paise machli wale stamps at home

When we remembered tens of jokes and were not finding
‘ice-cream and papa’ type jokes foolish enough to stop
us from laughing …

When we were not seeing patakhes on Diwalis and
gulaals on Holis as air and noise polluting or
allergic agents …

the list can be endless …

on the serious note I would like to summarise with …

When we were using our hearts more than our brains,
even for scientifically brainy activities like
‘thinking’ and ‘deciding’ …

When we were crying and laughing more often, more
openly and more sincerily …

When we were enjoying our present more than worrying
about our future …

When being emotional was not synonymous to being weak

When sharing worries and happinesses didnt mean
getting vulnerable to the listener …

When blacks and whites were the favourite colors
instead of greys …

When journeys also were important and not just the
destinations …

When life was a passenger’s sleeper giving enough time
and opportunity to enjoy the sceneries from its open
and transparent glass windows instead of some
superfast’s second ac with its curtained, closed and
dark windows …

I really miss .. do u?


———————————————————–
http://om-prakash.blogspot.com]]
Embedding the world for the sake of Humanity

miserable

To, The woman I loved the most

I dedicate this blog to you

. I feel distressful, hateful, infamous, enormous, counter, reprehensible,distressing, rank, noisome, hopeless, dirty, lumpen, blameworthy,measly, egregious,meretricious, harmful, sore, foul, dismaying, out of humor, in bad humor, cut up, dismal, arrant, ruthful,petty, moving, schlock, disconsolate, cheap, slummy,mournful, horrible, gimcracky, squalid, opposing, pitiful, low-down, sharp, uncheerful, dreadful, trashy, indolent, out of sorts,woeful, shameful, cheesy, contemptible, despairing, depraved, untoward,trying, scruffy, comfortless,sorrowful,unsmiling, joyless,unmirthful, painful, cheerless, atrocious, common, despicable, depressing, slumlike, bitter, deep-troubled, unmentionable, lamentable, valueless, afflictive, detestable, unclean, stressful, rubbishy, uncheery, touching, woebegone, scuzzy,sinister,heart-struck,filthy, opposite, base, execrable, desolate, detrimental, unjoyful, opposed, afflicted, grim, mean, flagrant, forlorn, heartsick, discomforting, uncomfortable,terrible, grave, loathsome, gross, nasty, worst, sad, scrubby, worthless, sorry,sorryish,miserable, scurvy, nefarious,rigorous, shabby, beneath contempt, pitiable, difficult, inimical, odious, vile, adverse,grievous, conflicting, beggarly, mangy, paltry,melancholy, pathetic, fetid, repulsive, lousy, saddening, counteractive, abominable, hard, little, gaudy, brutal,unfavorable,scabby, in opposition, beastly, horrid, offensive, shocking, dolorific, rueful, bleak, awful, scandalous, monstrous, poky, twopenny, notorious, obnoxious,antagonistic, trumpery, troublous, despondent, too bad, deplorable,contrary, heinous, sordid,mirthless, humorless, low, stricken, pleasureless, ignoble, rotten, disgusting, debased,abject, heart-stricken,dolorous,poor, discontented, crushed, dire, depressive, villainous, small, fulsome, servile, infestive,troublesome, dolorogenic, outrageous, degraded, crummy, suicidal, scummy,hostile,regrettable, piteous, unhappy, reptilian, dreary, poignant, doleful,affecting, shoddy.

God bless her