1. 48

  2. 8

    Some more notes:

    • Generating private keys on a hardware token is not necessarily the best idea. Remember the low entropy bug the Yubikeys had a few years ago?

    • Instead of ProxyCommand with arcane parameters you can use ProxyJump. This will get you to B through A:

        Host b.example.com
        ProxyJump a.example.com
    1. 6

      I had no idea that YubiKeys could store SSH and GPG keys. Currently, my whole digital identity can be trivially bootstrapped from my SSH key and my GPG key:

      1. Install SSH and GPG keys
      2. Use SSH to clone my pass database from git.nora.codes
      3. Use GPG to decrypt any password from my pass database
      4. Use GPG + a symmetric key derived from a passphrase I have memorized to get all my financial information

      It would be really nice to back these with a hardware store.

      1. 3

        They only store gpg keys (as a smartcard), but the gpg-agent tool can use gpg keys for ssh (as a drop in replacement for the ssh-agent tool).

        You can use gpg-agent to use any gpg key as an ssh key, not just a smartcard one.

        1. 2

          A great guide to setting up GPG and ssh with a Yubikey can be found here. I found it very helpful.

          1. 2

            Ah, understood. Very cool!

            1. 2

              You may also want to look at pivy which allows SSH key and other signing use of Yubikeys and smart cards without the GPG business!

        2. 3

          profile refers to something that runs only in interactive shells

          That should probably be “interactive login shells”. I don’t think ~/.profile is sourced by an interactive non-login shell.

          Source: man bash, section INVOCATION

          1. 6

            I’m not sure it’s hyperbole to say nearly every word in the author’s first sentence is wrong.

            The ~/.profile is for interactive login shells, where “login” is the important part because it runs when you login at the terminal or over SSH.

            This contrasts with ~/.bashrc, which is for interactive non-login shells, where “non-login” is the important part because it runs when you open a new terminal emulator window in X.

            Neither of these files relate to non-interactive shells, scripts, or keyboards.

            Many people who find this confusing are running MacOS (like the author), which treats all terminal emulator windows as login shells by default. You can change this setting.

            1. 3

              Good explanation of the difference between “login” and “non-login”.

              By putting

              XTerm*loginShell: true

              into ~/.Xresources you can make xterm to always start login shells.

              1. 4

                This is probably a less robust solution than sourcing bash_profile from bashrc to achieve the same effect in a more explicitly declared way, unless your machine is starting X and a GUI login prompt before the login user authenticates (as with OpenBSD Xenocara).

                The “all terminal emulator windows are login shells” setting makes sense on MacOS because there is no concept of logging in at the terminal per se, and MacOS machines are usually your client for SSH rather than your server. I assume they’ve set this default behavior because it generally fits the mental model to think of a terminal emulator window as being a discrete “login” to the BSD/Darwin part of the operating system, whereas most other Unix-like systems fit a mental model where the terminal world is the place the GUI lives inside (so, the opposite).

                Do whatever best fits your individual interface paradigm so you intuitively know where behavior is being set.

                It should also be said that you shouldn’t use ~/.profile at all if you’re not taking precautions to avoid bash-isms, because that file is to be used by all shells. If your current use-case is bash-only, use ~/.bash_profile to run shell commands at login, ~/.bashrc to run shell commands each time you open a terminal emulator post-login, and ~/.bash_logout for shell commands run upon exit from a login shell.

          2. 2

            I should add that for any ssh server you want to keep running for a while. Autossh is your friend https://www.everythingcli.org/ssh-tunnelling-for-fun-and-profit-autossh/

            1. 2

              I recently implemented a modular system for zsh! Glad to see it’s a known pattern

              1. 2

                An ssh key on disk, even with a passphrase, is vulnerable to malware (malware can steal your files, and keylog your passphrase to decrypt them). Put your ssh private keys somewhere that software (any software, even your own) on your computer simply cannot access them.

                This is technically true but misleading. A malware that can read files on disk can also reuse your SSH connections or wait until you start a new SSH connection to hijack it.

                The same problem applies to security keys used with browsers. You still rely heavily on your desktop not being compromised… (!)

                1. 1

                  That only works while it is plugged in. It doesn’t work offline, as stealing a private key does.

                  1. 2

                    Yes: I wrote “wait until”…

                2. 1

                  “Use a remote docker”

                  Well I do something similar on Windows using minikube. I believe you can do the same on MacOS X.