On Friday, 20-12-2024 at 20:21 Chris Green wrote:
> to...@tuxteam.de wrote:
> > [-- text/plain, encoding quoted-printable, charset: utf-8, 24 lines --]
> >
> > On Fri, Dec 20, 2024 at 10:22:29AM +0700, Max Nikulin wrote:
> > > On 19/12/2024 15:56, Chris Green wrote:
> > > > Horses for courses, I enter login passwords/passphrases quite
> > > > frequently (lots of
> > > > different systems that I ssh to) long, unmemorable, passwords would be
> > > > useless.
> > >
> > > Generate a private key and add its public counterpart to
> > > ~/.ssh/authorized_keys on remote machines. Locally running ssh-agent
> > > allows
> > > to authenticate on remote machines without typing the pass phrase for the
> > > private key for each connection. It is more secure than passwords against
> > > brute force attacks.
> >
> > Definitely. I was thinking specifically about passwords: what they are, how
> > they work. But it's clear that (asymmetric) crypto keys are worlds ahead
> > of passwords in terms of security, convenience (agent forwarding, anyone?)
> > LDAP integration and all of that. Whenever I have the choice, a SSH key it
> > is.
> >
> WHY????
>
> It depends very much on the way your connection might get attacked. A
> key based ssh connection is (as you say) much more secure against
> attacks directly on the remote server, but only if that remote server
> has password login disabled. Your key based login is quite irrelevant
> if there's actually a password that the intruder can guess.
>
> At the local end using a passphrase protected ssh key is no better
> than a password, both depend entirely on how easy the password or
> passphrase can be guessed. In fact my feeling is that password is
> slightly better because if you are using ssh-agent as you may well
> leave your system for short periods without logging off and then an
> intruder will be able to log in to all those remote systems for which
> ssh-agent has saved your key(s). (Physical security again!) This last
> is why I have my ssh-agent set to expire keys after a few minutes.
"nothing is secure"
Security is an interesting topic.
People have attempted to make things secure for many years.
When security is mentioned, I first think of wax seals on envelopes and
physical locks and keys. I wonder if the younger generations do?
1) When thinking about security, I like to remind myself that "nothing is
secure", and all I can do is make it "more difficult for others to gain
unapproved access". There is always a way to break through a security measure.
Hence 'access attempt' mitigation, monitoring and logging are useful in
security plans.
2) I also like to remind myself and others, "If I can access it via the
Internet, then so can anyone in the world who has access to the Internet".
Staring questions: Does it really needed to be connected to the Internet? Is
remote access truly required?
3) Applying Security makes access less convenient. The greater the security,
usually the less convenient my access becomes. Hence weak passwords are less
secure than complex, long passwords, ssh keys with passwords are less
convenient than ssh keys without passwords, stored passwords are convenient but
give others another option to gain access to your password. How much
inconvenience are you able to accept? (it is a good question)
4) Understanding what methods can be used to gain access to your system, and
how to bypass whatever security systems you choose to implement, is important
when choosing a security method.
5) Finding what methods, level, etc of security you are happy to accept and
what level of risk you are willing to accept is the first step in making a
security plan.
6) Keeping security patches up to date reduces ways people can inappropriate
access your systems. But only reduces, never be lulled into thinking you are
secure.
(please let me know if there is a simpler or more correct way to phrase this
info, I like improving my knowledge. And there has to be more to security than
the above).
Below is a link to an interesting list of suggestions. Somewhat inconvenient if
one were to implement all suggestions.
https://tailscale.com/learn/ssh-security-best-practices-protecting-your-remote-access-infrastructure
George.
>
> --
> Chris Green
> ·
>
>