Recently, a SSH client bug was discovered that could let the server read client private keys in some situations.
If you’re affected, then follow these steps. Regular users of SSH may be familiar with the commands used.
If you use public key authentication
If you do use keys to authenticate, you should regenerate them. Start by backing up your old key. Assuming it’s at the default location, just use-
|
|
Next, create or edit ~/.ssh/config
, and add the following line. This disables the roaming feature, which was part of the problem:
|
|
Generate new keys:
|
|
Now copy the new public key over, using the old keys. You would normally use ssh-copy-id
, but it adds keys rather than replacing them, which is why we need to do it manually:
|
|
SSH in with the old key:
|
|
Replace all current authorized keys with the newly generated one:
|
|
Logout, log back in with the new key to make sure it works, and you’re done.
If you don’t use public keys
If you don’t use keys for login, now could be a good time to start. Public-key authentication provides much stronger protection from brute force attacks, and also prevents the need for the server to be sent your password each time you log in.
Create or edit ~/.ssh/config
as above, and make sure it contains this line-
|
|
Generate a keypair and add your public key to the server-
|
|
Test it out:
|
|
At his point, you should disable password-based authentication in OpenSSH server. If you don’t control the server’s SSH configuration, then just set a good random password for your account to prevent it being brute-forced:
|
|
Set it on your account:
|
|
Update 2017-10-22: Updated to correct errors in the commands.