User Tools

Site Tools


osx:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
osx:start [2018/06/15 14:13]
robm [Middle-click via the trackpad]
osx:start [2022/05/13 13:19] (current)
robm [GPG with remote forwarding]
Line 671: Line 671:
 sudo route add default $NAKED_GATEWAY_IP sudo route add default $NAKED_GATEWAY_IP
 </code> </code>
- 
-====== VPN over SSH ====== 
- 
-  * **Server**: GNU/Linux (Ubuntu 12.04) -- ''172.16.0.1'' 
-  * **Client**: MacOS/BSD (El Capitan, v10.11.5) -- ''172.16.0.2'' 
- 
-Create and configure a tunnelled connection between client and server, via ''tun0'' interfaces: 
- 
-  - Go install http://tuntaposx.sourceforge.net/download.xhtml on the Mac, it is needed by ''ssh'' 
-  - SSH into the server and edit ''/etc/ssh/sshd_config'' to include <code> 
-PermitRootLogin yes 
-PermitTunnel yes 
-</code> 
-  - Restart SSHd on the server (''service ssh reload'' does not appear to be sufficient) <code>sudo service ssh stop; sudo service ssh start</code> 
-  - Log out of server (need to reconnect to make use of config changes) 
-  - **As root** on the client machine, SSH into the root account on the server with tun devices enabled via ''-w'' option<code>ssh root@server.hostname.com -w 0:0</code> (''0:0'' specifies that both local and remote ends will create ''tun0'' interfaces) 
-  - Within the resulting root shell on the **server**, configure the new ''tun0'' network interface: <code> 
-ifconfig tun0 inet 172.16.0.1 dstaddr 172.16.0.2 
-ifconfig tun0 
-ping 172.16.0.1  # Check tun0 has an IP address 
-ping 172.16.0.2  # Should fail, as we've not yet configured the client's tun0 
-</code> 
-   - In a root shell on the **client**, configure the new ''tun0'' network interface: <code> 
-ifconfig tun0 inet 172.16.0.2 172.16.0.1 
-ifconfig tun0 
-ping 172.16.0.2  # Check tun0 has an IP address 
-ping 172.16.0.1  # Check we can communicate with remote end (server) via tun0 
-</code> 
-   - Back in the root shell on the **server**, repeat ''ping 172.16.0.2'' and this time it should respond 
-   - The tunnel is now configured. It will remain so until the SSH session is closed. 
- 
-Configure IPv4 (ICMP+TCP+UDP) forwarding and Network Address Translation (NAT): 
- 
-   - In the root shell on the **server** (only needs to be done one per boot): <code> 
-# Prepare networking stack for use by forced commands in 
-# /root/.ssh/authorized_keys that creates a point-to-point network (via tun0) 
-# between 172.16.0.1 (this host) and 172.16.0.2 (remote end). 
- 
-# We then want to enabling forwarding of IPv4 traffic, i.e. we want to act as a 
-# router. We enable this in the kernel, and then ensure traffic originating 
-# from the remote side of the point-to-point link is accepted, and any 
-# responses are likewise accepted 
-echo 1 > /proc/sys/net/ipv4/ip_forward 
-/sbin/iptables -F 
-/sbin/iptables -A FORWARD ! --source 172.16.0.2 --destination 172.16.0.2 \ 
-        -m state --state RELATED,ESTABLISHED -j ACCEPT 
-/sbin/iptables -A FORWARD --source 172.16.0.2 ! --destination 172.16.0.2 -j ACCEPT 
- 
-# Any traffic originating from the remote side should go through Network 
-# Address Translation (NAT), so responses from (e.g.) DNS servers are sent to 
-# this host, so *we* can forward it to the remote end. This is the MASQUERADE 
-# rule. 
-/sbin/iptables -t nat -F 
-/sbin/iptables -t nat -A POSTROUTING ! --destination 172.16.0.2  -j MASQUERADE 
- 
-# Monitor packets 
-watch -n0.5 -d ifconfig tun0 
-</code> 
-   - As root on the **client**: <code> 
-route add 10.0.0.0/8 -interface tun0 
-</code> (you can undo this by repeating the command with ''delete'' in place of ''add'') 
-   - IPv4 forwarding via ''tun0'' is in effect. 
- 
-Note: The changes made to the server persist after the SSH session has ended. 
- 
-To get name resolution working, you need to configure the client to use a DNS server at the remote end, e.g. 
- 
-   - Discover the DNS nameservers used by the **server**: <code>cat /etc/resolv.conf</code> 
-   - Add these to the **client** system: <code>networksetup -setdnsservers Wi-Fi 10.1.2.24 10.1.2.23 192.168.1.253 8.8.8.8 8.8.4.4</code> This step must be manually undone (e.g. after closing the SSH session) by running <code> networksetup -setdnsservers Wi-Fi Empty</code> 
- 
-You may also want to add your remote system's DNS search domains, e.g.: <code>networksetup -setsearchdomains Wi-Fi site.example.com example.com local</code> Again, this must be manually undone after you close the VPN connection: <code>sudo networksetup -setsearchdomains Wi-Fi Empty</code> 
- 
-Most useful guides: 
- 
-   * http://ubuntuforums.org/showthread.php?t=926435&page=3&p=7886699#post7886699 
-   * http://kovyrin.net/2006/03/17/how-to-create-ip-ip-tunnel-between-freebsd-and-linux/ 
-   * https://help.ubuntu.com/community/SSH_VPN 
-   * https://blog.brixandersen.dk/2006/10/23/vpn-using-openssh-and-tun4-under-freebsd/ 
-   * http://osxdaily.com/2015/06/02/change-dns-command-line-mac-os-x/ 
-   * NAT: http://www.revsys.com/writings/quicktips/nat.html 
-   * SSH, including forced-commands via ''.ssh/authorized_key'': https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys 
- 
-More thorough networking (Ethernet layer, instead of link layer): http://sgros.blogspot.co.uk/2011/11/ssh-vpns-bridged-connection-to-lan.html 
  
 ====== Global Keyboard Shortcut to toggle Skype microphone ====== ====== Global Keyboard Shortcut to toggle Skype microphone ======
Line 795: Line 712:
 session    required       pam_permit.so session    required       pam_permit.so
 </code> </code>
- 
 These appear to be tried in the order listed, and if one aborts (e.g. press ESC for TouchID) the next is tried (i.e. the usual terminal password prompt) These appear to be tried in the order listed, and if one aborts (e.g. press ESC for TouchID) the next is tried (i.e. the usual terminal password prompt)
  
 +
 +To make this work from within ''tmux'' sessions, you can install another PAM module: ''pam_reattach.so'': https://github.com/fabianishere/pam_reattach
 +
 +Install by first running:
 +
 +<code>
 +brew install pam-reattach
 +</code>
 +
 +and then modifying ''/etc/pam.d/sudo'' to add it before ''pam_tid.so'':
 +
 +<code>
 +# sudo: auth account password session
 +auth       optional       pam_reattach.so
 +auth       sufficient     pam_tid.so
 +auth       sufficient     pam_smartcard.so
 +auth       required       pam_opendirectory.so
 +account    required       pam_permit.so
 +password   required       pam_deny.so
 +session    required       pam_permit.so
 +</code>
 ====== Automatic fan control when on AC power to avoid sweaty palms ====== ====== Automatic fan control when on AC power to avoid sweaty palms ======
  
Line 803: Line 740:
  
   brew cask install smcfancontrol   brew cask install smcfancontrol
 +
 +====== GPG with remote forwarding ======
 +
 +GPG Agent forwarding allows a remote system to access secrets held in your local system via an SSH tunnel. When you are not connected to the remote system, it cannot access your secrets, and if the remote system is compromised your secrets are not (since they are never stored on it).
 +
 +My (initial) use-case is to allow docker on a remote host to store login my login credentials (so I can push/pull images when working), but not store secrets on that hose. THe default behaviour is to store my password in plain text, which is unacceptable.
 +
 +So I opted to use [[https://docs.docker.com/engine/reference/commandline/login/#credentials-store|docker credentials management]] and [[https://www.passwordstore.org/|pass]]. The ''pass'' tool uses GPG to encrypt and decrypt passwords. If I use GPG the traditional way (with secret keys in my $HOME directory) I've not gained any security: the encrypted password and and the decryption key are on the same host!
 +
 +So I want to use GPG agent forwarding to allow ''pass'' to decrypt secrets while I am connected and working, without the decryptions keys ever leaving my laptop.
 +
 +Overview (notes to follow, I hope):
 +
 +  - Install GPG locally and create an identity
 +  - Ensure that passphrase challenge ("pinentry") does _not_ use the TTY, since the TTY at the remote won't match local - better to use a GUI or the OSX KeyChain
 +  - Install GPG on remote, and import public key
 +  - Configure SSH to forward agent socket
 +  - Disable systemd stuff which creates (unused) gpg sockets and/or configure SSHd to allow you to delete and recreate those sockets
 +
 +Gotchas to document:
 +
 +Invalid ioctl for device means the GPG agent was attempting to open a TTY. The agent lives on my MacBook, but the request comes from a remote system. So the remote system's GPG_TTY value is utterly useless on my MacBook, hence the error. Pinentry is the method by which the end-user (me) is prompted to enter a passphrase of the decryption key, the default is TTY, which doesn't work in this scenario. Using a GUI based one (line pinentry-mac) solves this, since the GUI always pops up on my Macbook.
 +
 +https://www.binarybabel.org/2017/03/10/setting-up-pin-entry-for-gpg-under-macos/
 +
 +  - ''brew install gnupg gpg-agent pinentry-mac''
 +  - Append to ''~/.profile'': <code> if [ -f ~/.gnupg/.gpg-agent-info ] && [ -n "$(pgrep gpg-agent)" ]; then
 +    source ~/.gnupg/.gpg-agent-info
 +    export GPG_AGENT_INFO
 +else
 +    eval $(gpg-agent --daemon --write-env-file ~/.gnupg/.gpg-agent-info)
 +fi</code>
 +  - Create/modify the following GPG files:
 +    - ''mkdir -p ~/.gnupg''
 +    - ''~/.gnupg/gpg.conf'':<code>use-agent</code>
 +    - ''~/.gnupg/gpg-agent.conf'':<code> use-standard-socket
 +pinentry-program /usr/local/bin/pinentry-mac
 +default-cache-ttl 600
 +max-cache-ttl 7200</code>
 +
 +https://superuser.com/a/1439824/25945
 +
 +Testcase:
 +
 +<code>echo "foo" | gpg --encrypt -r "Robert Meerman" | gpg --decrypt</code>
 +
 +Remote end:
 +
 +Modify ''/etc/ssh/sshd_config'' to include:
 +
 +<code>
 +# Allow socket files to be unlinked by incoming connections (intended to
 +# faciliate use of GPG Agent)
 +StreamLocalBindUnlink yes
 +</code>
 +
 +See https://wiki.gnupg.org/AgentForwarding
 +
 +Client: ''gpg -K'' to show secret (private) keys. Take the HEX (public key fingerprint) and ...
 +
 +Server: ''gpg --recv-key 6F840EE9A203D5283CAA943EF07529A9FE85C329''
 +
 +.. and trust it, or tools like 'passwd' cannot use it:
 +
 +Server: ''gpg --edit-key "Robert Meerman"'' and then enter ''trust'' and set to ''Ultimate'' (it's your own key after all), then ''quit''.
 +
 +Server testcase: <code>echo "foo" | gpg --encrypt -r "Robert Meerman" | gpg --decrypt</code>
 +
 +**Future direction**: Use [[https://medium.com/@prbinu/touch2sudo-enable-remote-sudo-two-factor-authentication-using-mac-touch-id-df638b7da594|touch2sudo]] to prompt for finger print before providing credentials?
 +====== Number Pad ======
 +
 +I installed an application to make my iPhone act as a Number Pad: https://apps.apple.com/gb/app/remote-keypad-numpad-keyboard/id1135300319
 +
 +Satisfies [[https://blender.stackexchange.com/q/108249/20696|Blender's obsession]] with number pads!
 +
 +====== Working with Certificates ======
 +
 +Tool to help with generating / converting certificates: 
 +
 +[[https://hohnstaedt.de/xca/]] -- X - Certificate and Key management
 +
 +====== Monitor Brightness Control (external monitor) ======
 +
 +[[https://github.com/MonitorControl/MonitorControl|MonitorControl/MonitorControl: 🖥 Control your external monitor brightness & volume on your Mac]]
 +
 +<code>
 +brew cask install monitorcontrol
 +</code>
 +
 +====== Fan Control ======
 +
 +(iStat Menus doesn't seem to work with MacBook Pro 16" 2019)
 +
 +https://crystalidea.com/macs-fan-control/download
 +
 +====== Change URL and file-type/MIME default handlers ======
 +
 +https://github.com/Lord-Kamina/SwiftDefaultApps
 +
 +or ''brew install swiftdefaultappsprefpane''
 +
 +====== Download files from interactive SSH sessions ======
 +
 +iTerm2.app snippet:
 +
 +<code>
 +alias download="bash <(base64 -d <<<'IyEvYmluL2Jhc2gKaWYgWyAkIyAtbHQgMSBdOyB0aGVuCiAgZWNobyAiVXNhZ2U6ICQwIGZpbGUg
 +Li4uIgogIGV4aXQgMQpmaQpmb3IgZmlsZW5hbWUgaW4gIiRAIgpkbwogIGlmIFsgISAtciAiJGZp
 +bGVuYW1lIiBdIDsgdGhlbgogICAgZWNobyBGaWxlICRmaWxlbmFtZSBkb2VzIG5vdCBleGlzdCBv
 +ciBpcyBub3QgcmVhZGFibGUuCiAgICBjb250aW51ZQogIGZpCgogIGZpbGVuYW1lNjQ9JChlY2hv
 +IC1uICIkZmlsZW5hbWUiIHwgYmFzZTY0KQogIGZpbGVzaXplPSggJCh3YyAtYyAiJHtmaWxlbmFt
 +ZX0iKSApCiAgcHJpbnRmICJcMDMzXTEzMzc7RmlsZT1uYW1lPSR7ZmlsZW5hbWU2NH07c2l6ZT0k
 +e2ZpbGVzaXplWzBdfToiCiAgYmFzZTY0IDwgIiRmaWxlbmFtZSIKICBwcmludGYgJ1xhJwpkb25l
 +Cg==')"
 +
 +</code>
 +
 +Also offered as an answer [[https://stackoverflow.com/questions/43453419/iterm2-quick-download-over-ssh-using-cmdclick/69854250#69854250|on StackOverflow]]
  
osx/start.1529072035.txt.gz · Last modified: 2018/06/15 14:13 by robm