SSH for Fun and Profit
karla.ioI really enjoyed reading this, you should add an rss feed to your blog, I couldn't find anything to subscribe to.
Thanks! I'll try to add one later this week, I've been meaning to :)
That would be really great! It's always a pity when this happens:
[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.- 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.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.
Yeah, I would hope with a tool as critical as ssh the docs would be pretty good. Hopefully the author will contribute and it will get accepted.
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.
The actual code on GitHub:
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.
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.
Sslh would give you this ability, if you're prepared to shim an extra program infront of your daemon; http://www.rutschle.net/tech/sslh.shtml
"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.
sshguard is amazing, I routinely install it on any new servers. It comes with the standard Debian and derivatives' repositories.
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
How does sshguard compare to fail2ban?
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."
>“none” as my compression algorithm.
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.
Nice.
What first revealed me the hidden complexity of SSH was typing this during a live SSH session:
~?
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).
Telnet had something similar.
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.
/usr/sbin/sshd -d
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?
Author never did say whether the Logjam vulnerability was present.
Did you read the link she provided? https://weakdh.org
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.
InfoSec folks dont make vulnerability data public usually..
But where's the "profit" part?
Hireability
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.
Great writeup and thanks for sharing!
Check your monitor gamma and white level using something like this: http://www.lagom.nl/lcd-test/gamma_calibration.php
You might be crushing whites, or just have incorrect gamma.
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).
P.S. Loved the article!
You know about "reader mode", right? http://www.howtogeek.com/228104/how-to-make-the-mobile-web-m...
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.
It's weird to me that people want millions of random people controlling how content is visually presented; aka, wish the web would die already.
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".