[ 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:
TUTORIAL (WITH SCREENSHOTS/VIDEO)
PART II:
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 username@host
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.
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
📺 🎞 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.