[ Did you miss ssh writeup Part I? We discuss how default Linux OS hostnames sometimes give away the default password, pitfalls in numerical passwords.

First we identified the OS by default hostname, then we used a "most common numerical pin number wordlist" to crack the default SSH password in seconds, demonstrating how successful ssh cracking (using Hydra) looks, and offering solutions/advice HERE) ]


INTRODUCTION

Do you accept "new" ssh client key fingerprint prompts without checking them against the server in question's own key fingerprint?

If you accept ssh key fingerprints (without verification), you may be setting yourself up to be an unwitting victim of a MITM (Man In The Middle Attack).

[This topic is covered in PART II (scroll down for Tutorial]

Additionally in PART II, we swap out weak default password authentication, to a much stronger (passwordless) RSA key authentication login assisted by ssh-keygen (we use to generate strong keys).

After which, we disable the password login option altogether (to prevent brute force attackers), and finally, we restart SSH for all changes to take effect.

As a Bonus, a video covers converting SSH server to a Tor Hidden .onion service, adding additional security/encryption benefits (without need for open ports).


(REFRESHER) PART I:

Part I video is below, covering weak default password examples in real Pinephone operating systems (applying to all Linux / UNIX machines / default logins).

In this scenario, we first scan machines on the LAN (as an attacker would), immediately identifying operating systems by their default hostname. After which we use Hydra (brute force cracker) to run known default username/pin number lists against the SSH server identified OS of our Pinephone.

After demonstrating how easy it can be to identify and crack SSH logins on machines sharing the same connection/LAN, we then go in to tighten up sshd_config settings to prevent future brute force attacks. As well as talk password security.

This video is below:

https://youtu.be/GAvGKlvKouY


TUTORIAL (WITH SCREENSHOTS/VIDEO)

PART II:

https://youtu.be/CZ8BjLjl7EA

Today's Video continues on from this SSHD Config angle.

As the introductory paragraph details, first we check key fingerprints shown by our ssh client against the server side's ssh key fingerprint. We must ensure these fingerprints match, otherwise we risk MITM attack. Never accept new fingerprints without verifying.


ADD SSH KEY AUTHENTICATION (NO PASSWORD NEEDED)

(ssh more securely)

Have you ever accepted a fingerprint and wished to start over to be sure?
(to: delete all saved keys for host / server and reconfirm fingerprint?)

Did you know if you accept a fingerprint (answering 'yes' to unrecognized fingerprints), you will from that point on no longer be warned about that fingerprint?

What about if you accepted this by mistake?

SOLUTIONS:

REMOVE PREVIOUS KEY FINGERPRINTS (CLIENTSIDE):

ssh-keygen -R HostHere


CHECKING FINGERPRINT (SERVERSIDE):

ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub

NOTE: THE ABOVE COMMAND IS ECDSA. LATEST AND GREATEST ADVICE IS FOR ED25519. CHECK THIS:

ssh-keygen -lf /etc/ssh/ssh_host_25519_key.pub


NEXT:

Connect (from clientside) to our SSH server to check the fingerprint output. Does it match the above "CHECKING FINGER (SERVERSIDE)" output?

See the screenshot below to watch this comparison in action.

SCREENSHOT CHECKING FINGERPRINT (COMMANDS ABOVE):

IMPORTANT: I felt the need to explain 01:56 -- do not accept the key (unless you previously recognize it). This key fingerprint acceptance is to demonstrate the plain 'password: ' prompt itself (fingerprint acceptance required to show). Follow below for fingerprint checking instruction (or follow video after 3min).


TIP #1 FINGERPRINT CHECKING:
Check the server's fingerprint from a separate network (if working remotely from it), or if you have physical access + a monitor, even better. By using a separate network to check the fingerprint upon connection, you are compartmentalizing both client checks from one another, further verifying fingerprints match from multiple networks.

Running the fingerprint checking locally (serverside) is always the best method (when possible).


TIP #2 FINGERPRINT CHECKING:

write hosts/fingerprints down , post them on your wall/corkboard/office: no risk in having a written list of your machines hostname/ip + correct ssh fingerprints. This can save you from having to check.

Why? You may one day need to login from a new machine without physical access to the server. Having record can help you check without risking the login/accepting fingerprints remotely.


After working on fingerprint checks, we add the key to our server, allowing our client machine to automatically login upon connection.


GENERATE RSA KEY PAIR

ssh-keygen -t rsa -b 4096


PASSWORD-FREE KEY AUTH: MORE SECURE SSH ACCESS

COPY KEY TO SERVER:

ssh-copy-id [email protected]

SEE SCREENSHOT BELOW FOR ABOVE STEPS IN ACTION


After successfully copying our key, we then connect by ssh to test it, if it lets us in without problem or password, we did it!

TESTING PASSWORD FREE KEY AUTHENTICATION


TIGHTEN UP SSHD_CONFIG (SERVERSIDE)

We add a few more lines to /etc/ssh/sshd_config, ensuring only our machine can login:
(disabling password guessing by relying on our newly minted key alone)

/etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Restarting SSH allows our configuration changes to take effect:

sudo systemctl restart ssh

[Timestamps are found inside the video description]


* BONUS: PART III: Tor SSH .Onion (Hidden Service):

This 3rd (optional) video shows how to setup SSH access as a Tor Hidden Service.

BENEFIT #1: By disabling ssh locally and allowing only the Tor ssh we prevent unknown machines from attempting brute force attacks (if we failed to follow previous videos). The only ssh attempts will be from those you give the onion address to.

BENEFIT #2: Additional layer of end to end encryption between the tor clients on ssh client and server side. Add to this the ssh encryption keys/fingerprints themselves on your client/software side, and you have a much more secure ssh setup.

https://youtu.be/syKZNMVxTM4

Comments/Questions Welcome below:


Like content/videos like this? Share it with friends/family who have interest in Linux and security.


Thank You to everyone who takes the time to Share and/or Support my videos. All my channels/pages are completely demonetized.


Thoughts, comments and any questions welcome below.

❀️ If you appreciate content like this and want to β˜• Buy Me a Coffee hit the support button on:
Home Page

Don't forget to follow links below.


(options for personalized 1 on 1 lessons/help in extras for those interested - or simply comment below (free and helps others) for answers to any answers to your questions on this tutorial)


----------------------------------------------------------------------
πŸ§…πŸ” ANONYMOUS GITEA (.onion): Books, Code/Scripts, Wiki, more (make a repository)
πŸ§…πŸ” PASTEBIN (.onion): anon pastebin pw protect, zk-256bit, "Burn After Reading" + more
----------------------------------------------------------------------
πŸ’– πŸ€— SUPPORT OPTIONS (If you like to)
🎁 EXTRAS: Get something unique for your Support here
πŸ€‘ πŸ’΅ CASHAPP: $HumanRightsTech
βœπŸ—’πŸŽž Politictech Membership (monthly coffee supporter option + extra access)
πŸ’³ Politictech Main Page: (info + lists current BTC/Crypto address)
----------------------------------------------------------------------
FOLLOW:
βœπŸ—’ MASTODON
🐦 TWITTER
πŸ“Ί 🎞 PEERTUBE
πŸ“Ί 🎞 BITCHUTE
πŸ“Ί 🎞 ODYSEE
πŸ“Ί 🎞 YOUTUBE
---------------------------------------------------------------------
βœ‰ CONTACT
-------------------------------------------------------------------------
THANK YOU for Sharing this, Liking, and Subscribing.
-------------------------------------------------------------------------
If you aren't registered for Odysee I'd love to see you over there.
Use my invite link: https://odysee.com/$invite/@RTP
--------------------------------------------------------------------------
Thank you for Sharing. I appreciate you.