That would be really great! It's always a pity when this happens:
- 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.
There are several services out there that will create an RSS feed out of any web page. They do this by periodically scraping the page's contents for you. https://feedity.com/ is pretty good; there are others.
I really like stories like this where somebody was overly curious about something and instead of just reading about it, he takes it apart and puts it back together to gain the kind of knowledge you will never find in a book/blog post.
> takes it apart and puts it back together to gain the kind of knowledge you will never find in a book/blog post.
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.
I thought it was fairly discouraging that the docs weren't sufficient to get the author up and running with ssh; a lot of seemingly undocumented gotchas popped up.
Another way to help discover how SSH works is to compile your own openssh server, instrumenting it with your own printfs, and see exactly what it's doing. I did this at one point, and it helped immensely to write a (horrifyingly insecure) homegrown SSH client. It was at least a good learning experience.
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.
It's interesting that "The transport protocol doesn’t cover who sends their banner first". It'd be good if I could configure my server to keep quiet until the client identifies itself as an SSH client. I run it on an unusual port and it gets scanned frequently. sshguard helps but I'd prefer it wasn't announcing to any client that it is an ssh server.
"It'd be good if I could configure my server to keep quiet until the client identifies itself as an SSH client. I run it on an unusual port and it gets scanned frequently."
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.
I never used fail2ban: sshguard was simply what I came across first and it was easy to setup and worked as advertised. The Arch wiki states: "sshguard is different from the other two in that it is written in C, is lighter and simpler to use with fewer features while performing its core function equally well."
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.
Note that the actual sequence is 3 characters (newline, tilde, question mark). If you try ~? after anything except a newline, ssh won't intercept it (this is true for all ssh tilde escapes).
This is of course specifically how to reveal these features in the OpenSSH client. If you're using another client (e.g. PuTTY) there's a different way to get to these features (click the menu).
"This was a problem, because my initial packets to the server were met with immediate disconnects, and I’d now lost my main means of debugging. I banged my head against the wall for a while, then at the suggestion of a friend, decided to turn the server’s OpenSSH log verbosity way up. I bumped the LogLevel in /etc/ssh/sshd_config to DEBUG3, and suddenly I was getting helpful error messages!"
ssh server can be run with -d option for monitoring. It redirects debug messages to stdout.
I liked reading the code for this - added a Star too.
* 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?
No. I assumed since it was prominently mentioned in the opening of the piece, it would be addressed before the conclusion. Sort of the Chekov's Gun principle.
Meta: the grey text thing which seems to be really popular right now? That's just unreadable. Third time today I inspect-elemented a blog post to turn the text coloring off.
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.
Many users don't have expensive monitors, so they can't calibrate the monitor successfully. This is a problem when many web designers only test their site on a mac in a nicely lot office.
Thanks for the link! I've seen the site before but never thought of testing my screen when I got my new laptop.
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.
The worst color change I recall seeing on a laptop was the background color Google used to use to identify ads (a pale yellow as I recall). On cheaper laptop screens even the slightest tilt would make it white, making the ads indistinguishable from real results.
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.
If the author is reading this, I always find it useful to run HTML CodeSniffer [1] to find contrast accessibility violations. It gives you the closest colour that meets the contrast requirements. With a few small colour tweaks, I got the number of WCAG AA violations down from 115 errors to 17 (the remainder are primarily contrast issues with the code blocks).
It's very odd to have to depend on a browser feature that is basically for accessibility in order to read a website because the colour choices are bad.
You can cry creative freedom all you want, the colour choices make it hard for certain people (with visual difficulties) to read the site. Not accepting that and improving the design is basically saying "my creative freedom is more important than people actually reading the website".
I took it as a suggestion not to assume the author is a male so as not to embarrass yourself when it turns out they aren't, as a bare minimum of investigation would have revealed. Since when is basic politeness "gender politics"?
Not to presume which gender OP identifies with, but if you take a look at their GitHub profile, you'd probably come to the conclusion the the writer is not male.
Since the specific context matters to you, would you now suggest the parent of this thread then change the pronoun to "she" instead?
I've misread (english is not my native language) post with ", he takes it apart..." as a fact about author gender and reacted to subsequent comment which I find wrong.
Answering your question: would he, or me, or other poster know the gender of author while writting about author -> we should use proper form. If no prior knowledge is present: it does not matter to me, and I consider it not worth mentioning or correcting.
The inital comments were bad, but I found it even worse to see how many people engaged this, making that ugly thread larger and larger. It became so large that it finally displaced all the good, on-topic comments!
If you really want to show respect for the author, just downvote + flag the ugly comments, and be done with it. Then, go on and use your time to post something insightful about the author's article.
Alternatively, such threads could not be hidden completely, but only be reached via a separate link. That way, the discussion would still exist, but would not consume growing space on the original discussion site anymore.
(In addition, it would still serve to bind the people who insist on wasting their time in that corner. On the other hand, that would still be a pity. I assume that some people who wasted their time in that corner would otherwise have engaged in the remaining insightful discussions.)
