I like the color coded visualization! Makes it very easy to absorb the information.
It is worth noting though that there are numerous “edge cases” when parsing URLs and there is a lot of inconsistency between different parsers. There is this classic talk from Orange Tsai and here is my attempt at explaining the issue in simpler terms.
This is great. Some of this stuff I’ve known and crammed into the back of the cellar of my brain, and I learned some new stuff as well. The gold here is the difference between URI/URL/URN/URC.
Another technique I find useful: sometimes some device can’t connect to your server, while others can. I then like to start another sshd process on the server, on a different port, and stay attached to that in debug mode. For example
sshd -dDp 2222
then you can watch the debug output of the server, with that servers settings, while the “broken” device tries to connect, without having to stop your “main” sshd process.
The fun one that I’ve been bitten by is things like sshguard blocking my IP because of too many failed login attempts. This is particularly easy to trigger when you’re setting up a new device to connect to some service and you enter the wrong password too many times. Then you get the timeout thing, yet can connect from a different IP very easily.
The cyphers one is also fun because the most recent releases of OpenSSH disabled some insecure hashes, but some services still require them. I have a thing in my ~/.ssh/config explicitly reenabling ssh-rsa for a specific host because of this.
My ISP doesn’t even provide an IPv6 address. And in general, the availability of IPv6 accessible services is rather thin. I’d like to work more with IPv6, but some people seem to hate it.
About half of my nmap uses are “nmap -sP www.xxx.yyy.*” to search the local subnet. I’d love it if there were a shortcut that just says “search the local subnet”; any suggestions?
You’re welcome! I think the problem is, that ‘local network’ in not precise enough, and therefore not easy to implement. What is your ‘local network’ if you are connected to 2 networks? - I think in the end it is not worth the trouble, and if it is needed, just use variables. And just for the protocol: there might be an easier solution, but I haven’t found it.
Better, but that still searches a docker0 network at 172.17.0.1/16, which will still take a long time and not be very useful.
I’ll take your lead, though, changing the search for “scope global” to a search for “/8”. I probably don’t want to automatically search for anything broader, anyway.
Yeah, needs some fine tuning. Isn’t as easy as it sounds. Depending on the setup, you could work with the -iL flag to import networks from a file, and/ or --exclude certain subnets.
Is it just me, or should public key authentication and disabling password logins be near the the top of that list, rather than an “advanced topic” that will be covered in future?
If you have session-multiplexing configured in your ssh-client, this will still let you in, even if new logins would no longer work, as it’s re-using your existing session to spawn a new one.
To check this safely, either first disable session-multiplexing, or delete the session-multiplexing socket file, or login from a different system
But I agree, the first thing to do is only allow logins with public-keys, disable passwords, and mostly ignore the other recommendations, as they don’t add anything useful and mostly just add frustration and problems.
Flipper Zero has just arrived. Time to figure out what to do with it.
Me every time I buy a raspi because they’re cheap.
I like the color coded visualization! Makes it very easy to absorb the information.
It is worth noting though that there are numerous “edge cases” when parsing URLs and there is a lot of inconsistency between different parsers. There is this classic talk from Orange Tsai and here is my attempt at explaining the issue in simpler terms.
Glad you like it. Good point - I’ll look into it and might add a section. Thank you!
This is great. Some of this stuff I’ve known and crammed into the back of the cellar of my brain, and I learned some new stuff as well. The gold here is the difference between URI/URL/URN/URC.
Hey Jeremy, glad you liked it. Was fun to research.
Another technique I find useful: sometimes some device can’t connect to your server, while others can. I then like to start another
sshdprocess on the server, on a different port, and stay attached to that in debug mode. For examplesshd -dDp 2222then you can watch the debug output of the server, with that servers settings, while the “broken” device tries to connect, without having to stop your “main”
sshdprocess.The fun one that I’ve been bitten by is things like sshguard blocking my IP because of too many failed login attempts. This is particularly easy to trigger when you’re setting up a new device to connect to some service and you enter the wrong password too many times. Then you get the timeout thing, yet can connect from a different IP very easily.
The cyphers one is also fun because the most recent releases of OpenSSH disabled some insecure hashes, but some services still require them. I have a thing in my
~/.ssh/configexplicitly reenabling ssh-rsa for a specific host because of this.Awesome idea! - Going to add this method later. Thank you for sharing.
My ISP doesn’t even provide an IPv6 address. And in general, the availability of IPv6 accessible services is rather thin. I’d like to work more with IPv6, but some people seem to hate it.
About half of my nmap uses are “nmap -sP www.xxx.yyy.*” to search the local subnet. I’d love it if there were a shortcut that just says “search the local subnet”; any suggestions?
Interesting idea. Haven’t found a native way to do so, but you could create something with bash aliases or functions:
ip -o -f inet addr show | grep eth0 | awk '{print $4}' | xargs -I {} nmap -sP {}This would search the whole subnet of interface
eth0.Very cool! Thanks. (I still think an alias for “everything on the local network” would be useful…)
You’re welcome! I think the problem is, that ‘local network’ in not precise enough, and therefore not easy to implement. What is your ‘local network’ if you are connected to 2 networks? - I think in the end it is not worth the trouble, and if it is needed, just use variables. And just for the protocol: there might be an easier solution, but I haven’t found it.
I’d be OK with it being “all local networks that I’m on”, e.g. the equivalent of this:
But, that includes virtual interfaces (e.g. “127.0.0.1/8”) that could take just about forever to search and return false positives galore.
Try this one:
ip -o -f inet addr show | awk '/scope global/ {print $4}' | tr '\n' ' ' | xargs nmap -sPBetter, but that still searches a
docker0network at172.17.0.1/16, which will still take a long time and not be very useful.I’ll take your lead, though, changing the search for “scope global” to a search for “/8”. I probably don’t want to automatically search for anything broader, anyway.
Yeah, needs some fine tuning. Isn’t as easy as it sounds. Depending on the setup, you could work with the
-iLflag to import networks from a file, and/ or--excludecertain subnets.Hm, interesting development. Have to update my Gitea instance anyway, so I’ll use this opportunity to switch to Forgejo.
Author here: I’ve just created another post on how to use public key authentication
ssh - How to use public key authentication on Linux
Appreciate your feedback! Going to add some notes later.
Is it just me, or should public key authentication and disabling password logins be near the the top of that list, rather than an “advanced topic” that will be covered in future?
Author here. You are right. I figured it would be too much content to add it there, so I’ve created a separate blog post for it. You can find it here.
Thank you for your feedback!
definitely, and it’s not that difficult, you just have to check your keys work before turning off password logins…
Important trick:
This way if you mess up the changes you’re making in terminal 1, the other one is still there.
Also, SIGHUP sshd, or tell it to reload its config. Don’t stop it.
If you have session-multiplexing configured in your ssh-client, this will still let you in, even if new logins would no longer work, as it’s re-using your existing session to spawn a new one. To check this safely, either first disable session-multiplexing, or delete the session-multiplexing socket file, or login from a different system
But I agree, the first thing to do is only allow logins with public-keys, disable passwords, and mostly ignore the other recommendations, as they don’t add anything useful and mostly just add frustration and problems.