Checking SSH Private Keys for Passphrases

Imposing ridiculously over the top security policies? Want to make sure any SSH private keys on your jump-off/administration server have a passphrase?

Don’t waste time trying to get expect working…

expect <

Just look at the damn file (thanks @ealexhudson and @Azquelt) and check if it’s got ‘Proc-Type: 4,ENCRYPTED’ in.

Without

root@a-server ~ # find /home/*/.ssh/ -name "id_*sa" -exec grep -L ENCRYPTED {} \; | wc -l
19

With

root@a-server ~ # find /home/*/.ssh/ -name "id_*sa" -exec grep -l ENCRYPTED {} \; | wc -l
1

Lovely. This of course doesn’t solve the issue of checking, from the SSH public keys, whether the private keys have passphrases or not.

LVM Stale NFS File Handles (Part 1)

So, here’s an interesting issue

(initramfs) mount
rootfs on / type rootfs (rw)
none on /sys type sysfs (rw,nosuid,nodev,noexec)
none on /proc type proc (rw,nosuid,nodev,noexec)
udev on /dev type tmpfs (rw,size=10240k,mode=755)
/dev/pudding/root on /mnt type ext3 (rw,errors=continue,data=ordered)

 

So I’m using BusyBox, with an LVM volume mounted on /mnt. Happy?

(initramfs) ls /mnt
ls: /mnt/initrd.img.old: Stale NFS file handle
ls: /mnt/vmlinuz: Stale NFS file handle
ls: /mnt/vmlinuz.old: Stale NFS file handle

Only one directory (was, a while ago) exported by NFS, which isn’t one that is affected, and the box has never mounted anything by NFS. It seems like the error can be caused when a file is open and the disk falls out from underneath it, and an ambiguous error code is sent back which is interpreted as a stale filehandle. Either way, the superblock on this particular FS is corrupted, so the next step would be to attempt to recover using one of the backup superblocks. I’ll attempt this later and let you know how it goes. I’m sure you’ll be on the edge of your seats.

Bitlbee -> Facebook rename script update

If you’ve recently noticed that your renamed users in bitlbee have changed back to UIDs, it’s probably because Facebook have changed their UID string from being ‘uNNNNNN’ to ‘-NNNNNN’. Not a huge problem, just change the script:

% diff bitlbee_rename.pl.old bitlbee_rename.pl
22c22
<   if($channel == $bitlbeeChannel && $nick == $username && $nick =~ m/^ud+/ && $host == “chat.facebook.com”)
—-
>   if($channel == $bitlbeeChannel && $nick == $username && $nick =~ m/^-d+/ && $host == “chat.facebook.com”)
25c25
<     $server->command(“whois $nick”);
—-
>     $server->command(“whois ”$nick”“);

(My) updated version here. Hope this helps at least one person.

Update

@TheSamoth has pointed out that new bitlbee (v >=1.2.5)doesn’t actually require the rename script, as it has the functionality built in and can be enabled with. Thanks!

account set facebook/nick_source full_name

Bitlbee -> Facebook rename script update

If you’ve recently noticed that your renamed users in bitlbee have changed back to UIDs, it’s probably because Facebook have changed their UID string from being ‘uNNNNNN’ to ‘-NNNNNN’. Not a huge problem, just change the script:

% diff bitlbee_rename.pl.old bitlbee_rename.pl
22c22
<   if($channel == $bitlbeeChannel && $nick == $username && $nick =~ m/^ud+/ && $host == “chat.facebook.com”)
—-
>   if($channel == $bitlbeeChannel && $nick == $username && $nick =~ m/^-d+/ && $host == “chat.facebook.com”)
25c25
<     $server->command(“whois $nick”);
—-
>     $server->command(“whois \”$nick\”“);

(My) updated version here. Hope this helps at least one person.

Update

@TheSamoth has pointed out that new bitlbee (v >=1.2.5)doesn’t actually require the rename script, as it has the functionality built in and can be enabled with. Thanks!

account set facebook/nick_source full_name

MegaRaid Lies

Dell PowerEdge 1850. I’ve never seen it in the flesh, but believe it has a MegaRAID card.

# lsscsi
[0:0:6:0]    process PE/PV    1×2 SCSI BP      1.0   -
[0:1:0:0]    disk    MegaRAID LD 0 RAID1   69G 516A  /dev/sda
# grep -i raid /var/log/dmesg
[   20.251664] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006)
[   20.690899] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006)
[   20.690929] megaraid: probe new device 0×1028:0×0013:0×1028:0x016c: bus 2:slot 14:func 0
[   20.690964] megaraid 0000:02:0e.0: PCI INT A -> GSI 46 (level, low) -> IRQ 46
[   21.324054] megaraid: fw version:[516A] bios version:[H418]
[   21.332182] scsi0 : LSI Logic MegaRAID driver
[   21.332598] scsi[0]: scanning scsi channel 0 [Phy 0] for non-raid devices
[   24.821907] scsi 0:1:0:0: Direct-Access     MegaRAID LD 0 RAID1   69G 516A PQ: 0 ANSI: 2

Seems fine, right?

# ./MegaCli64 -adpCount
Controller Count: 0.
Exit Code: 0×00

Hrm.

/opt/MegaRAID/MegaCli # omreport storage controller
No controllers found

Starting to get tweaky.

Update

Thanks to jtopper for the help so far. Getting a bit further, but still:

wget http://www.lsi.com/DistributionSystem/AssetDocument/files/support/rsa/utilities/megaconf/ut_linux_megarc_1.11.zip
unzip ut_linux_megarc_1.11.zip
sudo ./megarc.bin -AllAdpInfo
        Failed to get driver version
        No Adapters Found

And…

$ grep MAJOR megarc
MAJOR=`grep megadev /proc/devices|awk ‘{print $1}’`
$ grep -ci mega /proc/devices
0

Further Update

I’ve finally managed to get to the bottom of this. Looks like any app which creates the /dev/megadev0 device does it with the wrong major. To fix this, based on some brilliant info, I used a major of 10 (now that 252 is used for usbmon), and a minor from /proc/misc.

# mknod /dev/megadev0 c 10 59
# ./megarc -dispCfg -a0
        **********************************************************************
              MEGARC MegaRAID Configuration Utility(LINUX)-1.11(12-07-2004)
              By LSI Logic Corp.,USA
        **********************************************************************
          [Note: For SATA-2, 4 and 6 channel controllers, please specify
          Ch=0 Id=0..15 for specifying physical drive(Ch=channel, Id=Target)]
        Type ? as command line arg for help
        Finding Devices On Each MegaRAID Adapter…
        Scanning Ha 0, Chnl 0 Target 15
        **********************************************************************
              Existing Logical Drive Information
              By LSI Logic Corp.,USA
        **********************************************************************
          [Note: For SATA-2, 4 and 6 channel controllers, please specify
          Ch=0 Id=0..15 for specifying physical drive(Ch=channel, Id=Target)]
          Logical Drive : 0( Adapter: 0 ):  Status: OPTIMAL
        —————————————————————————-
        SpanDepth :01     RaidLevel: 1  RdAhead : Adaptive  Cache: DirectIo
        StripSz   :064KB   Stripes  : 2  WrPolicy: WriteBack
        Logical Drive 0 : SpanLevel_0 Disks
        Chnl  Target  StartBlock   Blocks      Physical Target Status
        ——  ———  —————   ———      ———————————
        0      00    0×00000000   0x0887c000   ONLINE
        0      01    0×00000000   0x0887c000   ONLINE

Hope this helps someone, and many thanks to these guys.