- I read a great article.
- I have a look at the rest of the blog, seeing more interesting articles.
- I see that the posting frequency is low. [1]
- I want to add it to my QuiteRSS reader, but there is no Atom/RSS feed.
[1] Which is actually a very good sign! Daily posters are inevitably posting mostly crap, and I'm too tired of such blogs to pick out the cherries. I prefer authors who publish only their cherries in the first place, or at least provide a "cherry-only" feed.Interestingly, the author still worked a lot with the docs (RFCs), not just with the software itself.
I believe this is important for any hands-on activity. Even though the documentation isn't your starting point, and may be too cumbersome and badly structured, sooner or later you should go back to them, now with more specific questions, picking out what you need.
https://github.com/tetrakai/miscellaneous/tree/master/ssh_cl...
Unfortunately, that was somewhat hidden in a small "here" link near the end of the article.
By the way, I believe to would be preferable to have a separate Git repository for that, rather than putting all mini projects ("miscellaneous code snippets") into a single repository.
This is unpopular, but you could implement port knocking.
Now the rest of the world doesn't even see your sshd - on any port. I love the idea and have implemented it everywhere that it's practical.
After installation, simply type:
$ sudo apt-get -y install sshguard
And then edit the whitelist to include your local IP if you want;
$ sudo vim /etc/sshguard/whitelist $ sudo service sshguard restart
Next blog post idea: taking apart how zlib works (https://tools.ietf.org/html/rfc1950) and using that as a built-in compression algorithm. Seriously though great article.
What first revealed me the hidden complexity of SSH was typing this during a live SSH session:
~?
Which show you the SSH supported escape sequences.Telnet had something similar.
ssh server can be run with -d option for monitoring. It redirects debug messages to stdout.
/usr/sbin/sshd -d
* Picking some RFCs and then writing a client/server is fun as a coding exercise.
* I had a go at implementing POP3 and HTTP years ago in a MUD / LPC, but HTTP has been done to death now.
* Documentation is also really really good and I like the self-describing code, but have you thought about adding any unit tests i.e. for the algorithms?
Edit: Finished reading, what a great project! I've looked for something like this before, but ssh documentation never quite contained what I was looking for, let alone providing a simple client to hack with.
Many code snippets look a lot easier than I would expect it to be (e.g. DH KEX looks very simple there), though of course finding out what the correct code is, even if it's brief, takes a lot of effort.
Great writeup and thanks for sharing!
You might be crushing whites, or just have incorrect gamma.
It's very difficult to tell, though. The gamma varies between 1.9 and 2.3 (roughly) depending on the angle at which I look at my screen. Every time I sit this will be different.
Opening the article again, it also depends where I look: when tilting my laptop back a bit, the text appears darker (even black if I tilt it far enough) but the exact shade differs: near the bottom of the page it's still greyish while the top part is indeed almost black.
Looking on my phone, it's a lot better readable than on my laptop, probably because I look at my laptop screen at an angle and my phone's colors don't change if you look from the far top or bottom.
If you have something like the Nvidia Linux control panel for adjusting colors, lowering the white level and raising the black level can help compensate a bit. The open source Media Player Classic (or MPC-HC maybe) player also has a nice shader to correct for the vertical variation, but I don't know of any way to apply it to the whole OS.
P.S. Loved the article!