Debugging SSH on Mac OS X

As a developer SSH is something I have to think about maybe once every few months when I’m setting up a connection for someone pairing in tmux for example. Cutting and pasting public keys can cost real time when a line feed gets inserted inadvertently or something gets clipped.

So assuming ssh isn’t working and you can’t connect it turns out there’s a pretty helpful debug mode on the client and the server. For the client you simply add the -v mode and get a pretty good idea about what’s going on:

ssh -v tmux@10.0.1.4 -i ~/.ssh/tmux_ssh

If that isn’t enough then you can just launch another ssh service on another port in debug mode.

sudo /usr/sbin/sshd -d -p 4444

Then you can just connect your client to the debugging server with a port specification:

ssh -v -p 4444 tmux@10.0.1.4 -i ~/.ssh/tmux_ssh

From that you should be able to get enough information to quickly debug the problem.

(My first experience with SSH was way back in 2000 when our 16 year old Unix sysadmin switched all the developers to SSH from raw telnet overnight because he could. All of us were on Windows or Classic Mac OS back then without any default SSH client software, and it cost us at least a day of pain to get everyone back to work.)

Agile Security as a Competitive Advantage

During a short conversation with our new Chief Security Officer he explained:

If we can certify that we have a secure software development life-cycle we stand to increase our overall revenue with clients from 10-20%.

Wow, actually utilizing our methodology as a competitive advantage. Typically if I mention methodology to anyone on the business side and many on the IT side they sort of shake their head no, never heard of XP or RUP. Indirectly it has a big impact on our ability to deliver and maintain applications, but it’s far from a direct revenue generator.

Over the next year we’ll be looking at adopting some practices, getting some training, and further integrating our QA and development teams. Many of the Agile practices we’re adopting parallel with established practices for improving application security. Thus unit, integration, and acceptance tests and their automation mean you can actually certify that you’re software is reasonably secure at least for what you’re testing for. Automated builds and code reviews mean no issues lay undiscovered for long. This also means QA will probably have to get involved at the coding and scripting level rather than their current pure UI testing and automated scripting against that UI.

Scrum and its 30 day Sprints allow us to inspect and adapt quickly instead of approaching security as an after thought that we find out when a security firm busts and application with a penetration test. And adding things like abuse use cases to our requirements make it clear how we can verify we’re ‘done-done’ with some particular feature.

If you take a non-paranoid approach to implementing better security you can actually stand up at a company meeting and explain how your software process improvement project delivered 100 million for the company. Not bad.