chealion.ca

This is an update to my personal notes that made up my 2016 post: SSH Key Types and Cryptogpraphy: The Short Notes.

Things have changed in short 6+ years since this post. Namely DSA is long one, RSA is on well on its way out, and the two newer options in that post are now considered the minimum standard.

The too long, didn’t read version of this entire post is almost the same as what I said in 2016 - use ed25519 for your keys unless something explicitly does not support it.

OpenSSH Version References

From the notes I gathered to make the previous blog post - ed25519 was introduced in OpenSSH 6.5+

Ubuntu

macOS

Nova / Horizon (OpenStack)

Of note ed25519 support was removed prior to Ocata, and then restored with around version 19 (Stein / Apr 2019) of nova-api.

On nearly all current (< 3 years old) operating systems there are 4 different types of SSH key types available - both as a client’s key and the host key:

• DSA (No longer allowed by default in OpenSSH 7.0+)
• RSA
• ECDSA (OpenSSH 5.7+)
• ed25519 (OpenSSH 6.5+)

So which one to use?

In general, the best practice preference is to use ed25519 if possible, otherwise use RSA (4096 bits) due to mistrust of NIST’s curve for ECDSA. Which key is chosen/created is managed by HostKeyAlgorithms in sshd.conf, and when you create a client key by running ssh-keygen. So what about the other parts of an SSH connection, and can I use an ed25519 key anywhere?

The key types are just one portion of an SSH connection; authentication. SSH connections have three major cryptographic phases, the key exchange, the authentication, followed by the negotiated symmetric encryption used by the rest of the connection. (If you want more detail, check out Digital Ocean or Cisco’s explanations.)

Unlike the SSH key type, the ciphers and key exchange are decided on between sshd and ssh depending on their feature set and what is defined in their config files.

If you’re running OpenSSH 6.3 or newer you can see what algorithms are supported by running one of the three commands: ssh -Q [cipher|mac|kex], or read man ssh_config.

Key Exchange

A glossed over version of the key exchange, has the client and the server share some information (eg. public keys) and use the Diffie-Hellman algorithm with a decided curve to set up the cipher (symmetric key) and the MAC (message authentication code to confirm validity) to be used for the rest of the connection.

Mozilla’s recomended list of kex choices to use (specify in sshd_config) per their wiki is a great starting point. The summary being anything at least with a sha256 confirmation helps.

Encryption

The symmetric key created during the key exchange step is now used to encrypt and decrypt the rest of the connection.

Mozilla’s wiki again lists the most recommended ciphers and MACs with the new chacha20-poly1305 being the first on the list.

Key Type Reference

* - disabled by default for sshd
1 - PuTTY stable only supports dsa and rsa but the latest development snapshots support ecdsa and ed25519.

TL;DR

Unless you’re using CentOS 6 or Ubuntu 12.04, use ed25519 keys and Mozilla’s config files to limit the preferred connection ciphers.

Other Resource Links

http://www.openssh.com/legacy.html

In April I pushed to GitHub my RewraptoMP4 Script I put together to help assist in creating proper MPEG-4 container files while being able to use the x264 QuickTime component in Compressor. Compressor only allows you to specify the codec being used when exporting to a QuickTime file, however it is possible to use QuickTime Player after the fact to convert a QuickTime Movie to an MPEG-4 without transcoding so long as the codecs are supported in the MPEG-4 container spec.

My primary reason for the extra work is that Google Chrome will not recognize a .mov file as a valid wrapper for video in HTML 5’s <video> tags.

Using Compressor

You need to make your Compressor preset using x264 as a normal QuickTime movie preset (use the table below to help with settings if necessary). You’ll then want to grab the script from GitHub and add it as a script to your preset.

Scripting Compressor isn’t very straight forward, while you can use AppleScript or launch a script using Compressor they fail to mention that the script must be saved as an application and the file is accessed by using on open.

Helpful Table of Limitations

Android information is rather limited. Official Android information is near non-existent.

Thanks to:

• http://www.proactiveinteractive.com/software/compressor/index.php

There’s a particularly nasty implementation detail that doesn’t seem to come up often but is just waiting to bite just about every Mac user in the ass. Mail.app allows users to attach files inline allowing them to be part of the flow of the text or in the case of one of my users be right alongside the paragraph talking about the changes in that paragraph. Or like me, right below the email you’re sending and above the replied emails because of Mail.app’s defaulting to top posting. The issue isn’t being able to put attachments inline, but the fact that by default Mail.app will encode the attachment in the same spot in the email file causing other email clients to see the rest of the email as a set of attachments.

The fix: Make sure “Always Insert Attachments at End of Message” is checked off (preference key is AttachAtEnd - boolean for you MCX minded folk) and you can now attach inline as you would normally want to without having Outlook eat your message.

Thunderbird will display the text correctly, but you’ll lose it and it will only appear as an attachment once that email is forwarded or replied to: (Part 1.1.3 is the text “There’s an attachment”). You’ll also notice the horizontal rule separating between the different HTML portions of the email.

What program completely falls flat on it’s face is Outlook; it just puts all attachments off to the side and you have no idea what’s in the those ATT documents and your client sure as hell isn’t going to read them. So you’ve sent the email, the email was successfully sent, the text will be visible on their webmail systems, on their mobile device (Blackberry or iPhone), and even visible in other mail clients but because it’s technically an attachment Outlook won’t display it inline by default. (For the same reason they won’t show images by default in emails - the cookie tracking and that it’s a great attack vector)

Of note, this only occurs when sending from Mail.app. Outlook can attach items inline and have no issue as it attaches the images at the end of the email.

Correct view:

While doing some research I discovered (first with the 27" iMacs) and now with the new MacBook Pro line that runs the i5 or the i7 processors; Apple has slotted in an ethernet controller that does NOT support Jumbo Frames.

See page four of the PDF of the Broadcom 5764 Chipset

In order to profile some in house web application development and find out a couple bottlenecks that were appearing I went looking for a decent PHP profiler and found Xdebug. Because I am using the built in version of PHP on the Leopard Server, and a MacPorts version on Snow Leopard (we also have an application that fails miserably on PHP 5.3) it lead to some fun installing Xdebug on the Leopard machine since I didn’t want to reconfigure apache2 to use PHP 5.3 from MacPorts.

The crux of it is to grab the source of Xdebug, and then when configuring prefix your standard ./configure --enable-xdebug with the statement CFLAGS='-arch ppc64' or CFLAGS='-arch x86_64' as necessary. Compile xdebug as a 64-bit extension and it will actually work with a 64-bit version of Apache. With MacPorts it was as simple as enabling the xdebug variant and letting it recompile PHP.

I highly recommend using webgrind. It gave me more useful results than MacCallGrind, and didn’t require an hour hoping MacPorts could compile all the dependencies for kcachegrind (which would require graphviz as an additional install). Now I have some numbers to tell me where to look for proof old me is a moron.

As many of you are aware, Apple released a new horribly named mouse, the Magic Mouse. On Saturday I had the opportunity (since I was in the mall anyway) to drop by the Market Mall Apple Store and give the mouse a whirl - it was comfortable, did not have the gum-up-every-5-seconds trackball, and was exceptionally responsive. On a whim I ended up purchasing one later that day.

The Good

The mouse is accurate, responsive and the multitouch feels intuitive and that with software updates it could become even more. Additionally the weight has just enough heft to feel solid but much lighter than most other wireless mice Definitely the best Bluetooth mouse I’ve ever used.

Scrolling without a wheel (and momentum on Snow Leopard) brings the best of scrolling on an iPhone/iPod touch to the desktop and for the reason alone is worth it. Instead of a tiny wheel that just spins the entire surface of the mouse is now you touchpad for scrolling, perfect for reading long PDFs and being able to lean back and just use one finger without having to clutch a mouse.

Of note the two finger swipe to go back in Safari hasn’t been an issue and actually useful on occassion.

The Bad

The mouse is smallish and does not offer the ability for a “middle click” (3rd button). If you are used to the Mighty Mouse the muscle memory of squeezing may take a little while to get used to not being able to do. The loss of being able to trigger Exposé in any form is definitely a large loss and the primary reason I normally prefer 5 or 6 buttons on my mice. Being forced to use a less than optimum layout for Exposé on the Aluminum keyboard makes using Exposé more and more of an afterthought without resorting to Dock Exposé in Snow Leopard. Apple’s hardware definitely is not very Exposé friendly at times.

The Ugly

The new mouse is quite cramped and not all that comfortable compared to full size mice like Logitech’s MX Revolution, 1000 or the Performance. This is a huge misnomer because the Magic mouse is surprisingly comfortable even for long periods of time - it’s that the MX line fits my hand more completely and feels nicer to hold at odd angles. That said, I always have a hand on the keyboard and avoid mousing unncessarily as keyboard shortcuts are nearly always faster then hunting for them in the menus.

Conclusion

Suffice to say, it’s an excellent Bluetooth mouse, it’s minimalistic and has all the features I want. For users who don’t require a middle button, those who want a solid mouse it’s perfect. I’ll definitely be keeping it - at least until the wife steals it and I upgrade to an MX Performance.

I highly recommmend the mouse so long as you’re not looking for a large or gaming mouse.

My initial impressions are that Snow Leopard is very much worth the upgrade if you can afford the time to do an operating system upgrade (in this case for me it was ~1.5 hours: 45 minute install, 45 minutes testing apps and seeing they still worked without any modification)

Pros:

• Speed
  Awesome!
• New Services Feature
  My favourite feature
• OpenCL
  If you haven’t seen MacResearch’s Introduction to OpenCL check out 33:30 to 34:50 or so. (Rough timecodes
• iCal Event Editing Gets a Window Again
• Spotlight Default Search Location Fix and Sortable Results I can finally search within a folder without holding a needle to my eye first!
• Enhanced Icon View Neat if I used icon view.
• Faster wakeup to password screen Hawt.
• Faster Time Machine Backup Hawt.
• Airport Menu Changes Neat animation, but more info when holding the option key as well.
• Gamma 2.2 Default No longer do I have to set this up each time.
• New Fonts Menlo is cool, but Chalkduster; Heiti SC and TC; and Hiragino Sans GB are all fonts I’ll never use.
• Safari Plug-ins are sandboxed Awesome - Flash won’t hurt as much even after ClickToFlash
• QuickTime Player New UI is great for viewing.
• Preview Faster and better scaling.
• Mail Much faster. :-)
• Set a time before the screen saver asks for a password. THANK YOU.
• Smaller footprint I liked the good thwack of disk space I got back (~6GB)
• Grand Dispatch Can’t wait to see the results on the Mac Pros at work.
• Screen Recording Neat, but I’ll stick with ScreenFlow.
• Revised Keyboard Shortcut / Services Preference Pane Much nicer to work with.
• Wake on Demand No more having to worry about whether the computer is asleep or not? Over wireless? Sweet (Airport Extreme only though)

Cons:

• Base 10 Counting
  WTF. DO NOT LIKE. “Mac OS X can not count” Would prefer a preference to turn this off and/or proper suffixes (eg. MiB instead of MB)
• QuickTime Player Absolutely neutered into being useless beyond viewing and “Sharing” your movie to MobileMe.

In summary, there is no one real feature in Snow Leopard worth upgrading for - no major consumer focused feature. It’s the sum of all the parts that make it worth much more than the $29 they are charging. Once installed you never want to go back.

At my workplace we use iCal Server running on Mac OS X 10.5 Server to share several calendars all under our one staff group. With iCal, so long as the group is delegated to be shown on the user’s accounts you can see all the calendars but with Sunbird you only get to see the first calendar.

Before going further it’s worth noting how to delegate a group calendar so a user can view it without manually adding the group calendar as it’s own calendar (if using Delegates instead of multiple calendar “accounts” (same credentials, different calendars) is your aim). To do so you have to add the group calendar as a normal account in order to set it up, and then set up delegation as you would for a normal account. The important URL to know for using a group calendar is http://FQDN.OF.SERVER:8008/principals/groups/groupname (as always replace http with https and 8008 with 8443 if you are using SSL).

Sunbird uses slightly different URLs than what you use in iCal to start with, where in iCal an example URL might be http://FQDN.OF.SERVER:8008/principals/users/USERNAME or http://FQDN.OF.SERVER:8008/principals/groups/GROUPNAME. The corresponding URL to use in Sunbird is http://FQDN.OF.SERVER:8008/calendars/users/USERNAME/calendar or http://FQDN.OF.SERVER:8008/calendars/groups/GROUPNAME/calendar

That’s great for adding a single calendar but what if a user or a group has multiple calendars under their one account? iCal will automatically show them as a group whereas Sunbird requires you to add each and everyone that you wish to have show up.

You can specify a “sub-calendar” to subscribe to in Mozilla Sunbird by specifying the unique ID of that calendar instead in the form of the url http://FQDN.OF.SERVER:8008/calendars/__uids__/UID_OF_GROUP_OR_USER/UID_OF_SUB_CALENDAR (Newer versions of Lightning will take http://FQDN.OF.SERVER:8008/users/USERNAME/UID_OF_SUB_CALENDAR). Note the lack of calendar at the end of the URL. To determine the UIDs in question it’s easiest using iCal, if you click on a calendar and press Command-I (File -> Get Info) you can see part of the CalDAV URL at the bottom of the sheet that appears.

You will see calendars/__uids__/UNIQUE_ID/ONLY_PART_OF_THE_UNIQUE_ID because the label the text is placed into is not big enough to fit the URL. Because you can’t get the full URL from there it’s easiest to go to the iCal Server itself and navigate to /Library/CalendarServer/Documents/calendars/__uids__/ (you’ll need administrator privileges to view this). From there find the folder named the same as the UNIQUE_ID portion of the URL and open it to find a folder with the UNIQUE_ID of the “sub-calendar”. You can now put the URL together and use that in Sunbird to view that additional calendar.

Example URL of a sub-calendar in the group:
https://FQDN.OF.SERVER:8443/calendars/__uids__/FA26C8C6-5B78-4AB0-AE73-0E9576574EBB/F74174B7-380C-4630-9192-9025F4C691A2

EDIT:

Sub-calendars also work at https://FQDN.OF.SERVER:8443/calendars/users/USERNAME/UID_OF_SUBCALENDAR

Sources Used:

• MacOSXHints.com - Add group calendars to iCal Server
• Apple Support Discussions - Correct URLs for Sunbird
• Apple Support Discussions - iCal + Sunbird

On ServerFault someone was asked a question why .csv files were unable to be viewed in Quick Look. For some reason .csv files are not defined as plain text by the operating system which leads to odd conflicts between applications that can deal with .csv files that causes QuickLook to report that it can’t find a generator for the file and just show the icon.

The one way to force it to work is to roll your own, with a bit of help after reading the QuickLook Programming Reference it was rather simple to roll together a proof of concept QuickLook generator for .csv files.

It’s not pretty, it may break at any time (if only because it’s using a dynamic UTI since one is not defined anywhere, however .csv files have been using the UTI “dyn.age80g650” for quite a while - as far back as prior to 10.0) but it works and forces the .csv to display properly.

The code and a download of CSVQL is available on GitHub:

Source: http://github.com/Chealion/chealion/tree/master

Download: http://cloud.github.com/downloads/Chealion/chealion/CSVQL.zip

Check out Pascal’s comment for a much nicer looking version - actually puts the data into tables.