markwilson.it

Tag: Apple Mac OS X

  • Showing hidden files in Mac OS X

    I use hidden files (such as .htaccess) extensively on my website, so I needed to be sure that they were included with my local backup copy. Mac OS X doesn’t show hidden files by default (it all gets a bit messy otherwise – although they are visible in a Terminal shell); however I found a tip which details the commands to run in order to show hidden files in the Finder (this can be run using a standard user account):

    defaults write com.apple.finder AppleShowAllFiles TRUE
    killall Finder

    To return to the default display, run:

    defaults write com.apple.finder AppleShowAllFiles FALSE
    killall Finder

    I did find an application to display hidden files too but why bother if a couple of commands will do the trick? Even better, there is a workflow to show hidden files using Automator.

  • SSH addendum

    Since my recent posts about using SSH to securely remote administer Mac OS X, Linux and Windows computers, a couple of extra points have come up that are probably worth noting:

    • To use the console interactively, it may be better to use PuTTY (putty) than PuTTY Link (plink). In seems that PuTTY Link is fine for setting up a tunnel and then connecting using VNC, RDP or another remote control method but I found that control codes were echoed to the console window when I connected to a Linux of Windows computer and the command line experience was generally better using PuTTY interactively. This is because (quoting from the PuTTY documentation) “The output sent by the server will be written straight to your command prompt window, which will most likely not interpret terminal control codes in the way the server expects it to […] Interactive connections like this are not the main point of Plink”.
    • For another method of generating SSH keys, an online SSH key generator is available (I haven’t tried it myself).

  • Secure, remote administration of a Mac OS X computer from within Windows

    In a recent post about multimedia file format conversions, ripping DVDs, playback and more, I linked to a number of Mark Pilgrim’s “How To” articles; however there was one which wasn’t relevant to that particular post – how to use your Mac from anywhere (although it is intended for remote control of a Mac the advice should be equally applicable to a Linux system, or even to a Windows Server with an SSH server installed).

    A few months back, I blogged about using creating an SSL VPN to access my network but Mark’s video explains how to open a single firewall port and use SSH to provide a secure tunnel through which other protocols (in this case VNC) can be run for remote administration of a single computer. I tried it earlier and it’s very straightforward. Best of all, the software involved is all freely available under open source licensing agreements!

    I recommend downloading Mark Pilgrim’s video for a full explanation but the notes below explain what is involved (some of the Unix concepts may be unfamiliar to those more used to a graphical environment and my quick introduction to Linux for Windows administrators might be useful):

    1. Download and install the PuTTY, PuTTYgen, Pageant and Plink SSH utilities on a Windows PC.
    2. Using puttygen, generate a public/private key pair and protect it with a passphrase. Save the private key to a file on the Windows PC and copy the public key to the remote computer (e.g. within a text file transmitted via e-mail or FTP).
    3. On the Mac, open a terminal session (either using the OS X Terminal application or an alternative such as iTerm) and enter the following commands from the home (~) directory:
      • mkdir .ssh (this was already present on my machine as I already had the SSH server running).
      • chmod 700 .ssh (again, I didn’t need to do this).
      • chmod 600 publickeyfilename (the default permission set is 640).
      • mv publickeyfilename .ssh/authorized_keys
      • sudo nano /etc/sshd_config (non-admin users may need to su - to an admin account first as explained in my earlier post about running sudo as a standard user) and make the following edits:
        • Allow SSHtunnelling (also known as TCP forwarding or port forwarding) by changing #AllowTcpForwarding yes to AllowTcpForwarding yes
        • (Optionally) Prevent the use of usernames and passwords for login (the public/private key pair and passphrase will provide the security for the connection) by changing #PasswordAuthentication yes to PasswordAuthentication no
        • (OS X 10.4 only) Disable pluggable authentication modules by changing #UsePAM no to UsePAM no
      • Exit nano and save the changes to /etc/sshd_config (exit to the original shell if su was previously used to escalate privileges).
      • Generate an SSH key fingerprint (to prevent man-in-the-middle attacks) using ssh-keygen -l -f /etc/ssh_host_rsa_key.pub and make a note of the fingerprint.
    4. Open TCP port 22 on any firewalls/routers between the Windows and Macintosh computers and enable port forwarding to the appropriate internal IP address (it may be necessary to apply a static IP address to the Mac but I prefer to use a DHCP reservation).
    5. If the external IP address for the network is not static (mine is) then use a dynamic DNS service to assign a DNS name so that it may be located on the Internet.
    6. Within the OS X System Preferences, Open Sharing and enable Remote Login (restart the service if it is already running in order to pick up the changes made earlier to /etc/sshd_config). Because password authentication has been disabled, remote login (SSH) will only be possible from a machine with the appropriate private key.
    7. Although OS X includes Apple Remote Desktop, which is a VNC server, alternatives such as Vine Server (OSXvnc) offer additional functionality. In particular, VNC is insecure by default; however by selecting to only allow local connections (require SSH) and start the system server (i.e. run as a service, rather than in the context of a particular user), it is possible to run a secure VNC server each time the system is restarted.
    8. At this stage, it should be possible to create an SSH tunnel to the Mac. On the Windows PC, run pageant which is a PuTTY helper application (SSH agent) to cache the passphrase for the private key, which adds a level of security if the PC is compromised but which would also become a nuisance if it needed to be repetitively entered. Add a key using the private key file generated in step 2 and enter the passphrase that was used when created the key.
    9. Next, run putty and enter:
      • The hostname/ipaddress in the basic session options.
      • The auto-login username for the Macintosh for the connection data.
      • The privatekeyfilename for SSH authentication.
      • A new forwarded source port of 5900 and destination of localhost:5900 for SSH port forwarding.
    10. Save the session with an appropriate sessionname and open the connection. On the first connection, the host key will be unknown; however the reported key can be compared with the one generated earlier to ensure that the host is the intended target computer. Assuming that all is well and the connection is allowed to continue, then a Welcome to Darwin! greeting should be displayed, along with a shell prompt.
      • If the connection fails and there is a prompt for the private key then Pageant is not correctly configured.
      • If there is a prompt for a password then /etc/sshd_config was not correctly edited.
    11. Unless command line interaction with the Mac is required, the PuTTY window can be minimised. In order to create the SSH tunnel automatically at login, a startup shortcut can be created with the target of "%programfiles%\PuTTY\pageant.exe" privatekeyfilename -c "%programfiles%\PuTTY\plink.exe" sessionname
    12. Finally, a graphical connection may be initiated with a VNC viewer such as UltraVNC. The connection should be made to localhost; however because localhost:5900 has been defined as the forwarded port in the SSH tunnel, the request is securely transferred to the VNC server on the Mac.

    It’s worth noting that when I originally tried to test this configuration from a remote network I was unable to get past my employer’s firewall; however there are plenty of unsecured wireless networks around which I could use to test the connection!

    Note that the original information that provided inspiration for writing this post is licensed under a creative commons attribution sharealike 2.5 license and consequently so is the information contained in this post.

  • Running sudo as a standard user in Mac OS X

    Apple Mac OS X has its roots in a development of BSD Unix and as such the command line should be pretty familiar to most Unix sysadmins. It does have one significant security flaw though – the default privilege level for a user is admin (although, to be fair, that is not the same as root, which needs to be enabled manually if required). Such routine use of administrative privileges is a dangerous practice – one which many Mac users will be happy to criticise Windows for; however, unlike versions of Windows prior to Vista, it is perfectly easy to operate a Mac using the principle of least user privilege – indeed, I perform all of my Mac OS X activities as a standard user although I’m asked to authenticate using an admin account for certain activities (in a similar manner to Windows Vista user access control).

    Rather than enabling root access, OS X uses the sudo command to temporarily escalate privileges when required in a terminal shell (Linux Box Admin has an interesting article comparing sudo with root); however, by default, sudo will not work for a standard user – when I tried to run sudo command earlier today I got the following response:

    WARNING: Improper use of the sudo command could lead to data loss
    or the deletion of important system files. Please double-check your
    typing when using sudo. Type “man sudo” for more information.

    To proceed, enter your password, or type Ctrl-C to abort.

    Password:
    username is not in the sudoers file. This incident will be reported.

    I could edit /etc/sudoers (the guide at MDLog:/sysadmin gives a good introduction to sudo) but I don’t know what security holes I might open in the process. One workaround is to enable the root account and use ssh root@localhost but enabling root access is really an unnecessary step. Instead, I prefer to use su - adminaccountname, after which I can sudo the appropriate command(s) and exit to return to a standard shell.

  • Mac OS X keyboard shortcuts

    After my backup hard disk failed a couple of weeks ago, I needed to be sure that a hard reset of my Mac hadn’t damaged anything so I fired the machine up in single user mode and ran AppleJack.

    As it happened, there was nothing wrong, but there’s no harm in a bit of preventative maintenance from time to time; however I had forgotten the keypress to bring Mac OS X up in single user mode – for future reference, Apple has a document which details OS X keyboard shortcuts.

  • More on iChat AV

    A couple of weeks back I wrote about the issues I was having getting iChat AV working with services other than .Mac. Well, a few days ago, Alex and I finally managed to get it all working as intended.

    This is what I learnt:

    • Audio/visual (AV) chat is not supported over Jabber (I thought that it might work on a point-to-point basis as some commercial real-time collaboration products do – e.g. Microsoft Live Communications Server); however it does work using an ICQ account via the AOL Instant Messenger (AIM) transport within iChat AV.
    • If your buddy keeps switching out of iChat into other IM programs (e.g. Adium) then it will break your testing… Despite having loads of nice features Adium doesn’t support AV.
    • Some IM client combinations will render the conversation as raw HTML. That’s not very nice.
    • After deleting a contact from my buddy list, I was having problems recreating it (and was receiving a bizarre Feedbag error 14 message). Eventually, I gave up trying to add the contact via iChat (on either the AIM or the Jabber transport) and instead installed the native ICQ client, added my contact, and then switched back to using iChat AV (which could then read the contact from my ICQ buddy list). Following this, the audio/video icons (and menu options), previously greyed out, were enabled and we were able to have an audio/video conversation.

    There’s a conversation thread on the Apple Forums that describes some more of the troubleshooting steps that I went through.

  • Getting iChat AV to work with users on other IM services

    I find the PC vs. Mac ads that Apple is running at the moment amusing, but it does strike me as odd that a company with a brand as strong as Apple’s would drop to what is effectively bragging (even p***s envy?). It seems I’m not the only one either – from listening to TWiT episode 76 earlier today, it seems that “virtually everyone who watches it comes away liking the ‘PC guy’ while wanting to push the ‘Mac guy’ under a bus“!

    PC guy - Mac guy

    But hey… what’s my point exactly? Well, according to Apple’s get a Mac website (at the time of writing), reason number 1 to get a Mac is:

    “It just works. How much time have you spent troubleshooting your PC? Imagine a computer designed by people who hate to waste time as much as you do. Where all the hardware and software just works, and works well together. Get a Mac and get your life back.”

    Wake up and smell the coffee guys. I love my Mac, but it does not “just work”. That’s why I’ve spent hours (literally) using a third party utility to get iChat AV working without forking out for a .Mac account. It’s not the first time either, I’ve blogged before about how getting things to work on a Mac is not always as straightforward as it should be. I love my Mac but it has problems, as does any PC running any operating system (open or closed, proprietary or open-source).

    This is what I had to do…

    Apple iChat AV (I’m using v3.1.5 on Mac OS X 10.4.8) supports .Mac and AOL Instant Messenger (AIM) logins. It also supports Jabber – so I thought I’d prove the concept by getting it working with Google Talk (which is also based on Jabber). That turned out to be pretty straightforward – Google even provide instructions for configuring iChat for Google Talk. That’s all very well, but my contacts all use ICQ or MSN/Windows Live Messenger – wouldn’t it be great to get them all working within iChat? ICQ is another easy one… just add an AIM account to iChat and enter your ICQ number as the AIM screen name, but that still doesn’t help with any of the other services.

    Luckily Melvin Rivera at All Forces has written a comprehensive article about iChat to MSN through Jabber. In theory, this should work for any service, since Jabber acts as a gateway for communication with the various IM networks. I followed Melvin’s article to:

    1. Download and install PSI.
    2. Create a Jabber account – I chose a UK provider – tuff.org.uk – largely because their site gives a lot of information.
    3. Register the Jabber account within PSI.
    4. Select the required services (I chose MSN and ICQ – I’ll probably add more later but an account is required on each connected service).

    At this point, my MSN contacts all started to appear in the PSI client… although each one needed to be authorised (and the multiple alerts meant I had to force quit PSI a couple of times). Incidentally, if a load of contacts are stuck on waiting for authorization (this happened to me, and from reading the comments on Melvin’s article it’s not uncommon) right-clicking and selecting rerequest authorization from seemed to fix things (I then needed to open the alert which came back for each contact). I thought at first this meant getting all my contacts to approve me again but as long as the MSN servers know I’m not blocked from these contacts, the authorisation is immediate.

    Now, here’s the bit that I didn’t work out immediately… once the contacts have been sucked out of MSN (or elsewhere) and into Jabber, quit PSI… otherwise all the IM conversations occur within PSI, instead of iChat.

    Next, I configured iChat to use the tuff.org.uk Jabber server – the settings were the same as for Google Talk (except for the account name/password and the server). After that iChat was working with MSN and ICQ. For cross-platform instant messaging at least.

    The next stage was to get video/audio conferencing working. This is where I roped in a friend, using another Mac, connected via ADSL from his home a few miles away. It took us a while to get things going – in the end it was a MacRiot article about port forwarding to avoid iChat AV no audio/video woes that gave the answer, referring us to Apple’s document about using iChat AV with a firewall or NAT router.

    After opening TCP ports 5190, 5220, 5222 and UDP ports 5060, 5190, 5678 and 16384-16403 on my Internet-facing router, my friend was able to successfully invite me to an audio/video conversation (although for some reason I don’t see the icons to invite him). Incidentally, on a local network there will be additional ports required for client firewall configurations (UDP 5297, TCP/UDP 5298 and UDP 5353) and my Internet connection is NATted, so that is handled too. I just need to work out why I can’t see the options to invite contacts to audio or video chats (and to buy a webcam – my Sony CMR-PC1 is unsupported on a Mac and my DV camera turns itself off after a few minutes).

    (Whilst I was cursing Apple for not making this easier, my mate Alex pointed out that getting video conferencing working on a Windows PC would probably be just as bad… I replied that Microsoft don’t state that their software “just works” – just as well really – and nor do Apple caveat their marketing rhetoric with “subject to firewall/network configuration”)!

  • Remotely controlling Mac OS X using VNC

    I frequently control my Windows computers remotely from other Windows, Linux or Mac OS X computers using a remote desktop protocol (RDP) client; however there is no RDP server built into Mac OS X (not surprisingly, as RDP is a Microsoft protocol) and Apple’s remote control product (Apple Remote Desktop) is a little pricey for a network with only one Mac!

    All is not lost though, as I’ve found that I can use VNC Viewer (Free Edition 4.1.1 for X) on my Linux (Fedora core 5) box to remotely control my Mac (OS X 10.4.8) – I could probably use a Windows VNC client too but I haven’t tried yet.

    All that is required on the Mac side is to enable Apple Remote Desktop in the System Preferences (Sharing, Access Privileges, VNC viewers may control screen with password) and to set an appropriate password but, initially, I was having problems whereby the VNC Viewer refused to connect and returned the following error:

    Unknown message type

    It seems that the solution is to set the colour level connection option to use full colour (all available colours) – once this was set I was able to connect to the Mac and control it remotely.

  • Some tips for grabbing screenshots

    Coming from a Windows background, I’m used to grabbing a copy of the entire screen using the PrtSc key or the current window with Alt+PrtSc. When I first bought my Mac, I couldn’t work out how to do this without using the Grab application (which seems a little cumbersome for a simple screen shot) until Alex explained to me that, like so many things in OS X, there is some arcane keyboard shortcut that feels like it will induce a permanent strain on my fingers to do the job for me (I used to think the Ctrl-Alt-Del three finger salute was bad enough). I keep forgetting the keystrokes, so I’m blogging them here:

    • Command+Shift+3 – capture entire screen and save as a file
    • Command+Control+Shift+3 – capture entire screen and copy to the clipboard
    • Command+Shift+4 – capture dragged area and save as a file
    • Command+Control+Shift+4 – capture dragged area and copy to the clipboard
    • Command+Shift+4 then Space – capture a window, menu, desktop icon, or the menu bar and save as a file
    • Command+Control+Shift+4 then Space – capture a window, menu, desktop icon, or the menu bar and copy to the clipboard.

    For more on this, see the O’Reilly description of OS X screenshot secrets, which also links to a really useful hack to take a screenshot from DVD Player in OS X – simply type screencapture -i ~/Desktop/dvd.png in a terminal window, then hit Space and click on the DVD Player window to avoid the annoying restriction illustrated in the error message below.

    Error when attempt to screen grab from DVD Player

  • It’s time to practice safe computing – whatever the operating system

    I recently switched my primary home computer to a Mac but I also use Windows and Linux. I don’t consider myself to be a member of the Mac community, or the Linux community, or the Windows community – because (based on many forum posts and blog comments that I read) all of these “communities” are full of people with bigoted views that generally boil down to “my OS is better than your OS” or “Duh… but why would you want to use that?”.

    Based largely on Apple’s advertising though, one of the things that I did assume with Mac OS X was that I’d be secure by default. Nope. It turns out that’s not true as there is an obscure flaw in Mac OS X (surely not?!) whereby a malformed installer package can elevate its privileges in Mac OS X and become root. After running Windows for 16 years I’m used to these sort of flaws but surely His Jobsness’ wonderful creation is above such things!

    Frankly I don’t care that Mac OS X is flawed. So is Linux. So is Windows. So is anything with many millions of lines of code – open or closed source – but I thought better of Apple because I believed that they would keep me safe by default. It’s well known that running Windows XP as anything less than a Power User is difficult and that’s one of the many improvements in Windows Vista. All the Linux installers that I’ve used recently suggested that I create a non-root user as well as root but the OS X installer is happy for me to breeze along and create a single administrator account without a word of further advice. I appreciate that an OS X administrator is not equal to root but nevertheless it’s a higher level of access than should be used for daily computing and because I didn’t know any better (I’m just a dumb switcher) I didn’t create a standard user account (until today).

    I read a lot of Mac and Linux zealots singing the praises of their operating systems and saying how Windoze is a haven for spyware and viruses. Well, it’s time to wake up and smell the coffee – as Mac OS X gains in popularity (I heard something about the new MacBooks having a 12% share of all new laptop sales recently) then Mac users will have to start thinking about spyware, viruses and the like. Now is the time to practice safe computing – whatever the operating system – with most users running as administrators then that could quickly become a major issue.