Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #268391 > unrolled thread

Root password strength

Back to article view | Back to linux.debian.user

Contents

  Root password strength Jan Krapivin <daydreamer199005@gmail.com> - 2024-03-19 15:50 +0100
    Re: Root password strength Jan Krapivin <daydreamer199005@gmail.com> - 2024-03-19 16:00 +0100
    Re: Root password strength Dan Ritter <dsr@randomstring.org> - 2024-03-19 16:10 +0100
      Re: Root password strength debian-user@howorth.org.uk - 2024-03-19 16:50 +0100
        Re: Root password strength Greg Wooledge <greg@wooledge.org> - 2024-03-19 21:20 +0100
    Re: Root password strength Greg Wooledge <greg@wooledge.org> - 2024-03-19 16:10 +0100
      Re: Root password strength jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-19 21:30 +0100
        Re: Root password strength <tomas@tuxteam.de> - 2024-03-20 06:40 +0100
          Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 07:10 +0100
            Re: Root password strength tomas@tuxteam.de - 2024-03-20 08:40 +0100
          Re: Root password strength jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-20 08:50 +0100
            Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 12:10 +0100
              Re: Root password strength <tomas@tuxteam.de> - 2024-03-20 12:20 +0100
                Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 13:20 +0100
              Re: Root password strength jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-20 12:30 +0100
                Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 13:10 +0100
                Re: Root password strength Dan Ritter <dsr@randomstring.org> - 2024-03-20 13:40 +0100
              Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 14:30 +0100
                Re: Root password strength <tomas@tuxteam.de> - 2024-03-20 14:50 +0100
    Re: Root password strength Marco Moock <mm@dorfdsl.de> - 2024-03-19 16:40 +0100
    Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-19 20:40 +0100
      Re: Root password strength debian-user@howorth.org.uk - 2024-03-19 22:00 +0100
    Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 16:00 +0100
      Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 16:20 +0100
        Re: Root password strength Jan Krapivin <daydreamer199005@gmail.com> - 2024-03-20 16:30 +0100
          Re: Root password strength John Hasler <john@sugarbit.com> - 2024-03-20 17:10 +0100
            Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 17:20 +0100
              Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 18:50 +0100
                Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 19:10 +0100
                  Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 19:30 +0100
                Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 19:50 +0100
                Re: Root password strength Lee <ler762@gmail.com> - 2024-03-20 20:50 +0100
                  Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 21:00 +0100
                    Re: Root password strength Lee <ler762@gmail.com> - 2024-03-20 21:30 +0100
            Re: Root password strength <tomas@tuxteam.de> - 2024-03-20 18:50 +0100
              Re: Root password strength John Hasler <john@sugarbit.com> - 2024-03-20 19:50 +0100
          Re: Root password strength "Alexander V. Makartsev" <avbetev@gmail.com> - 2024-03-21 20:40 +0100
            Re: Root password strength Jan Krapivin <daydreamer199005@gmail.com> - 2024-03-22 11:00 +0100
              Re: Root password strength Joe <joe@jretrading.com> - 2024-03-22 12:00 +0100
              Re: Root password strength "Alexander V. Makartsev" <avbetev@gmail.com> - 2024-03-22 13:30 +0100
                Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-23 10:50 +0100
              Re: Root password strength Lee <ler762@gmail.com> - 2024-03-23 01:10 +0100
                Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-23 11:30 +0100
        Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 16:50 +0100
      Re: Root password strength John Hasler <john@sugarbit.com> - 2024-03-20 17:00 +0100
        Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 17:10 +0100
          Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 17:30 +0100
            Re: Root password strength Max Nikulin <manikulin@gmail.com> - 2024-03-20 17:50 +0100
            Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 18:00 +0100
              Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 18:40 +0100
                Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 18:50 +0100
                  Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 19:20 +0100
                    Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 19:40 +0100
                      Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 21:20 +0100
                      Re: Root password strength Curt <curty@free.fr> - 2024-03-21 17:50 +0100
                  Re: Root password strength John Hasler <john@sugarbit.com> - 2024-03-20 19:40 +0100
                    Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 19:50 +0100
          Re: Root password strength John Hasler <john@sugarbit.com> - 2024-03-20 17:30 +0100
            Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 18:00 +0100
          Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 19:20 +0100
        Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 17:10 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#268391 — Root password strength

[Multipart message — attachments visible in raw view] — view raw

I read Debian Administrator's handbook now. And there are such words:

The root user's password should be long (12 characters or more) and
impossible to guess. Indeed, any computer (and a fortiori any server)
connected to the Internet is regularly targeted by automated connection
attempts with the most obvious passwords. Sometimes it may even be subject
to dictionary attacks, in which many combinations of words and numbers are
tested as password. Avoid using the names of children or parents, dates of
birth, etc.: many of your co-workers might know them, and you rarely want
to give them free access to the computer in question.

The thing is my password is very easy now, and i haven't thought about
*"automated
connection attempts"*, that sounds rather... scary? My password is easy
because i am not afraid of direct physical access to the computer.

But... if there is a serious network danger, then i should change my
password of course. But how strong it should be? If we speak about network
attacks... it should be like 32 symbols with special symbols? Or this
paragraph in a handbook is rather paranoid?

I have activated sudo now for my regular user. Can it (password of regular
user) be less sophisticated than root password? Because it would be rather
difficult to enter 32 symbols every time i wake my PC after suspend.

[toc] | [next] | [standalone]

#268394

[Multipart message — attachments visible in raw view] — view raw

> The threats are different for:
>
> - a laptop that travels and can be stolen
> - a desktop that does not leave your residence
> - a server that accepts connections from the outside world
>
>
> Check whether you are running ssh:
>

It is a simple home desktop PC

*@deb:~$ /sbin/service ssh status*

*Unit ssh.service could not be found.*

*@deb:~$ sudo /sbin/service ssh status*


*[sudo] password for ***: *

*Unit ssh.service could not be found.*

[toc] | [prev] | [next] | [standalone]

#268395

Jan Krapivin wrote: 
> I read Debian Administrator's handbook now. And there are such words:
> 
> The root user's password should be long (12 characters or more) and
> impossible to guess. 
...

 
> The thing is my password is very easy now, and i haven't thought about
> *"automated
> connection attempts"*, that sounds rather... scary? My password is easy
> because i am not afraid of direct physical access to the computer.
> 
> But... if there is a serious network danger, then i should change my
> password of course. But how strong it should be? If we speak about network
> attacks... it should be like 32 symbols with special symbols? Or this
> paragraph in a handbook is rather paranoid?
> 
> I have activated sudo now for my regular user. Can it (password of regular
> user) be less sophisticated than root password? Because it would be rather
> difficult to enter 32 symbols every time i wake my PC after suspend.

The threats are different for:

- a laptop that travels and can be stolen
- a desktop that does not leave your residence
- a server that accepts connections from the outside world

If you have a laptop, you want to have your filesystem encrypted
(LUKS or ZFS encryption, most likely) and protected by a 12+
character password.

If you have a desktop, perhaps you feel it is at low risk. 

If you have a machine that runs the ssh daemon, you should not
use passwords at all for remote logins; you should use ssh keys.

Check whether you are running ssh:

/sbin/service ssh status

If it is active, use sudo to edit /etc/ssh/sshd_config to lock
down access. (It may be that you don't want it running at all,
too.)

-dsr-

[toc] | [prev] | [next] | [standalone]

#268400

Dan Ritter <dsr@randomstring.org> wrote:
> Jan Krapivin wrote: 
> > I read Debian Administrator's handbook now. And there are such
> > words:
> > 
> > The root user's password should be long (12 characters or more) and
> > impossible to guess.   
> ...
> 
>  
> > The thing is my password is very easy now, and i haven't thought
> > about *"automated
> > connection attempts"*, that sounds rather... scary? My password is
> > easy because i am not afraid of direct physical access to the
> > computer.
> > 
> > But... if there is a serious network danger, then i should change my
> > password of course. But how strong it should be? If we speak about
> > network attacks... it should be like 32 symbols with special
> > symbols? Or this paragraph in a handbook is rather paranoid?
> > 
> > I have activated sudo now for my regular user. Can it (password of
> > regular user) be less sophisticated than root password? Because it
> > would be rather difficult to enter 32 symbols every time i wake my
> > PC after suspend.  
> 
> The threats are different for:
> 
> - a laptop that travels and can be stolen
> - a desktop that does not leave your residence
> - a server that accepts connections from the outside world
> 
> If you have a laptop, you want to have your filesystem encrypted
> (LUKS or ZFS encryption, most likely) and protected by a 12+
> character password.
> 
> If you have a desktop, perhaps you feel it is at low risk. 
> 
> If you have a machine that runs the ssh daemon, you should not
> use passwords at all for remote logins; you should use ssh keys.
> 
> Check whether you are running ssh:
> 
> /sbin/service ssh status

It's not called ssh; it is sshd
Also nowadays it's more usual to say

 $ systemctl status sshd

> If it is active, use sudo to edit /etc/ssh/sshd_config to lock
> down access. (It may be that you don't want it running at all,
> too.)
> 
> -dsr-
> 

[toc] | [prev] | [next] | [standalone]

#268405

On Tue, Mar 19, 2024 at 03:49:06PM +0000, debian-user@howorth.org.uk wrote:
> Dan Ritter <dsr@randomstring.org> wrote:
> > Check whether you are running ssh:
> > 
> > /sbin/service ssh status
> 
> It's not called ssh; it is sshd
> Also nowadays it's more usual to say
> 
>  $ systemctl status sshd

On Debian, the systemd service name for openssh-server is "ssh", not
"sshd".  However, Debian offers an *alias* named "sshd" which allows
people to type your command and still get a meaningful result.

However, it should be noted that "ssh" is the actual service name, which
matters if you're going to do something like creating a drop-in override.
Those need to be done with the correct name instead of the alias name.

[toc] | [prev] | [next] | [standalone]

#268396

On Tue, Mar 19, 2024 at 05:42:55PM +0300, Jan Krapivin wrote:
> The root user's password should be long (12 characters or more) and
> impossible to guess. Indeed, any computer (and a fortiori any server)
> connected to the Internet is regularly targeted by automated connection
> attempts with the most obvious passwords. [...]

For most people, this really isn't a concern, because they either don't
run an ssh server at all, or they use the default sshd_config which does
not allow root logins.

The only time you need to worry about this is if you:

 * Run an ssh server, AND
 * Accept ssh connections from the public Internet, AND
 * Have changed the sshd_config file to allow ssh root logins.

[toc] | [prev] | [next] | [standalone]

#268406

On 19/3/24 23:02, Greg Wooledge wrote:
> On Tue, Mar 19, 2024 at 05:42:55PM +0300, Jan Krapivin wrote:
>> The root user's password should be long (12 characters or more) and
>> impossible to guess. Indeed, any computer (and a fortiori any server)
>> connected to the Internet is regularly targeted by automated connection
>> attempts with the most obvious passwords. [...]
> For most people, this really isn't a concern, because they either don't
> run an ssh server at all, or they use the default sshd_config which does
> not allow root logins.
>
> The only time you need to worry about this is if you:
>
>   * Run an ssh server, AND
>   * Accept ssh connections from the public Internet, AND
>   * Have changed the sshd_config file to allow ssh root logins.
>

A preferred method of securing root on public access systems is to use 
client certificates. Some implementations will have no password for root 
so unless you have the certificate you will never be able to log in.

Cloud servers such as hosted by AWS typically do this.

A 'safer' implementation will not even expose an ssh port. Instead there 
will be a certificate based VPN where you first need a certificate to 
connect and then you need a separate certificate to log in as root. A 
further enhancement of security is to use 2-factor authentication - 
which is supported in sshd via pam.

For me to get remote root access to my systems I first need to connect 
to my firewall with a certificate based vpn; then I need to present a 
root client certificate; and then I need to enter a 2fa code.

Even from within my network I need a client certificate and 2fa to 
connect to an sshd server.

[toc] | [prev] | [next] | [standalone]

#268410

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 20, 2024 at 04:22:29AM +0800, jeremy ardley wrote:

> A 'safer' implementation will not even expose an ssh port. Instead there
> will be a certificate based VPN where you first need a certificate to
> connect and then you need a separate certificate to log in as root. A
> further enhancement of security is to use 2-factor authentication - which is
> supported in sshd via pam.

How will a "VPN" with a "certificate" (whatever that means in this context)
be more secure than a SSH (assuming key pair authentication, not password)?

They are doing the same dance (key exchange, key pair validation, session
key establishment) -- the "certificate" part is just a step further (and,
BTW, SSH can do that, too), which just eases key management (at the expense
of security: you have but one more moving part).

The "port" thing stays the same: the VPN server uses a TCP connection, too.

Moving the port to a non-standard number, using fail2ban, firewall knocking
and those things don't increase security *directly* -- they just remove
noise from the logs, which eases the admin's task and thus increase security
indirectly.

There's no magic.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#268411

On Wed, Mar 20, 2024 at 1:32 AM <tomas@tuxteam.de> wrote:
>
> On Wed, Mar 20, 2024 at 04:22:29AM +0800, jeremy ardley wrote:
>
> > A 'safer' implementation will not even expose an ssh port. Instead there
> > will be a certificate based VPN where you first need a certificate to
> > connect and then you need a separate certificate to log in as root. A
> > further enhancement of security is to use 2-factor authentication - which is
> > supported in sshd via pam.
>
> How will a "VPN" with a "certificate" (whatever that means in this context)
> be more secure than a SSH (assuming key pair authentication, not password)?

This may be more theoretical, but... IPSec uses
Encrypt-then-Authenticate (EtA), which is provably secure under random
models. In fact, I believe IPSec is IND-CCA2 secure (Ciphertext
Indistinguishability), which is a strong notion of security. SSH uses
Encrypt-and-Authenticate (E&A), which is provably insecure. The SSH
protocol leaks information because of the order of operations of
encryption and authentication.

As far as the certificate, I suspect it alludes to public key. Both
IPSec and SSH can use public key cryptography (as opposed to
passwords), so they are about equally secure (compared to passwords).
IPSec is actually a little stronger with provable security properties
because it uses HKDF after key agreement to derive bulk encryption
keys. And I believe IPSec performs a key conformation step, which
helps with the security proofs.

The IPSec standard is maintained by Hugo Krawczyk and associates. Hugo
is a world class cryptographer. That's why the IPSec protocol does not
have the theoretical defects of SSH (or TLS).

Krawczyk is also the author of The Order of Encryption and
Authentication for Protecting Communications,
<http://www.iacr.org/archive/crypto2001/21390309.pdf>. It is a very
good paper.

> They are doing the same dance (key exchange, key pair validation, session
> key establishment) -- the "certificate" part is just a step further (and,
> BTW, SSH can do that, too), which just eases key management (at the expense
> of security: you have but one more moving part).
>
> The "port" thing stays the same: the VPN server uses a TCP connection, too.
>
> Moving the port to a non-standard number, using fail2ban, firewall knocking
> and those things don't increase security *directly* -- they just remove
> noise from the logs, which eases the admin's task and thus increase security
> indirectly.
>
> There's no magic.

Jeff

[toc] | [prev] | [next] | [standalone]

#268412

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 20, 2024 at 02:01:44AM -0400, Jeffrey Walton wrote:
> On Wed, Mar 20, 2024 at 1:32 AM <tomas@tuxteam.de> wrote:
> >
> > On Wed, Mar 20, 2024 at 04:22:29AM +0800, jeremy ardley wrote:
> >
> > > A 'safer' implementation will not even expose an ssh port. Instead there
> > > will be a certificate based VPN where you first need a certificate to
> > > connect and then you need a separate certificate to log in as root. A
> > > further enhancement of security is to use 2-factor authentication - which is
> > > supported in sshd via pam.
> >
> > How will a "VPN" with a "certificate" (whatever that means in this context)
> > be more secure than a SSH (assuming key pair authentication, not password)?
> 
> This may be more theoretical, but... IPSec uses
> Encrypt-then-Authenticate (EtA), which is provably secure under random
> models. In fact, I believe IPSec is IND-CCA2 secure (Ciphertext
> Indistinguishability), which is a strong notion of security. SSH uses
> Encrypt-and-Authenticate (E&A), which is provably insecure. The SSH
> protocol leaks information because of the order of operations of
> encryption and authentication.

Of course it's not only theoretical. I took issue with the umbrella
statement "VPN", which might be IPSec or some variant of TLS, to
mention two ends of the scale.

We might have lots of ground to cover until the issues you mention
really matter, but at some point they will, for sure.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#268413

[Multipart message — attachments visible in raw view] — view raw

On 20/3/24 13:32, tomas@tuxteam.de wrote:
> How will a "VPN" with a "certificate" (whatever that means in this  > context) be more secure than a SSH (assuming key pair 
authentication, > not password)? > > They are doing the same dance (key 
exchange, key pair validation, > session key establishment) -- the 
"certificate" part is just a step > further (and, BTW, SSH can do that, 
too), which just eases key > management (at the expense of security: you 
have but one more moving > part). > > The "port" thing stays the same: 
the VPN server uses a TCP > connection, too. > > Moving the port to a 
non-standard number, using fail2ban, firewall > knocking and those 
things don't increase security *directly* -- they > just remove noise 
from the logs, which eases the admin's task and > thus increase security 
indirectly.

Benefits of running VPN rather that VPN + SSH or even just SSH:

- VPN only has only one 'hole' in the firewall.

- Providing VPN ingress through or to your firewall is a different 
security model to hosting a ssh server on your firewall.

- Accessing an internal host using SSH from an internal machine is yet 
another security model.

- A SSH server exposed to public will have less ability to detect and 
counter serious probes compared to a VPN server

If you go for the arrangement I use, you need have only one security 
mechanism for all internal ssh servers and that mechanism will also 
defend in the event the firewall is breached.

Then in isolation you can develop a security strategy for your public 
facing VPN ports as well as firewall configuration to mitigate any breach.

Regarding certificates, I issue VPN certificates to be installed on each 
remote device. I don't use public key.

For ssh use I issue secret keys to each user and maintain matching 
public keys in LDAP servers.  SSHD servers can get the public keys in 
real time by using the AuthorizedKeysCommand. If a secret key is 
compromised I simply remove the matching public key.

[users are locked out from uploading their public key using ssh-copy-id]

[toc] | [prev] | [next] | [standalone]

#268421

On 20 Mar 2024 15:46 +0800, from jeremy.ardley@gmail.com (jeremy ardley):
> Regarding certificates, I issue VPN certificates to be installed on each
> remote device. I don't use public key.

What exactly is this "certificate" that you speak of? In typical
usage, it means a public key plus some surrounding metadata, but you
say that you "don't use public key".


> For ssh use I issue secret keys to each user and maintain matching public
> keys in LDAP servers.  SSHD servers can get the public keys in real time by
> using the AuthorizedKeysCommand. If a secret key is compromised I simply
> remove the matching public key.
> 
> [users are locked out from uploading their public key using ssh-copy-id]

So the private keys aren't private, thereby invalidating a lot of
assumptions inherent in public key cryptography.

Also, are you saying that you do not let users rotate their keys
themselves; and if so, why on Earth not?

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#268422

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 20, 2024 at 11:03:16AM +0000, Michael Kjörling wrote:
> On 20 Mar 2024 15:46 +0800, from jeremy.ardley@gmail.com (jeremy ardley):
> > Regarding certificates, I issue VPN certificates to be installed on each
> > remote device. I don't use public key.
> 
> What exactly is this "certificate" that you speak of? In typical
> usage, it means a public key plus some surrounding metadata, but you
> say that you "don't use public key".

My take. I'm always a bit oversuspicious when umbrella words are thrown
around.

A certificate is (usually) a signed public key. You need it whenever
you need more complex key management (definitely not when things are
between your server and you).

> > For ssh use I issue secret keys to each user and maintain matching public
> > keys in LDAP servers [...]

> So the private keys aren't private, thereby invalidating a lot of
> assumptions inherent in public key cryptography.

We are using that schema in our (small) company, too. Private keys
are definitely private here (we don't "issue keys" to anyone, everyone
uploads their *public* keys to the LDAP).

> Also, are you saying that you do not let users rotate their keys
> themselves; and if so, why on Earth not?

Definitely. "Issuing keys" to people is a "crypto smell". I know,
it is being done far too often. People are too stupid to make their
key pairs, it is often said. But keeping people stupid is your
biggest security hole!

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#268425

On 20 Mar 2024 12:17 +0100, from tomas@tuxteam.de:
>>> For ssh use I issue secret keys to each user and maintain matching public
>>> keys in LDAP servers [...]
> 
>> So the private keys aren't private, thereby invalidating a lot of
>> assumptions inherent in public key cryptography.
> 
> We are using that schema in our (small) company, too. Private keys
> are definitely private here (we don't "issue keys" to anyone, everyone
> uploads their *public* keys to the LDAP).

Right; I have no issues with _that_ part. It's the _issuing_ of a
whole key pair that means that the private key _must_ have been
accessible to someone else at some point. In a scheme where the key
pair is generated by the user, the private key _may_ still be
accessible to others (for example through administrator access), but
that's a trade-off we always have to make when using a system
administered by someone else; and it can be mitigated by e.g. storing
the key on a SSH-capable Yubikey or in the TPM, along with a
decent-strength passphrase.


> Definitely. "Issuing keys" to people is a "crypto smell". I know,
> it is being done far too often. People are too stupid to make their
> key pairs, it is often said. But keeping people stupid is your
> biggest security hole!

Step 1: Open a terminal

Step 2: Run this command: ssh-keygen -f ~/.ssh/my_key_<date> ...

Step 3: Submit (through whatever means appropriate to the environment)
the contents of ~/.ssh/my_key_<date>.pub; do not ever, no matter what
anyone tells you, share the contents of ~/.ssh/my_key_<date>

Step 4: Update ~/.ssh/config to indicate IdentityFile ~/.ssh/my_key_<date>

It's not _that_ hard. I'm pretty sure pretty much anyone who can
meaningfully use SSH to start with can figure that out.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#268423

On 20/3/24 19:03, Michael Kjörling wrote:
> On 20 Mar 2024 15:46 +0800, fromjeremy.ardley@gmail.com  (jeremy ardley):
>> Regarding certificates, I issue VPN certificates to be installed on each
>> remote device. I don't use public key.
> What exactly is this "certificate" that you speak of? In typical
> usage, it means a public key plus some surrounding metadata, but you
> say that you "don't use public key".
Each client is issued with a private key unique to the access point. 
When I say I don't use public key I mean I don't use certificates issued 
from public key authorities such as comodo
>> For ssh use I issue secret keys to each user and maintain matching public
>> keys in LDAP servers.  SSHD servers can get the public keys in real time by
>> using the AuthorizedKeysCommand. If a secret key is compromised I simply
>> remove the matching public key.
>>
>> [users are locked out from uploading their public key using ssh-copy-id]
> So the private keys aren't private, thereby invalidating a lot of
> assumptions inherent in public key cryptography.
>
> Also, are you saying that you do not let users rotate their keys
> themselves; and if so, why on Earth not?


Private keys aren't private in any corporate network. Security 
management would be impossible to manage if users could generate their 
own keys and install them on any server. For one thing users do not have 
any easy way to revoke certificates.

In any serious network, private keys are simply a name for a secret key 
issued by an administrator to a user. Matching public keys are often 
published and are maintained by the administrator. Both keys are owned 
by the administrators.

If you are in full control of your network and resources, sure, go ahead 
and rotate your keys. But if you are in a network run by others you have 
to accept their control of keys and access to resources.

[toc] | [prev] | [next] | [standalone]

#268424

On 20 Mar 2024 19:21 +0800, from jeremy.ardley@gmail.com (jeremy ardley):
>>> Regarding certificates, I issue VPN certificates to be installed on each
>>> remote device. I don't use public key.
>> 
>> What exactly is this "certificate" that you speak of? In typical
>> usage, it means a public key plus some surrounding metadata, but you
>> say that you "don't use public key".
> 
> Each client is issued with a private key unique to the access point. When I
> say I don't use public key I mean I don't use certificates issued from
> public key authorities such as comodo

Ah, so when you say "public key", what you mean is "certificate issued
by a widely trusted X.509 PKI certificate authority" (a large chunk of
which is often abbreviated as CA). Not the cryptographic concept of
the public portion of an asymmetric key pair. Gotcha. Though now I'm
instead uncertain what you mean by "access point"; somehow I don't
think you're referring to IEEE 802.11 variants APs, although of course
certificate-based authentication _can_ be used with those.

By the way, no sane public CA these days should issue your keys _for_
you, and no customer should accept a process that involves the CA
doing so. The process of acquiring a signed certificate starts with
preparing and presenting a CSR which includes the public portion of a
key pair generated locally (for some definition of locally); this
ensures that it is at least _possible_ that only the party preparing
the CSR has knowledge of the corresponding private key. Breaches
notwithstanding, obviously, but that's an issue in any scheme.
Certainly no reasonable CA should _want_ the risk of ever handling the
corresponding private keys.


> Private keys aren't private in any corporate network. Security management
> would be impossible to manage if users could generate their own keys and
> install them on any server. For one thing users do not have any easy way to
> revoke certificates.

"Run this command, send me this file."

Depending on the setup, that can of course also be automated. It is
even possible to provision a provisional key pair, triggering a forced
key rotation upon login if that key is used (or if a flag is set in
the user database); and if you only allow _one_ key at any one time,
that this key is generated under the user's control should not present
any significant difficulties.

Also, I suspect that you use the term "certificate" here in a
different sense than elsewhere, because aside from the issues
surrounding PKI certificate revocations (as opposed to rotation) in
practice, private-CA certificates face similar issues which revocation
is supposed to help mitigate.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#268426

jeremy ardley wrote: 
> 
> On 20/3/24 19:03, Michael Kjörling wrote:
> > On 20 Mar 2024 15:46 +0800, fromjeremy.ardley@gmail.com  (jeremy ardley):
> > > [users are locked out from uploading their public key using ssh-copy-id]
> > So the private keys aren't private, thereby invalidating a lot of
> > assumptions inherent in public key cryptography.
> > 
> > Also, are you saying that you do not let users rotate their keys
> > themselves; and if so, why on Earth not?
> 
> 
> Private keys aren't private in any corporate network. Security management
> would be impossible to manage if users could generate their own keys and
> install them on any server. For one thing users do not have any easy way to
> revoke certificates.

No. Users create public/private keypairs, keep the private one
private and send you the public side to install on servers. A
user can revoke their own access by deleting the private one;
a sysadmin can revoke a user's access by deleting the public one
from each host that it's installed on.

For ssh, the sysadmin can also add/remove users from the
AllowUsers list in the sshd config, or add them to the DenyUsers
list, or remove their membership in an AllowGroups list.

Proponents of certificates are going to say "but this is harder
than adding their cert to the CRL", which is nominally true but
in practice, you most likely already have a distribution mechanism
for maintaining system configuration everywhere.

> In any serious network, private keys are simply a name for a secret key
> issued by an administrator to a user. Matching public keys are often
> published and are maintained by the administrator. Both keys are owned by
> the administrators.

This is incorrect, as Michael and others have stated.
 
> If you are in full control of your network and resources, sure, go ahead and
> rotate your keys. But if you are in a network run by others you have to
> accept their control of keys and access to resources.

No, you have to accept their control of access to their resources.

-dsr-

[toc] | [prev] | [next] | [standalone]

#268428

On Wed, Mar 20, 2024 at 7:03 AM Michael Kjörling <2695bd53d63c@ewoof.net> wrote:
>
> On 20 Mar 2024 15:46 +0800, from jeremy.ardley@gmail.com (jeremy ardley):
> > Regarding certificates, I issue VPN certificates to be installed on each
> > remote device. I don't use public key.
>
> What exactly is this "certificate" that you speak of? In typical
> usage, it means a public key plus some surrounding metadata, but you
> say that you "don't use public key".
>
>
> > For ssh use I issue secret keys to each user and maintain matching public
> > keys in LDAP servers.  SSHD servers can get the public keys in real time by
> > using the AuthorizedKeysCommand. If a secret key is compromised I simply
> > remove the matching public key.
> >
> > [users are locked out from uploading their public key using ssh-copy-id]
>
> So the private keys aren't private, thereby invalidating a lot of
> assumptions inherent in public key cryptography.
>
> Also, are you saying that you do not let users rotate their keys
> themselves; and if so, why on Earth not?

Key continuity has turned out to be a better security property than
key rotation. It is wise to avoid gratuitous rotation schemes.

Jeff

[toc] | [prev] | [next] | [standalone]

#268429

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 20, 2024 at 09:23:58AM -0400, Jeffrey Walton wrote:

[...]

> > Also, are you saying that you do not let users rotate their keys
> > themselves; and if so, why on Earth not?
> 
> Key continuity has turned out to be a better security property than
> key rotation. It is wise to avoid gratuitous rotation schemes.

I will be the last ne to advocate any gratuitous rotation scheme (key
or password or anything).

My point is giving users enough wits and power (and competent help) to
make good decisions and to implement them.

If my laptop gets stolen, I'll definitely generate new keys.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#268397

Am Tue, 19 Mar 2024 17:42:55 +0300
schrieb Jan Krapivin <daydreamer199005@gmail.com>:

> The thing is my password is very easy now

The simplest thin is to change that now.

, and i haven't thought about *"automated connection attempts"*,
> that sounds rather... scary?

Those attempts happen if a server software (like SSH, Telnet, rlogin)
is running on you machine and reachable from the Internet.
The IPv4 address range can be iterated easily (only 4 billion
addresses) and the ports too.

> My password is easy because i am not afraid of direct physical access
> to the computer.

As long as it isn't connected to a network or running any services
reachable from the outside, there is no danger.

I recommend choosing a good password anyway because if you intent to
have remote access in the future, you might forget to choose long
passwords for ALL users.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web