What you should know about SSH

Michael W. Lucas pub­lished his new book “SSH Mas­tery” (no link to an online store, get it from your pre­ferred online or offline one in your part of the world).

Do you think you know a lot about SSH? I thought I did when Michael searched tech­ni­cal proof-readers for this book. I offered to have a look at his work in progress and he gen­tly accept­ed (while I do not get mon­ey for this, I am one of the per­sons he thanks for  the tech­ni­cal review in the begin­ning, so I am involved some­how and as such you should take the fol­low­ing with a grain of salt).

I already had user restric­tions in place before the review, but now I nar­rowed down some restric­tions based upon some con­di­tion­als. I already used SSH tun­nels for var­i­ous things before (where legal­ly applic­a­ble), but I learned some addi­tion­al VPN tech­niques with SSH. I already used mul­ti­ple ssh-keys for var­i­ous things, but Michael pro­vides some inter­est­ing ways of han­dling a large-volume of ssh-keys over mul­ti­ple machines. … I real­ly hope that my review was as valu­able for Michael, as it was for me to do the review.

He ends the book with “You now know more about SSH, OpenSSH and Put­ty than the vast major­i­ty of IT pro­fes­sion­als! Con­grat­u­la­tions”, and this is true, and all that in his writ­ing style where you can come with a prob­lem, read about it, and leave with a solu­tion (nor­mal­ly with a lit­tle bit of enter­tain­ment in between).

I know a lot of peo­ple which work dai­ly with SSH, and they know only a small part of what is pre­sent­ed in this book. In my opin­ion this book is a must-have for every System/Database/Application/Whatever Admin­is­tra­tor in charge of some­thing on an UNIX-like sys­tem, and even “nor­mal users” of SSH (no mat­ter if they use PuT­TY, or a ssh com­mand line pro­gram on an UNIX-like sys­tem (most prob­a­bly it will be OpenSSH or a clone of it)) will get some help­ful infor­ma­tion from this book.

I can only rec­om­mend it.

Sta­t­ic DTrace probes for the lin­ux­u­la­tor updated

I got a lit­tle bit of time to update my 3 year old work of adding sta­t­ic DTrace probes to the linuxulator.

The changes are not in HEAD, but in my linuxulator-dtrace branch. The revi­sion to have a look at is r230910. Includ­ed are some DTrace scripts:

  • script to check inter­nal locks
  • script to trace futexes
  • script to gen­er­ate stats for DTracified lin­ux­u­la­tor parts
  • script to check for errors: 
    • emu­la­tion errors (unsup­port­ed stuff, unknown stuff, …)
    • ker­nel errors (resource shortage, …)
    • pro­gram­ming errors (errors which can hap­pen if some­one made a mis­take, but should not happen)

The programming-error checks give hints about user­land pro­gram­ming errors respec­tive­ly a hint about the rea­son of error return val­ues due to resource short­age or maybe a wrong com­bi­na­tion of para­me­ters. An exam­ple error mes­sage for this case is “Appli­ca­tion %s issued a sysctl which failed the length restrictions.\nThe length passed is %d, the min length sup­port­ed is 1 and the max length sup­port­ed is %d.\n”.

The stats-script (tai­lored spe­cial­ly to the lin­ux­u­la­tor, but this can eas­i­ly be extend­ed to the rest of the ker­nel) can report about:

  • num­ber of calls to a ker­nel func­tion per exe­cutable bina­ry (not per PID!): allows to see where an opti­miza­tion would be ben­e­fi­cial for a giv­en application
  • graph of CPU time spend in ker­nel func­tions per exe­cutable bina­ry: togeth­er with the num­ber of calls to this func­tion this allows to deter­mine if a ker­nel opti­miza­tion would be ben­e­fi­cial / is pos­si­ble for a giv­en application
  • graph of longest run­ning (CPU-time!) ker­nel func­tion in total
  • tim­ing sta­tis­tics for the emul_lock
  • graph of longest held (CPU-time!) locks

Unfor­tu­nate­ly this can not be com­mit­ted to HEAD as-is. The DTrace SDT provider can not han­dle probes which are added to the ker­nel after the SDT provider is already loaded. This means that you either have to com­pile the lin­ux­u­la­tor sta­t­i­cal­ly into the ker­nel, or you have to load the SDT ker­nel mod­ule after the lin­ux­u­la­tor mod­ule is loaded. If you do not respect this, you get a ker­nel pan­ic on first access of one of the providers in the lin­ux­u­la­tor (AFAIR this includes list­ing the probes avail­able in the kernel).