Category: Hacking

  • ssh asking for password when it shouldn’t

    After a recent Ubuntu upgrade, one of my frequented remote servers stopped accepting my public key and was prompting me for my password.  The password is gross and unwieldy and I was most put-out, I must say.  So, I googled the title of this post.  Mostly suggestions to check the permissions of various files.  All of mine were locked tight to user-only, including my home directory.

    Of course, I’d already tried ssh -vvv to get all the debugging output.  Unfortunately, I zoomed in on the following message:

    debug1: Next authentication method: publickey
    debug2: we did not send a packet, disable method
    
    

    Instead of this one a little further up:

    debug1: Skipping ssh-dss key /home/ME/.ssh/keyfiles/ME.key - not in PubkeyAcceptedKeyTypes
    
    

    Rather than add ssh-dss to the supported types, I just created a new key with ssh-keygen.   An ssh-copy-id later, everything worked.

    … except when it didn’t.  Adding the following to ~/.ssh/config</tt for the offending host worked:

    Host refuses-my-agent-keys.jerkass.com
        PubkeyAcceptedKeyTypes +ssh-dss
    
    
  • Shell Nuggets: Quickie Tabulizer

    I’m real bad about things lining up.  Used to go out of my way to ensure variable declarations were columnized by access mode, type, name, equals sign and initial value.

    final BufferedImage mapImg = MapImageFactory.newInstance(width, height);
    final int           count  = ad.getPosition() * 2;
    
    mapImg.composite(adImg, 25               , (this.adHeight + 20) * count + 20, Over);
    mapImg.composite(adTxt, 25 + this.adWidth, (this.adHeight + 20) * count + 20, Over);
    

    The Tabularizer plugin for vim was a boon for productivity.  Well, mine.  For everyone else, it meant either destroying the pre-formatted beauty or re-aligning all the columns.

    Anyway, it’s considered bad practice, so I’ve tried to get away from it– at least when writing shared code.  I still like perfect tabular output in my day-to-day.  Take the df command, for example.  It’s default “human readable sizes” output:

    2016-02-05 11:03:57 «««« ~
     rons@rons-VM$ df -h
    Filesystem            Size  Used Avail Use% Mounted on
    /dev/mapper/VolGroup00-LogVol00
                           59G   29G   27G  52% /
    /dev/sda1              99M   33M   61M  36% /boot
    tmpfs                 1.5G     0  1.5G   0% /dev/shm
    

    Bleah. A line break. Why you mess my rows, GNU? An easy fix jumped into my noggin the other day and crept down my arms and out my fingertips:

    2016-02-05 11:03:58 «««« ~
     rons@rons-VM$ df -h | sed 's/Mounted on$/Mount/;' | xargs printf '%-40.40s %8s %8s %8s %5s  %s\n'
    Filesystem                                   Size     Used    Avail  Use%  Mount
    /dev/mapper/VolGroup00-LogVol00               59G      29G      27G   52%  /
    /dev/sda1                                     99M      33M      61M   36%  /boot
    tmpfs                                        1.5G        0     1.5G    0%  /dev/shm
    

    The trick is that a printf format with a trailing newline will repeat if it runs out of input tokens.   That’s why I had to truncate the “Mounted on” to just “Mount” above– otherwise there would be an irregular number of columns (and thus printf tokens) on each line/row.  Spaces in filesystems and mounts will mess it up, too, but if you use spaces in the names of your mounts, you deserve the dissonance.

    Edit: Better shell function replacement below.

    unset -f df ; function df() {
      command df -P $@ | perl -ane '
        push(@rows, [@F]);
        for (0..$#F) {
          $ll = length($F[$_]); $cm[$_] = $ll if $ll > ($cm[$_] // 0);
        }
        END { printf("%-$cm[0]s %$cm[1]s %$cm[2]s %$cm[3]s %$cm[4]s %s\n", @{$_})
          for @rows; }';
    } ;

     

    Uses the -P flag for POSIX one-line-per-mount format.   Dynamically calculates column widths.

     

  • Why 80 characters?

    Searching for reasonable values for the *.vt100.geometry[5-6] xterm menu font-menu options in my ~/.Xdefaults file, I re-stumbled a gem of computing history as the top-answer to a question on StackOverflow, and this pretty picture of an old IBM punch-card.

    Inspired by a perl script within the comments, I ran this shell pipe:

    2015-07-23 10:30:00 :: ~
     rons@rons-VM$ find /usr/share/terminfo/ -type f -printf '%f\n' |
       xargs -n1 infocmp | egrep -o 'cols#[0-9]+, *lines#[0-9]+' |
       sort | uniq -c | sort -nr | head
     489  cols#80,  lines#24
     58   cols#132, lines#24
     55   cols#80,  lines#25
     27   cols#80,  lines#34
     15   cols#80,  lines#40
     15   cols#80,  lines#31
     14   cols#80,  lines#33
     12   cols#126, lines#24
     10   cols#85,  lines#64
     8    cols#80,  lines#42

    Unsure if infocmp normalizes its output such that the cols and lines entries will always be adjoined, but this is good enough for my purposes.

    80×24 wins by a landslide, with 132×24 a distant second.   Then I found a Gnome help page which added 80×43 and 132×43 as options for its gooey{sic} terminal.  Next, a quick stop at the SVGA documentation in the Linux kernel with another list of common geometries.

    Finally, the Wikipedia Text Mode entry which included a neat table of common text modes:

    Text res. Char. size Graphics res. Colors Adapters
    80×25 9×14 720×350 B&W MDA, Hercules
    40×25 8×8 320×200 16 CGA, EGA
    80×25 8×8 640×200 16 CGA, EGA
    80×25 8×14 640×350 16 EGA
    80×43 8×8 640×350 16 EGA
    80×25 9×16 720×400 16 VGA
    80×30 8×16 640×480 16 VGA
    80×50 9×8 720×400 16 VGA
    80×60 16 VESA-compatible SVGA
    132×25 16 VESA-compatible SVGA
    132×43 16 VESA-compatible SVGA
    132×50 16 VESA-compatible SVGA
    132×60 16 VESA-compatible SVGA

    I think I’ll go with 80×50 and 132×60.