Re: ssh confusion

Thank you, thank you, Anthony.  As I say, you are a mensch!

I have just now added 'PasswordAuthentication no' to 
/etc/ssh/sshd_config on all three machines and suspect I may have reason 
to figure out and look at /var/log/authlog with some care very soon.

This evening when I first knowingly installed openssh-server on the 
Kubuntu machine and sshed in from the Debian machine it mentioned that 
my last login was April 15 (I believe) and I was a little taken aback at 
that as I don't quite recall having any server installed at that time 
except possibly (now that I think about it) I may have fiddled with one 
on an MX or antiX USB that I tested on that machine.

Now I suppose I should try to figure out exactly how the ip address 
would have shown across the USB operating systems and the Ubuntu Server VM.

Not to mention that I most certainly intend to heed the rest of your 
good advice below.  I've heard it from you before in a different venue 
but did not at the time have sufficient conceptual or experiential 
infrastructure in place to fully grasp it.

Tom

On 6/16/19 9:40 PM, Anthony J. Bentley wrote:
> Akkana Peck writes:
>> Many tutorials will include a section on how to set up keys so you
>> can ssh without a password. While that's certainly useful, I'd
>> recommend skipping that part for now, until you're more comfortable
>> with the basics of ssh with a password.
> Using ssh keys and disabling passwords is the number one most important
> configuration to enable on any ssh server.
>
> This is the number of attempts by bots yesterday to break into my home
> PC via ssh. Not a server with a public domain name, but my desktop
> computer sitting in my apartment:
>
> # grep 'Jun 15' /var/log/authlog | grep sshd | wc -l
>     76010
>
> That is approaching a hundred thousand attempts PER DAY. On a server not
> linked on any website or indexed by any search engine. I wouldn't trust
> a password to that, even my own reasonably well chosen ones.
>
> Back when I was an undergrad, I took a cybersecurity class in UNM's
> CS department. One kid ran a public ssh server for an assignment. A bot
> guessed his password. When the professor found out, he imaged the disk,
> and the next class assignment was to study the hard drive to figure out
> what the bots do once they succeed in breaking in.
>
> So what is it they do? First they silently replace passworded tools
> (sudo, ssh, and the like) with trojaned versions that log all passwords
> of all sites you log into. Then they set up bruteforcers and start using
> YOUR machine to attack more servers. And then they cover their tracks.
>
> I don't mean to scare people, but running an ssh server without
> disabling passwords is incredibly unsafe, both for oneself and for
> everyone else on the internet. Doesn't matter how good your passwords
> are--the risk of a compromised machine is too great.
>
> Disabling passwords is easy: in /etc/ssh/sshd_config, add the following
> line:
>
> PasswordAuthentication no
>
> Then restart the server (or restart the machine).
>
> Using keys is easy too. It is only two steps.
>
> Step one: on the client machine (the one you "ssh" *from*), run:
>
> $ ssh-keygen
>
> It will ask where to save it (default of ~/.ssh/id_rsa is fine), and ask
> for a passphrase to use (blank/no passphrase is perfectly fine).
>
> (Personally I run "ssh-keygen -t ed25519 -c 'my comment goes here'" but
> running just "ssh-keygen" is fine too.)
>
> Step two: copy the public key (it ends in ".pub", like ~/.ssh/id_rsa.pub)
> to the destination machine (the one you ssh *to*), at:
>
>    ~/.ssh/authorized_keys
>
> Now you can ssh from the one machine to the other, with passwords
> disabled. You won't even have to enter a password (very convenient),
> yet it is vastly more secure than a password-enabled configuration.
>
_______________________________________________
nmglug mailing list
[email protected]
http://lists.nmglug.org/listinfo.cgi/nmglug-nmglug.org