Philip Tellis bluesmoon

## addSSHKeys.md

      
              1 file
            
          
              1 fork
            
          
              5 comments
            
          
              19 stars
            
          
                echo-dave
                / addSSHKeys.md
            
            
              Last active
              March 18, 2024 19:43
            
              
                Mac OS: Load SSH keys on login / restart
              
          
    Help my SSH keys are unavailable after restart

I'm still not sure what but on both my systems my keys just don't get loaded back into the ssh-agent on restarts and new login sessions. I got annoyed enough at it that I jumped through the hoops of putting ssh-add into a script and writting a property list file to load as a launchagent to fix it.
Add SSH Keys

If you haven't done so already you can use the well written gub hub instructions for generating ssh keys. Once you get them generated you'll add them with ssh-add -K <sshkey> where sshkey is the file path/name. Keys are stored by default in your ~/.ssh folder
Update

Note that you may need to use ssh-add --apple-use-keychain in Big Sur onward instead of ssh-add -K. I discovered the issue in Montery after skipping Big Sur.
Manual reloading SSH keys

The manual method (assuming your keys were stored into the Mac OS Keychain) is to open up Terminal

  
## command.sh
# Here a few bash one-liners that helped me analyze / fight a weak DOS attack against debuggable.com. Mostly for future reference.
# The attacker was opening lots of tcp connections without sending data, I believe it's called a SYN flood, see: http://tools.ietf.org/html/rfc4987#section-3.2

# Step 0: Check what is going on at port 80
$ netstat -tan | grep ':80 ' | awk '{print $6}' | sort | uniq -c

# Step 1: Increase the number of available fds
$ ulimit -n 32000

# Step 2: Restart your webserver, for me:

## BoomerangVelvetMetrics.html
<!DOCTYPE html>
<html>
<head>
    <title>Velvet test with BOOMR</title>
</head>
<body>
<h1>Testing roundtrip time</h1>
<p>Using <a href="http://developer.yahoo.com/blogs/ydn/posts/2010/06/performance_testing_with_boomerang/">Boomerang</a> and <a href="http://www.velvetmetrics.com/">velvetmetrics</a></p>
<p id="results"></p>
<img src="http://www.velvetmetrics.com/chart?&path=random.path.3yb8s&groupBy=10min&f=avg&datapoints=true&title=true&axes=true&legends=true&customtitle=Avg%20roundtrip%20time%20/10%20mins&w=600&h=250&output=image&rand=2612" alt="loadtime history"/>
	# Here a few bash one-liners that helped me analyze / fight a weak DOS attack against debuggable.com. Mostly for future reference.
	# The attacker was opening lots of tcp connections without sending data, I believe it's called a SYN flood, see: http://tools.ietf.org/html/rfc4987#section-3.2

	# Step 0: Check what is going on at port 80
	$ netstat -tan \| grep ':80 ' \| awk '{print $6}' \| sort \| uniq -c

	# Step 1: Increase the number of available fds
	$ ulimit -n 32000

	# Step 2: Restart your webserver, for me:
	<!DOCTYPE html>
	<html>
	<head>
	<title>Velvet test with BOOMR</title>
	</head>
	<body>
	<h1>Testing roundtrip time</h1>
	<p>Using <a href="http://developer.yahoo.com/blogs/ydn/posts/2010/06/performance_testing_with_boomerang/">Boomerang</a> and <a href="http://www.velvetmetrics.com/">velvetmetrics</a></p>
	<p id="results"></p>
	<img src="http://www.velvetmetrics.com/chart?&path=random.path.3yb8s&groupBy=10min&f=avg&datapoints=true&title=true&axes=true&legends=true&customtitle=Avg%20roundtrip%20time%20/10%20mins&w=600&h=250&output=image&rand=2612" alt="loadtime history"/>