Morning All,

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

You don't need a live-usb/cd.
If your boot system is grub you only have to change command to exec=/bin/bash

Once you are in your system you can change root password and others.


Toni Mas

Missatge de Stanislav Vlasov <stanislav.v.v@gmail.com> del dia dt., 17
de gen. 2023 a les 7:15:

вт, 17 янв. 2023 г. в 11:01, David <david.g_jones@ntlworld.com>:

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

You can't.
But you can set new password, if you boot from live-usb/live-cd, mount
your system to dir and run `chroot dir && passwd $user`

--
Stanislav

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

вт, 17 янв. 2023 г. в 11:01, David <david.g_jones@ntlworld.com>:

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

You can't.
But you can set new password, if you boot from live-usb/live-cd, mount
your system to dir and run `chroot dir && passwd $user`

--
Stanislav

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

futureproofing could include encrypting passwords then logging those on
paper in encrypted form. Just remember where you keep that log and
remember your encryption for recovery if you forget your password again.
Us totally blind people not only have braille as an encryption technique
but other forms of writing we can use in braille for additional
encryption.



Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Tue, 17 Jan 2023, Stanislav Vlasov wrote:

??, 17 ???. 2023 ?. ? 11:01, David <david.g_jones@ntlworld.com>:

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

You can't.
But you can set new password, if you boot from live-usb/live-cd, mount
your system to dir and run `chroot dir && passwd $user`

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 17 Jan 2023, Stanislav Vlasov wrote:

??, 17 ???. 2023 ?. ? 11:01, David <david.g_jones@ntlworld.com>:

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

You can't.
But you can set new password, if you boot from live-usb/live-cd, mount
your system to dir and run `chroot dir && passwd $user`

One other thing you can do if you don't have a quick and easy way to
boot is to manually replace the hash in /etc/shadow with one that you do
know the password for. (This might be the case, for example, where the
USB stick is for booting ARM but all your other machines are x86, mount,
change password, umount is much quicker than trying to work out how to
live boot a headless arm system...)

This is something I did in ancient times when most systems still used
crypt and the system I was having problems with was the only one (so
far) that had been converted to use SHA? hashes. I replaced root's hash,
which I'd forgotten with that of my user account, which I did know.

And if you don't have any hashes that you know the password for then ask
here, someone can generate one for you - or see this thread:

https://unix.stackexchange.com/questions/81240/manually-generate-password-for-etc-shadow

Obviously manually editing these files isn't something to be done
without care. I always have backups so worst case is "restore from
backup" and not "I've lost everything"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 17-01-2023, à 07:58:40 +0000, Tim Woodall a écrit :

One other thing you can do if you don't have a quick and easy way to
boot is to manually replace the hash in /etc/shadow with one that you do
know the password for. (This might be the case, for example, where the
USB stick is for booting ARM but all your other machines are x86, mount, >change password, umount is much quicker than trying to work out how to
live boot a headless arm system...)

Easier would be to delete the second field in /etc/shadow for root, so there won't be anymore root password (it's empty). You can then create one with the 'passwd' command.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2023-01-17 at 09:51 +0100, DdB wrote:

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list?

Yes. It's a common occurrence, and trivial to deal with - if you have
physical access to the computer or disk. And if you have such access
then that password isn't actually protecting anything you couldn't do
without the password.

If you google "linux forgotten root password" then you will find these techniques are explained all over the web, e.g. Redhat's site, Arch
wiki etc.

--
Tixy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello

On 2023-01-17 08:58, Tim Woodall wrote:

On Tue, 17 Jan 2023, Stanislav Vlasov wrote:

??, 17 ???. 2023 ?. ? 11:01, David <david.g_jones@ntlworld.com>:

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in
/etc/passwd
and /etc/shadow

In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can
I
read this string?

You can't.
But you can set new password, if you boot from live-usb/live-cd, mount
your system to dir and run `chroot dir && passwd $user`

One other thing you can do if you don't have a quick and easy way to
boot is to manually replace the hash in /etc/shadow with one that you
do
know the password for. (This might be the case, for example, where the
USB stick is for booting ARM but all your other machines are x86,
mount,
change password, umount is much quicker than trying to work out how to
live boot a headless arm system...)

No, don't do that. It's requires to do more steps manually and might
lead to less security. And you need to make sure to use you use
cryptographic salt. crypt, the utility used to set passwords stored in /etc/shadow, use salts. There is just to many things you could do wrong, especially if you use a different tool to henerate the password and
trust it default settings.

For instance, you might choose (or use by default) the "wrong"
encryption when you generate the password, which might by less secure
than the default one. For instance, I just realised after readding this thread and checking, Debian 11 now uses yescrypt ($y$ prefix, see
crypt(5) man entry: `man 5 crypt`). If I replaced the hash manually, I
would probably used an older encryption algo without realizing it…

You're better off editing /etc/shadow and remove instead of replacing
the second field, which is the hash with it's encryption identifier
prefix ($*$) of the salted password. Then boot and log into your now-passwordless user account, then set a password again, as you would
normally normally, using `passwd` command.

IMPORTANT NOTE: Not sure if you need to edit /etc/passwd to remove the
second field as well, the "x" that indicated a hidden/hashed password is used/expected, before rebooting to re-set your password. Last time I did
that, multiples "debian-stable-versions ago", I remove it "just in case"
as it doesn't cost anything whether it's necessary or not.

This is something I did in ancient times when most systems still used
crypt and the system I was having problems with was the only one (so
far) that had been converted to use SHA? hashes. I replaced root's
hash,
which I'd forgotten with that of my user account, which I did know.

And if you don't have any hashes that you know the password for then
ask
here, someone can generate one for you - or see this thread:

https://unix.stackexchange.com/questions/81240/manually-generate-password-for-etc-shadow

Obviously manually editing these files isn't something to be done
without care. I always have backups so worst case is "restore from
backup" and not "I've lost everything"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 17 Jan 2023 09:51:46 +0100
DdB <debianlist@potentially-spam.de-bruyn.de> wrote:

Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:

вт, 17 янв. 2023 г. в 11:01, David <david.g_jones@ntlworld.com>:

Looking on the internet it says the passwords are stored in
/etc/passwd and /etc/shadow

In /etc/shadow only password's hashes, some data, one-way
calculated from password string.

The password string in /etc/shadow looks as if it's encoded, how
can I read this string?

You can't.

Everyone (and their friend) seem to know, how to work around this,
which apparently is common debian knowledge (which is nice).

It's common Internet knowledge generally. Google will find you a
method, and will also find you a utility to fix a lost password in
Windows, if you can trust it.

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

First rule of security: keep your computer physically secure. If it's
portable, encrypt it, if it isn't, generally don't, because encryption
really is impossible to recover if the key is lost. My laptop isn't
encrypted, but all significant data is stored in a VeraCrypt volume. I
don't care if the machine is booted by a thief, because I'll never see
it again, and I have backup copies of the data.

--
Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
On 17.01.2023 13:51, DdB wrote:

Everyone (and their friend) seem to know, how to work around this, which apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

This is not hacking. How to reset password on your computer is the is
most basic system administration knowledge everyone should know.
This information is described in system administration manual and mostly applies for any Linux-based system.

Since it is so easy to reset user password on a computer you have
physical access to, and it doesn't matter if OS is Windows or Linux-based,
so making your user password so long and complex, to the point it could
be forgotten, is so not necessary.
Even 4-6 digit password is enough to secure access to local user account
and impossible to forget.

Long and complex passwords are only necessary for non-local user
accounts, e.g. Web-sites, e-Mail accounts, or any accounts exposed to
the Internet.

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 17.01.2023 13:51, DdB wrote:</div>
<blockquote type="cite" cite="mid:2e9255e5-24ba-4750-e091-f82633626d53@potentially-spam.de-bruyn.de">
<pre class="moz-quote-pre" wrap="">Everyone (and their friend) seem to know, how to work around this, which
apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.
</pre>
</blockquote>
This is not hacking. How to reset password on your computer is the
is most basic system administration knowledge everyone should know.<br>
This information is described in system administration manual and
mostly applies for any Linux-based system.<br>
<br>
Since it is so easy to reset user password on a computer you have
physical access to, and it doesn't matter if OS is Windows or
Linux-based,<br>
so making your user password so long and complex, to the point it
could be forgotten, is so not necessary.<br>
Even 4-6 digit password is enough to secure access to local user
account and impossible to forget.<br>
<br>
Long and complex passwords are only necessary for non-local user
accounts, e.g. Web-sites, e-Mail accounts, or any accounts exposed
to the Internet.<br>
<br>
<div class="moz-signature">-- <br>
<tt>With kindest regards, Alexander.<br>
<br>
⢀⣴⠾⠻⢶⣦⠀ <br>
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system<br>
⢿⡄⠘⠷⠚⠋⠀ <a class="moz-txt-link-freetext" href="https://www.debian.org">https://www.debian.org</a><br>
⠈⠳⣄⠀⠀⠀⠀ <br>
</tt></div>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello

On 2023-01-17 09:51, DdB wrote:

Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:

вт, 17 янв. 2023 г. в 11:01, David <david.g_jones@ntlworld.com>:

Looking on the internet it says the passwords are stored in
/etc/passwd
and /etc/shadow

In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can
I
read this string?

You can't.

Everyone (and their friend) seem to know, how to work around this,
which
apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

just my 2 cents
DdB

It's not hacking. It's typical administration system stuff. A required knowledge so you don't end up locked out of your own system in
non-encypted installation. It requires physical access to the computer,
so applicable from distance as you need to either
- remove then mount the hard drive on another machine.
- boot from a live USB.
- boot into GRUB's rescue-shell.

But if you're worried about physical access to your computer (as a
laptop than can be easily stolen, or left in hotel room, or whatever),
an account password isn't going to protect your data or from someone
alter your password /install fishy stuff…

In such case, you need to protect your system by encrypt it. And not
just encrypt /home as the files you need to protect in order to protect
the system from password tampering are NOT in /home. Debian installer
has an option to encrypt the system quite easily, you just need time for
the initial installation is it spends an good amount of writing random
data (mère or less acceptable duration depending on your disk speed and CPU performance). And re-ecrypt it when needed/when algorithmes get
broken and new better ones become the new recommended standard/if your decryption passphrase is known by someone else/whatever.

But it only makes sense of your decryption key has a long complex
passphase. An easily brute-forceable or guessable password for disk
encryption defeats the very own purpose of disk encryption. It basically
means if you forget the passphrase, you're pretty much screwed until you
either remembrer it, or reinstall and reconfigure everything. so you
need to have backup [1] in secure place.

---
1. But again, backups are required anyway, encrypted installs or not.
Storage support do fail and/or get stolen. Never trust a single storage
device. Or a "cloud" backup bullshit. Cloud being nothing else than
someone's else computer who can do whatever they want on it, kick users whenever they please or abuse personal data for profit if they want to
(whether they do it in a "legal" or semi-legal way or not doesn't
matter. As they have the technical means to do so and users have no
means to check what's going on [2]. Including when data is "encrypted" IF encryption and decryption happens on their systems).
2. It's already hard enough to know what's going on on one's own
computer, let alone distant systems managed by someone else…

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2023-01-17 at 09:51 +0100, DdB wrote:

Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:

вт, 17 янв. 2023 г. в 11:01, David <david.g_jones@ntlworld.com>:

Looking on the internet it says the passwords are stored in
/etc/passwd
and /etc/shadow

 In /etc/shadow only password's hashes, some data, one-way
calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how
can I
read this string?

You can't.

Everyone (and their friend) seem to know, how to work around this,
which
apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to
teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

For this sort of `cracking', there would need to be direct access to
the machine. It would involve house breaking after having discerned the
address in the other country the target resided in, and travelling
there.
Cheers!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le mardi 17 janvier 2023 à 09:51 +0100, DdB a écrit :

Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
Everyone (and their friend) seem to know, how to work around this,
which
apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to
teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

Local user is king. They can change boot-loader, extract disks to put
them in another computer ... Not only Debian-related, much computer-
related ^^

To prevent that, you should encrypt your disks, so no-one can mount
them and change your passwords/read your data. (But you won't recover
for lostt passphrase, then ;))

Regards,

--
Bastien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 17, 2023 at 09:51:46AM +0100, DdB wrote:

[...]

Everyone (and their friend) seem to know, how to work around this, which apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

You don't improve security by keeping knowledge secret.

On the contraty, only knowing what's possible you can make your
system more secure.

Please, don't advocate for knowledge being reserved to a closed
cast of "priests". Arguably, we're here for making knowledge
available to all.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCY8Z3sAAKCRAFyCz1etHa RpFgAJ9Dk8aAzYI4rRmK7KvcgLGd8oSYdQCfdH+wB8S9NpkgZLa6VkmL1ib+2J8=
=1z5a
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 17, 2023 at 1:01 AM David <david.g_jones@ntlworld.com> wrote:

Morning All,

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

David.

Do you have a root account? If so then log in as root and run `passwd <UserName> <NewPassword>`

If you do not have root then you can login using single user mode and set a root password. https://devconnected.com/single-user-mode-secure-boot-on-ubuntu-debian/

Tim

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 17, 2023 at 1:01 AM David &lt;<a href="mailto:david.g_jones@ntlworld.com">david.g_jones@ntlworld.com</a>&gt; wrote:<br></div><blockquote
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Morning All,<br>

I have forgotten my password to a Debian PC using an SD stick as it&#39;s<br> main drive.<br>

Looking on the internet it says the passwords are stored in /etc/passwd<br>
and /etc/shadow<br>

The password string in /etc/shadow looks as if it&#39;s encoded, how can I<br> read this string?<br>

David.<br>

</blockquote></div><div><br></div>Do you have a root account? If so then log in as root and run `passwd &lt;UserName&gt; &lt;NewPassword&gt;`<div><

pass phrase length and complexity. At least 16 characters; Starts and
ends with a letter, has two symbols, two numbers two upper-case two
lower-case. Nothing found in dictionaries in pass phrase no keyboard
walking, no recognizeable keyboard patterns may work for a few seconds.



Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Tue, 17 Jan 2023, davenull@tuxfamily.org wrote:

Hello

On 2023-01-17 09:51, DdB wrote:

Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:

??, 17 ???. 2023 ?. ? 11:01, David <david.g_jones@ntlworld.com>:

Looking on the internet it says the passwords are stored in /etc/passwd >>> and /etc/shadow

In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can I >>> read this string?

You can't.

Everyone (and their friend) seem to know, how to work around this, which apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

just my 2 cents
DdB

It's not hacking. It's typical administration system stuff. A required knowledge so you don't end up locked out of your own system in non-encypted installation. It requires physical access to the computer, so applicable from distance as you need to either
- remove then mount the hard drive on another machine.
- boot from a live USB.
- boot into GRUB's rescue-shell.

But if you're worried about physical access to your computer (as a laptop than
can be easily stolen, or left in hotel room, or whatever), an account password
isn't going to protect your data or from someone alter your password /install fishy stuff?

In such case, you need to protect your system by encrypt it. And not just encrypt /home as the files you need to protect in order to protect the system from password tampering are NOT in /home. Debian installer has an option to encrypt the system quite easily, you just need time for the initial installation is it spends an good amount of writing random data (m?re or less acceptable duration depending on your disk speed and CPU performance). And re-ecrypt it when needed/when algorithmes get broken and new better ones become the new recommended standard/if your decryption passphrase is known by someone else/whatever.

But it only makes sense of your decryption key has a long complex passphase. An easily brute-forceable or guessable password for disk encryption defeats the very own purpose of disk encryption. It basically means if you forget the passphrase, you're pretty much screwed until you either remembrer it, or reinstall and reconfigure everything. so you need to have backup [1] in secure
place.

---
1. But again, backups are required anyway, encrypted installs or not. Storage support do fail and/or get stolen. Never trust a single storage device. Or a "cloud" backup bullshit. Cloud being nothing else than someone's else computer
who can do whatever they want on it, kick users whenever they please or abuse personal data for profit if they want to (whether they do it in a "legal" or semi-legal way or not doesn't matter. As they have the technical means to do so and users have no means to check what's going on [2]. Including when data is "encrypted" IF encryption and decryption happens on their systems).
2. It's already hard enough to know what's going on on one's own computer, let
alone distant systems managed by someone else?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 17, 2023 at 07:38:28AM +0100, Toni Mas Soler wrote:

You don't need a live-usb/cd.
If your boot system is grub you only have to change command to exec=/bin/bash

Once you are in your system you can change root password and others.

For the record, the kernel parameter you wanted was "init=/bin/bash".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:

Easier would be to delete the second field in /etc/shadow for root, so there won't be anymore root password (it's empty). You can then create one with the 'passwd' command.

If you can edit the /etc/shadow file, you're already root, which means
you can simply run "passwd root" to set a new password. You will not
be prompted for the old password, so there's no need to clear the old
password hash preemptively.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:

Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :

On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:

Easier would be to delete the second field in /etc/shadow for root, so there
won't be anymore root password (it's empty). You can then create one with the
'passwd' command.

If you can edit the /etc/shadow file, you're already root, which means
you can simply run "passwd root" to set a new password. You will not
be prompted for the old password, so there's no need to clear the old password hash preemptively.

You're right if you're editing the file in the OS, but not if you have accessed data from a live-cd, which was what I was thinking. Sorry.

Or mounted the disk externally on another system.

Still there's the -R (chroot) option for passwd(1) as an alternative
for those cases. But editing is definitely a valid option (esp. if
you are dealing with an OS you suspect format compatibility problems
because of its age or some such).

There is more than... and so on :)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCY8ac6AAKCRAFyCz1etHa RuhzAJ9P+3SpFfUh39kWq8udUsxyVz0IzACePSHXb3HZ/5dZfgyfU2E1s7215rM=
=jQE2
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:

Le 17-01-2023, � 07:19:04 -0500, Greg Wooledge a �crit :

On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:

Easier would be to delete the second field in /etc/shadow for root, so there
won't be anymore root password (it's empty). You can then create one with the
'passwd' command.

If you can edit the /etc/shadow file, you're already root, which means
you can simply run "passwd root" to set a new password. You will not
be prompted for the old password, so there's no need to clear the old password hash preemptively.

You're right if you're editing the file in the OS, but not if you have accessed data from a live-cd, which was what I was thinking. Sorry.

If you went in via a Live CD, and mounted the Debian root partition,
the next step is to chroot into the Debian root partition. Then you
can run "passwd root" in the chroot shell. Then exit from the shell,
and unmount the Debian partition.

Of course, your way (which I'm assuming is "mount the Debian root
partition, edit the /debian/etc/shadow file to clear the hash, unmount
it, reboot into Debian, login as root with no password, and run "passwd")
also works, but it's a bit more effort.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :

On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:

Easier would be to delete the second field in /etc/shadow for root, so there >> won't be anymore root password (it's empty). You can then create one with the
'passwd' command.

If you can edit the /etc/shadow file, you're already root, which means
you can simply run "passwd root" to set a new password. You will not
be prompted for the old password, so there's no need to clear the old >password hash preemptively.

You're right if you're editing the file in the OS, but not if you have
accessed data from a live-cd, which was what I was thinking. Sorry.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 17-01-2023, à 08:07:02 -0500, Greg Wooledge a écrit :

On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:

Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :

On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:

Easier would be to delete the second field in /etc/shadow for root, so there
won't be anymore root password (it's empty). You can then create one with the
'passwd' command.

If you can edit the /etc/shadow file, you're already root, which means
you can simply run "passwd root" to set a new password. You will not
be prompted for the old password, so there's no need to clear the old
password hash preemptively.

You're right if you're editing the file in the OS, but not if you have
accessed data from a live-cd, which was what I was thinking. Sorry.

If you went in via a Live CD, and mounted the Debian root partition,
the next step is to chroot into the Debian root partition. Then you
can run "passwd root" in the chroot shell. Then exit from the shell,
and unmount the Debian partition.

chroot can be tricky for newcommers…

Of course, your way (which I'm assuming is "mount the Debian root
partition, edit the /debian/etc/shadow file to clear the hash, unmount
it, reboot into Debian, login as root with no password, and run "passwd") >also works, but it's a bit more effort.

Sure but it's pretty straightforward and simple to understand.

Anyway, thanks for the other options, always good to have a refresh :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 17, 2023 at 03:02:03PM +0100, steve wrote:

Le 17-01-2023, à 08:07:02 -0500, Greg Wooledge a écrit :

On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:

Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :

If you went in via a Live CD, and mounted the Debian root partition,
the next step is to chroot into the Debian root partition [...]

chroot can be tricky for newcommers…

That's why passwd is nice to us and has the -R option :)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCY8arMQAKCRAFyCz1etHa RhQAAJ4kb8/Pf0L4XIDapa5vP/R/4bXvuACeOfFGjmB7pBimwYV2Fb3Ks34J9L4=
=2lMs
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 17, 2023 at 03:30:32PM +0100, steve wrote:

Le 17-01-2023, à 15:05:37 +0100, tomas@tuxteam.de a écrit :

chroot can be tricky for newcommers…

That's why passwd is nice to us and has the -R option :)

Thanks Tomas, didn't know that option. Will go to bed a bit less stupid tonight :-)

Alas, as far as I'm concerned, I fear I'm leaking at least as much
wisdom as I try to fill from the top :-)

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCY8azfgAKCRAFyCz1etHa Rp+FAJ9bXsts1wCBkDcSPI3yC4PYaiy1vgCaA8RYkkBfJaLfnGmzL27EuleKGZI=
=vUHQ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 17-01-2023, à 15:05:37 +0100, tomas@tuxteam.de a écrit :

chroot can be tricky for newcommers…

That's why passwd is nice to us and has the -R option :)

Thanks Tomas, didn't know that option. Will go to bed a bit less stupid
tonight :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 17 Jan 2023 15:02:03 +0100
steve <dlist@bluewin.ch> wrote:

Le 17-01-2023, à 08:07:02 -0500, Greg Wooledge a écrit :

If you went in via a Live CD, and mounted the Debian root partition,
the next step is to chroot into the Debian root partition. Then you
can run "passwd root" in the chroot shell. Then exit from the shell,
and unmount the Debian partition.

chroot can be tricky for newcommers…

No harder than the easy first bit of an installation (i.e. language,
keyboard etc.)

About two or three minutes gets you to the point where you can select a
root drive and chroot into it, all the mounting details handled for you.

--
Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/17/23 01:01, David wrote:

Morning All,

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

David.

.

TBH, you can't, its a one way hash, add a "single" to the grub boot line
which should give you a text shell, from which you can set a new root
pw. Make it hard for the hackers, minimum 20 characters, every character
you add, multiplies the effort they have to use to find it.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 17, 2023 at 3:55 AM DdB
<debianlist@potentially-spam.de-bruyn.de> wrote:

Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:

вт, 17 янв. 2023 г. в 11:01, David <david.g_jones@ntlworld.com>:

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

You can't.

Everyone (and their friend) seem to know, how to work around this, which apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

There's nothing extraordinary in the answers to recover a lost
password. Reiterating them here does not provide additional advantage
to an attacker.

If you don't have physical security on your machine, then you are
already pwn'd. You may not realize it yet, but it's already game over.

Jeff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)