websiterot.blogg.se -

#Ssh for mac m1 how to
#Ssh for mac m1 pro
#Ssh for mac m1 code
#Ssh for mac m1 password

config.templates/ contains SSH configuration blocks which can be included on a given machine, but shouldn’t be included everywhere.

See the “Long-lived screen sessions” section, below, for an explanation on why this is necessary. In this case, it updates a symlink in ~/.ssh/sock to point to the new SSH agent socket.

rc runs after I log into a machine via SSH.

I run this after pulling from the repository if it results in any changes the files’ permissions in the repo should be corrected.

fix-permissions.sh ensures that ~/.ssh/authorized_keys and ~/.ssh/rc have the correct permissions.

At the top, it sets some SSH best practices that I’ve accumulated over the years.

config is where you’ll add Host blocks for your servers.

authorized_keys is where you’ll add the public keys associated with the new, private SSH keys on your Yubikeys.

README.md covers initial installation & setup.

I’ve created a stripped-down version at cdzombak/ssh-example which you can use as a basis for your own setup. This allows me to sync configuration and authorized_keys changes between systems easily. I keep my ~/.ssh directory, with a few important exceptions (keys are never committed!), in a private Git repo. MacOS tends to lose changes to sshd_config during OS upgrades, so after installing macOS updates I make sure to check that my SSH server configuration is intact. Restart the SSH service, and immediately - before logging out - open a new terminal window and test that you can still login to the server with your Yubikey. (That last line - PermitRootLogin no - ensures that logins as root via SSH are never allowed, which is a good SSH best practice unrelated to Yubikeys.) Make this change only after you’ve set up a Yubikey and added it to authorized_keys for your user account on the server! On every server, in /etc/ssh/sshd_config, I set the following.

#Ssh for mac m1 password

Of course, moving to Yubikeys doesn’t solve much if your servers still allow password logins. (Worth noting, this changes the security model somewhat, as the second factor is biometric rather than a PIN, but it’s still two factors.)

#Ssh for mac m1 pro

I plan to move to Big Sur soon enough, since I want to get an M1 MacBook Pro when the 16” models are released, so I’ll be able to try Secretive soon enough. Unfortunately, for Reasons™ I’m still using macOS Mojave, and Secretive requires Catalina or Big Sur. I’d like to use the new macOS app Secretive, which stores SSH keys in the Secure Enclave on newer MacBooks and requires Touch ID to authenticate. This allows apps started from outside your terminal - like the GUI Git client, Fork.app - to find and use yubikey-agent. IdentityAgent /usr/local/var/run/yubikey-agent.sock (The commands and configuration changes under this heading apply to client machines with attached Yubikeys.)

#Ssh for mac m1 how to

It’s pretty straightforward to set this up the real work was figuring out how to smooth out the various difficulties I encountered later. I found it easiest by far to use yubikey-agent for this project. I use a private Git repository to synchronize SSH configuration (including authorized_keys, the list of public keys corresponding to my Yubikeys) between machines, with a modular local configuration system allowing me to quickly enable commonly-used SSH configuration blocks which only apply to a subset of my machines. With yubikey-agent, my preferred agent software, every single SSH operation - yes, even those performed via agent forwarding - requires a physical touch to confirm.

#Ssh for mac m1 code

SSH agent forwarding is used to allow me to SSH from one server to another or fetch code from GitHub on a remote server. The Yubikeys require a PIN, so this is an example of two-factor authentication: something I physically have, and something I know. To do this, I moved to using a few Yubikeys to store my SSH keys there’s no longer key material stored on any server for a hypothetical attacker to steal. I wanted to ensure that, should an attacker gain access to one of my servers, they can’t use that access to move onto any other computer I control. This presents a number of obvious security problems. Historically, I’ve used a pretty basic SSH setup for my personal projects: my user account on every laptop/desktop/server had its own key in ~/.ssh, and I’d try to keep the authorized_keys lists on all my servers more-or-less up-to-date. In this post, I’ll outline my goals, the strategy I took, and the problems and solutions I ran into along the way. One recently-completed project I mentioned in January’s “Now” post was locking down SSH in my personal computing infrastructure using Yubikeys. Securing my personal SSH infrastructure with Yubikeys February 08, 2021