Discussion:
14.2 Slack64 system doesn't ask for password
(too old to reply)
root
2018-11-08 19:18:13 UTC
Permalink
One of my machines doesn't ask for a password at login. There
is a password set by passwd, and the /etc/shadow file shows
a password. The inittab file contains these lines:
# These are the standard console login getties in multiuser mode:
c1:12345:respawn:/sbin/agetty 38400 tty1 linux --noclear
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Logging in directly with the keyboard attached to the
machine (not ssh in) I get a prompt immediately after
entering root as the user. I have tried a number
of things short of re-installing the whole system.

Any suggestions about what might cause this?

Thanks.
Eef Hartman
2018-11-08 20:13:34 UTC
Permalink
Post by root
Logging in directly with the keyboard attached to the
machine (not ssh in) I get a prompt immediately after
entering root as the user. I have tried a number
Normally you shouldn't login directly as root, but you still should
get a prompt for a password IF root has got one.
Post by root
Any suggestions about what might cause this?
Show us the whole line for root from the /etc/shadow file.
Post by root
The password field may be empty, in which case no passwords
are required to authenticate as the specified login name.
but normally the line should have (at least) the first 3 fields filled
with: root as the first (user name), the encrypted passwd (preceded by
Post by root
ID | Method
-----------------------------------------
1 | MD5
2a | Blowfish (not in mainline glibc;
added in some Linux distributions)
5 | SHA-256 (since glibc 2.7)
6 | SHA-512 (since glibc 2.7)
These indicators are preceded and followed by a $) as second field and
the date last changed (in days since 1970) as the third.
And there should be at least 6 : chars in the rest of the line (so 5
more fields). They all may be empty, though.
root
2018-11-08 20:19:19 UTC
Permalink
Post by Eef Hartman
Post by root
Logging in directly with the keyboard attached to the
machine (not ssh in) I get a prompt immediately after
entering root as the user. I have tried a number
Normally you shouldn't login directly as root, but you still should
get a prompt for a password IF root has got one.
Post by root
Any suggestions about what might cause this?
Show us the whole line for root from the /etc/shadow file.
From /etc/shadow:
root:$5$Pi4/P/3TyY$3VMxhsS0HpQYL24fBjJqL3cVN22qs/D3gtoUsqnUkH5:17818:0:::::
Eef Hartman
2018-11-08 20:46:08 UTC
Permalink
That looks perfectly ok, encryption, salt and password present.

So as Lew already suggested: make sure the 2nd field in /etc/passwd
for root is NOT empty (but filled with an x).
The encrypted password field may be blank, in which case no
password is required to authenticate as the specified login name.
This field is a leftover from the days before the shadow file was
introduced and the (encrypted) password was stored directly IN the
If the password field is a lower-case ???x???, then the encrypted
password is actually stored in the shadow(5) file instead;
there must be a corresponding line in the /etc/shadow file,
or else the user account is invalid.
You _do_ have the corresponding file (and line in it) so make sure
login will be actually looking for it in there.
root
2018-11-08 20:58:37 UTC
Permalink
Post by Eef Hartman
That looks perfectly ok, encryption, salt and password present.
So as Lew already suggested: make sure the 2nd field in /etc/passwd
This field is a leftover from the days before the shadow file was
introduced and the (encrypted) password was stored directly IN the
Yes, that was it. The /etc/passwd had a null second field.

Thanks.
Henrik Carlqvist
2018-11-08 21:32:17 UTC
Permalink
Post by root
Yes, that was it. The /etc/passwd had a null second field.
Good problem was solved! If you are only slightly paranoid you might now
want to change your root password unless you somehow altered the
encrypted password string in /etc/shadow before publishing it.

Even though the password is stored with a one-way encryption it is still
possible with brute force to test passwords against the encrypted string
until a working password is found. If someone does that they will have
the root password to your system unless you change the password before
the time it takes the brute force algorith to find the password.

As was noted in this thread and has been said before, it is also best
practice not to log in directly as root but to do your everyday work as a
normal user and only su in a shell when you need to do administrative
tasks.

regards Henrik
Eef Hartman
2018-11-08 22:18:50 UTC
Permalink
Post by Henrik Carlqvist
Even though the password is stored with a one-way encryption it is still
possible with brute force to test passwords against the encrypted string
until a working password is found.
But not easy with a sha256 one (it started with $5$).

It _was_ possible with DES and even with MD5, that's why those
encryptions normally aren't used anymore. But even with those you
would need something close to a super-computer (or a massive parallel
one). If the password has been chosen right, of course.

But then again, changing the root password won't hurt.

To the OP: you can change it very easily with the command:
passwd root
(logged in as root, of course).
Rich
2018-11-09 03:43:49 UTC
Permalink
Post by Eef Hartman
Post by Henrik Carlqvist
Even though the password is stored with a one-way encryption it is still
possible with brute force to test passwords against the encrypted string
until a working password is found.
But not easy with a sha256 one (it started with $5$).
Yeah, looks like he's safe (by accident).

https://www.netmux.com/blog/how-to-build-a-password-cracking-rig

A 4 GPU rig.

Hashtype: sha256crypt, SHA256(Unix)
Speed.Dev.#*.....: 1119.1 kH/s

(Using bc):
(95^8)/1119100/60/60/24/365
187

187 years to brute force all 95 printable ascii characters for an 8
character password.
Post by Eef Hartman
It _was_ possible with DES and even with MD5, that's why those
encryptions normally aren't used anymore. But even with those you
would need something close to a super-computer (or a massive parallel
one). If the password has been chosen right, of course.
Well, yes, but "super-computer (or a massive parallel one)" today just
means "GPU rig" (from the same url as above):

Hashtype: descrypt, DES(Unix), Traditional DES
Speed.Dev.#*.....: 2693.9 MH/s

(95^8)/2693900000/60/60/24
28

Twenty eight days to brute force an 8 char. crypt() password.

Hashtype: md5crypt, MD5(Unix), FreeBSD MD5, Cisco-IOS MD5
Speed.Dev.#*.....: 30373.0 kH/s

(95^8)/30373000/60/60/24/365
6

Six years for md5crypt (mostly secure, but not as good as sha256crypt).

And adding more GPU's increases the performance, so the final speed is
really dependent upon "how much money ya got to spend?"
Richard Kettlewell
2018-11-09 09:12:18 UTC
Permalink
Rich <***@example.invalid> writes:
[...]
Post by Rich
Six years for md5crypt (mostly secure, but not as good as sha256crypt).
And adding more GPU's increases the performance, so the final speed is
really dependent upon "how much money ya got to spend?"
Yes; but for small number of passwords, the attacker doesn’t spend it on
buying equipment, they spend it on renting GPU instances on AWS (or
similar). IMO the best measure of password strength at the moment is the
dollar value required to crack it using a cloud computing service,
rather than the elapsed time on any given piece of equipment.
--
https://www.greenend.org.uk/rjk/
Eef Hartman
2018-11-09 19:02:34 UTC
Permalink
Post by Rich
Well, yes, but "super-computer (or a massive parallel one)" today just
No, even in my time "massive parallel" meant some box with at LEAST
64K cpu's (each with their own secondary cache and a bank of local
RAM). By now a massive parallel system could have as much as 1M of
(strictly separate) cpu's.
The speed problem with cpu core's and/or GPU is the access to the shared
memory (I mean RAM, for the program code and optional the dictionary).
Post by Rich
Twenty eight days to brute force an 8 char. crypt() password.
And the other rhing is that nowadays passwords aren't restricted to 8
chars anymore. And the charset might be not pure ASCII (95 printables)
anymore but an ISO-8859 or UTF-8 one, giving many more chars to try.
Post by Rich
And adding more GPU's increases the performance, so the final speed is
really dependent upon "how much money ya got to spend?"
AND how much time!
Rich
2018-11-09 23:56:32 UTC
Permalink
Post by Eef Hartman
Post by Rich
Well, yes, but "super-computer (or a massive parallel one)" today just
No, even in my time "massive parallel" meant some box with at LEAST
64K cpu's (each with their own secondary cache and a bank of local
RAM). By now a massive parallel system could have as much as 1M of
(strictly separate) cpu's.
Yes, but for password cracking, folks don't buy a traditional
'massively parallel' system, they buy eight Nvida 1080 GPU's.
Post by Eef Hartman
The speed problem with cpu core's and/or GPU is the access to the
shared memory (I mean RAM, for the program code and optional the
dictionary).
Access speeds to ram onboard video cards for modern GPU setups is
significantly higher than CPU/memory bandwidth pathways. I have no
numbers, but I'd not be surprised if the ram speed for CPU's outpases
even the speed available to the "massive parallel" systems you are
thinking of.
Post by Eef Hartman
Post by Rich
Twenty eight days to brute force an 8 char. crypt() password.
And the other rhing is that nowadays passwords aren't restricted to 8
chars anymore. And the charset might be not pure ASCII (95
printables) anymore but an ISO-8859 or UTF-8 one, giving many more
chars to try.
All true, and beside the point. For a post where one is comparing time
to brute force, one's got to pick *something* as an example. My
'something' was an 8 character password selected from the 95 printable
ASCII characters.
Post by Eef Hartman
Post by Rich
And adding more GPU's increases the performance, so the final speed is
really dependent upon "how much money ya got to spend?"
AND how much time!
For most of these rigs, the time involves little more than: "insert
eight Nvidia 1080 video cards into eight PCI-E slots", boot up system,
run hash-cat".

Of course, I'm assuming in my statement above that the individual
running the rig has already: 1) purchased a mother board with eight
pci-e slots, 2) purchased a PSU (or multiple PSU's) of sufficient
wattage to feed the GPUs, 3) already installed an OS on a boot disk
attached to the motherboard. But even adding in all this time, it is
not significant in the grand scheme.
Eli the Bearded
2018-11-10 01:14:27 UTC
Permalink
Post by Rich
For most of these rigs, the time involves little more than: "insert
eight Nvidia 1080 video cards into eight PCI-E slots", boot up system,
run hash-cat".
Of course, I'm assuming in my statement above that the individual
running the rig has already: 1) purchased a mother board with eight
pci-e slots, 2) purchased a PSU (or multiple PSU's) of sufficient
wattage to feed the GPUs, 3) already installed an OS on a boot disk
attached to the motherboard. But even adding in all this time, it is
not significant in the grand scheme.
Or the individual creates an AWS instance on someone else's credit
card. p2.8xlarge[*] has 8GPUs for $3.40 / hour. There's also a p2.16xlarge
which is 16GPUs for $6.80 / hour.


[*] "P2 instances are intended for general-purpose GPU compute
applications." It's not the only instance type with a GPU option.
There are G3 "optimized for graphics-intensive" and P3 "latest
generation of general purpose GPU". I'm not an expert by any
means, but I think the P2 is the "Nvidia 1080" one.

Elijah
------
the "someone else's" card bit is optional, of course
Rich
2018-11-10 05:28:51 UTC
Permalink
Post by Eli the Bearded
Post by Rich
For most of these rigs, the time involves little more than: "insert
eight Nvidia 1080 video cards into eight PCI-E slots", boot up system,
run hash-cat".
Of course, I'm assuming in my statement above that the individual
running the rig has already: 1) purchased a mother board with eight
pci-e slots, 2) purchased a PSU (or multiple PSU's) of sufficient
wattage to feed the GPUs, 3) already installed an OS on a boot disk
attached to the motherboard. But even adding in all this time, it is
not significant in the grand scheme.
Or the individual creates an AWS instance on someone else's credit
card. p2.8xlarge[*] has 8GPUs for $3.40 / hour. There's also a p2.16xlarge
which is 16GPUs for $6.80 / hour.
[*] "P2 instances are intended for general-purpose GPU compute
applications." It's not the only instance type with a GPU option.
There are G3 "optimized for graphics-intensive" and P3 "latest
generation of general purpose GPU". I'm not an expert by any
means, but I think the P2 is the "Nvidia 1080" one.
Yup, for those who wish to let someone else pay, this is a way.

Not everyone who builds a gpu password cracking rig is a criminal,
however:

https://securityintelligence.com/the-cracken-in-action-a-password-cracking-adventure/
jjge
2018-11-09 06:53:49 UTC
Permalink
Post by Henrik Carlqvist
Post by root
Yes, that was it. The /etc/passwd had a null second field.
Good problem was solved! If you are only slightly paranoid you might now
want to change your root password unless you somehow altered the
encrypted password string in /etc/shadow before publishing it.
Even though the password is stored with a one-way encryption it is still
possible with brute force to test passwords against the encrypted string
until a working password is found. If someone does that they will have
the root password to your system unless you change the password before
the time it takes the brute force algorith to find the password.
Worse yet, a dictionary attack remains possible, and feasible.
Post by Henrik Carlqvist
As was noted in this thread and has been said before, it is also best
practice not to log in directly as root but to do your everyday work as a
normal user and only su in a shell when you need to do administrative
tasks.
regards Henrik
Rich
2018-11-09 16:00:29 UTC
Permalink
Post by jjge
Post by Henrik Carlqvist
Post by root
Yes, that was it. The /etc/passwd had a null second field.
Good problem was solved! If you are only slightly paranoid you might now
want to change your root password unless you somehow altered the
encrypted password string in /etc/shadow before publishing it.
Even though the password is stored with a one-way encryption it is still
possible with brute force to test passwords against the encrypted string
until a working password is found. If someone does that they will have
the root password to your system unless you change the password before
the time it takes the brute force algorith to find the password.
Worse yet, a dictionary attack remains possible, and feasible.
Well, this statement in the grandparent:

"with brute force to test passwords against the encrypted string
until a working password is found"

Is the definition of a "dictionary attack".
jjge
2018-11-09 17:25:08 UTC
Permalink
Post by Rich
Post by jjge
Post by Henrik Carlqvist
Post by root
Yes, that was it. The /etc/passwd had a null second field.
Good problem was solved! If you are only slightly paranoid you might now
want to change your root password unless you somehow altered the
encrypted password string in /etc/shadow before publishing it.
Even though the password is stored with a one-way encryption it is still
possible with brute force to test passwords against the encrypted string
until a working password is found. If someone does that they will have
the root password to your system unless you change the password before
the time it takes the brute force algorith to find the password.
Worse yet, a dictionary attack remains possible, and feasible.
"with brute force to test passwords against the encrypted string
until a working password is found"
Is the definition of a "dictionary attack".
Not entirely. It also involves a dictionary, or several dictionaries,
which considerably reduces the search space. That is what makes a
dictionary attack feasible (say a few hundred of million tries, against
the supposed zillions for a real brute force attack)
Eef Hartman
2018-11-08 22:12:02 UTC
Permalink
Post by root
Yes, that was it. The /etc/passwd had a null second field.
Now you should, if you haven't done this before, create a "normal
user". Always working as root is very much discouraged, it's too easy
to really scr*w up your system as root. Especially in GUI mode.
Lew Pitcher
2018-11-08 20:33:54 UTC
Permalink
Post by Eef Hartman
Post by root
Logging in directly with the keyboard attached to the
machine (not ssh in) I get a prompt immediately after
entering root as the user. I have tried a number
Normally you shouldn't login directly as root, but you still should
get a prompt for a password IF root has got one.
Post by root
Any suggestions about what might cause this?
Show us the whole line for root from the /etc/shadow file.
And, the line for root from /etc/passwd
From the passwd(5) man page:
If the password field is a lower-case "x", then the encrypted password is
actually stored in the shadow(5) file instead; there must be a
corresponding line in the /etc/shadow file, or else the user account is
invalid.
[snip]
--
Lew Pitcher
"In Skills, We Trust"
root
2018-11-08 20:59:31 UTC
Permalink
Post by Lew Pitcher
Post by Eef Hartman
Post by root
Logging in directly with the keyboard attached to the
machine (not ssh in) I get a prompt immediately after
entering root as the user. I have tried a number
Normally you shouldn't login directly as root, but you still should
get a prompt for a password IF root has got one.
Post by root
Any suggestions about what might cause this?
Show us the whole line for root from the /etc/shadow file.
And, the line for root from /etc/passwd
If the password field is a lower-case "x", then the encrypted password is
actually stored in the shadow(5) file instead; there must be a
corresponding line in the /etc/shadow file, or else the user account is
invalid.
[snip]
/etc/passwd file had a null second entry. Thanks
Jimmy Johnson
2018-11-11 05:46:27 UTC
Permalink
Post by root
One of my machines doesn't ask for a password at login. There
is a password set by passwd, and the /etc/shadow file shows
c1:12345:respawn:/sbin/agetty 38400 tty1 linux --noclear
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
Logging in directly with the keyboard attached to the
machine (not ssh in) I get a prompt immediately after
entering root as the user. I have tried a number
of things short of re-installing the whole system.
Any suggestions about what might cause this?
Thanks.
Okay, so you say you can login as root, well do it and then type #
'passwd root' in the console and enter a root passwd and see if that
solves your problem. Also check your display manager, kdm or what ever
you are using and see if it is set to do auto login.
--
Jimmy Johnson

Slackware64 14.2 - KDE 4.14.32 - AMD A8-7600 - EXT4 at sda9
Registered Linux User #380263
Loading...