Create an SSH key. If you don't have an SSH key pair, open a bash shell or the command line and type in: ssh-keygen -t rsa -b 2048. This will generate the SSH key. Press Enter at the following prompt to save the key in the default location (under your user directory as a folder named.ssh). To support RSA key-based authentication, take one of the following actions: Install an ssh that uses the DES-EDE3-CBC cipher. Install the RXA 2.3.0.9 package in your environment. RXA 2.3.0.9 supports the AES-128-CBC cipher. 16 hours ago This time ssh-rsa term confuse me a lot. I have old RSA public key, for instance it worked to authorize my openssh client against Debian 10, Debian 8 and Cisco 4k router. After upgrade I have to add PubkeyAcceptedKeyTypes +ssh-rsa to.ssh/config for most of older hosts, in this case it would be Debian 8 and Cisco 4k router. Now I can log in. SSH clients will typically use /.ssh/identity (ssh v1) or one of/.ssh/idrsa or /.ssh/iddsa (v2) as the default private key. You can change this in /.ssh/config (the IdentityFile parameter - the -i option to SSH actually overrides this. See man sshconfig for details). If you have multiple private keys to deal with using ssh-agent is probably a better choice.
OpenSSH 8.6 is now available. The 'ssh-rsa' signature scheme, which usesthe SHA-1 hash algorithm, will be disabled by default in the nearfuture. 'Note that the deactivation of 'ssh-rsa' signatures does notnecessarily require cessation of use for RSA keys. In the SSH protocol,keys may be capable of signing using multiple algorithms. In particular,'ssh-rsa' keys are capable of signing using 'rsa-sha2-256' (RSA/SHA256),'rsa-sha2-512' (RSA/SHA512) and 'ssh-rsa' (RSA/SHA1). Only the last ofthese is being turned off by default.'From: | Damien Miller <djm-AT-cvs.openbsd.org> |
To: | lwn-AT-lwn.net |
Subject: | Announce: OpenSSH 8.6 released |
Date: | Sun, 18 Apr 2021 18:53:14 -0600 |
Message-ID: | <[email protected]> |
OpenSSH 8.6 released
Posted Apr 20, 2021 7:14 UTC (Tue) by wtarreau (subscriber, #51152) [Link]
The incessant switch between algorithms is a real pain. Initially we were all using RSA. Then we were told RSA was bad and that DSA had to be used instead. We all switched to DSA. Then DSA was deamed bad forcing many of us to turn back to RSA after facing connection issues on their machines, but with larger keys this time. Then ED25519 started to appear but is still not enabled on a wide number of already installed machines (typically the machines we have in our respective basements). Now RSA's dead again..SSH is widely used to connect, but not only where extreme security is required, simply where you need to connect (i.e. the old server on your local network, where it replaced telnet+ftp). In such situations removing support for algorithms breaks the connectivity, makes backups fail, and causes lots of grief. I think that clients should not completely remove support for no-so-old algorithm but instead require an extra option like '--insecure' or something like this. Because clearly if I can't connect anymore to some of my old machines, I'll go back to telnet, which never broke accessibility in 40 years. And I do think that SSH is better than telnet, even with older keys that a neighbor could fake for $50k to intercept my connection on my local network just to send me a 'you're pwned' banner when I connect..
OpenSSH 8.6 released
Ssh config user. Posted Apr 20, 2021 7:39 UTC (Tue) by cjwatson (subscriber, #7322) [Link]
No, RSA is not dead. There is a warning (which has been in the OpenSSH release notes for several releases, so I don't know why LWN picked it for a pull quote) that a particular signature scheme used with RSA is deprecated, but RSA keys will still work just fine even after that scheme is eventually removed.
OpenSSH 8.6 released
Posted Apr 20, 2021 8:21 UTC (Tue) by Sesse (subscriber, #53779) [Link]
RSA keys yes, but that isn't the problem: SSHing to your switch, where you cannot change the sshd implementation, is. (Keys can, after all, be replaced pretty easily!) This is a huge pain, and has only been accelerating in the last decade.Unable to negotiate with <ip> port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
I sometimes keep a machine on oldstable or oldoldstable around, so that I can have an older ssh(1) binary to SSH to stuff with…
OpenSSH 8.6 released
Posted Apr 20, 2021 9:20 UTC (Tue) by dottedmag (subscriber, #18590) [Link]
ssh -oKexAlgorithms=diffie-hellman-group-exchange-sha1 oldbox?
OpenSSH 8.6 released
Posted Apr 20, 2021 9:32 UTC (Tue) by Sesse (subscriber, #53779) [Link]
Works for that case, yes, but not for all others. E.g. I have devices that only accept SSHv1. Terribly insecure, yes, but the real alternative is telnet.
OpenSSH 8.6 released
Posted Apr 20, 2021 10:38 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Just build a 'crapssh' utility then, it's pretty easy to do that using old sources of OpenSSH.
OpenSSH 8.6 released
Posted Apr 20, 2021 8:41 UTC (Tue) by Vipketsh (guest, #134480) [Link]
A better example is some old(er) networking equipment, like a managed switch. These things are often disowned by their manufacturers so no hope to getting any update with more recent authentication schemes but the equipment works perfectly well for its intended function. I would be happy if they disabled rsa-ssh on the server and put it into some last-resort-fallback list on the client when negotiating the scheme.It would be great if security people today would understand that security is a function of *three* things: Confidentiality, Integrity and *Availability*. Clearly availability is being reduced here for no gain in Integrity.
OpenSSH 8.6 released
Posted Apr 20, 2021 10:14 UTC (Tue) by hkario (subscriber, #94864) [Link]
> Clearly availability is being reduced here for no gain in Integrity.That's your opinion, not shared by wider security community.
Look for SSH Downgrade Attacks to learn why.
OpenSSH 8.6 released
Posted Apr 20, 2021 10:43 UTC (Tue) by pizza (subscriber, #46) [Link]
> That's your opinion, not shared by wider security community.> Look for SSH Downgrade Attacks to learn why.
Sure, and the net result of this 'improved security' is 'SSH downgrade to telnet'
Mission accomplished, I guess.
OpenSSH 8.6 released
Posted Apr 20, 2021 11:04 UTC (Tue) by hkario (subscriber, #94864) [Link]
First, count number of people that use SSH daily with modern ciphers and count how many people need to use long insecure protocols like SSHv1.Second, you aren't secure with SSHv1, at least with telnet you're not lying to yourself that you are. So there's a chance that you'll do something about it. That is improved security: real, not apparent.
OpenSSH 8.6 released
Posted Apr 20, 2021 11:32 UTC (Tue) by pizza (subscriber, #46) [Link]
> That is improved security: real, not apparent.What is 'real, improved' over dropping the barrier of attack from $50K to $0?
At $50K, you're only going to be vulnerable to larger criminal enterprises and nation-states that are specifically going after _you_. But at $0 you're open to every script kiddie on the internet with a copy of nmap.
Your argument is equivalent to getting rid of the front doors on houses because they're easy to open.
OpenSSH 8.6 released
Posted Apr 20, 2021 11:40 UTC (Tue) by hkario (subscriber, #94864) [Link]
OpenSSH 8.6 released
Posted Apr 22, 2021 17:39 UTC (Thu) by jschrod (subscriber, #1646) [Link]
No, you don't understand him.It seems that there are a lot of ssh use cases that you haven't experienced yet, especially in the network devices realm.
OpenSSH 8.6 released
Posted Apr 20, 2021 15:03 UTC (Tue) by foom (subscriber, #14868) [Link]
If you have a device that's so old it only runs sshv1 -- which presumably means it hasn't been updated in 20 years -- does it really matter what protocol you use to connect to it?It's there any chance it isn't exploitable via some well known security vulnerabilities? Quite possibly even ones which have been nicely packaged into a one-click exploit toolkit, and a may be just as easy to 'login' with as an ssh client..
OpenSSH 8.6 released
Posted Apr 20, 2021 14:03 UTC (Tue) by epa (subscriber, #39769) [Link]
I once patched ssh 1.x to add a 'none' cipher, sending data over the wire unencrypted. That helped get usable performance on a 16MHz 386SX. I'd much rather run ssh and sshd, even without encryption, than go back to telnet.
OpenSSH 8.6 released
Posted Apr 20, 2021 16:53 UTC (Tue) by Vipketsh (guest, #134480) [Link]
Disabling the weak algorithm on the server thwarts the downgrade attack, from what I understand (no expert though so feel free to correct me). It then doesn't make sense to disabled it on the client side.
OpenSSH 8.6 released
Posted Apr 20, 2021 12:21 UTC (Tue) by pabs (subscriber, #43278) [Link]
Do these switches not support standard Linux distros?
![Ssh Config Rsa Key Ssh Config Rsa Key](/uploads/1/3/5/1/135121743/333917065.png)
OpenSSH 8.6 released
Posted Apr 20, 2021 16:55 UTC (Tue) by floppus (subscriber, #137245) [Link]
For $WORK we needed an inexpensive router with high IPSec throughput, and the option we settled on was a Mikrotik box, which runs some form of Linux but the crypto offload hardware is proprietary.Even when it comes to standard distros, though, dropbear added support for Ed25519 and RSA+SHA-2 only very recently, so those aren't yet supported in stable OpenWRT.
OpenSSH 8.6 released
Posted Apr 22, 2021 20:30 UTC (Thu) by Sesse (subscriber, #53779) [Link]
Why do you believe they are running Linux in the first place?
OpenSSH 8.6 released
Posted Apr 22, 2021 20:32 UTC (Thu) by pabs (subscriber, #43278) [Link]
I was asking about what they *can* run rather than what they ship with.
OpenSSH 8.6 released
Posted Apr 22, 2021 20:36 UTC (Thu) by Sesse (subscriber, #53779) [Link]
They can run firmware images signed by the vendor, using their proprietary OS, period. They can not run Linux, there is no effort underway to port Linux to them, the hardware (which is custom, highly nontrivial, and intertwined with the software) is not documented, and to be honest, I don't think I'd want Linux on them either.
OpenSSH 8.6 released
Posted Apr 22, 2021 21:00 UTC (Thu) by pabs (subscriber, #43278) [Link]
There are folks trying to change this, here are a few of the Debian derivatives I know about, I think they mostly do enterprise stuff though:https://wiki.debian.org/Derivatives/Census/VyOS
https://wiki.debian.org/Derivatives/Census/DANOS
https://wiki.debian.org/Derivatives/Census/CumulusLinux
https://wiki.debian.org/Derivatives/Census/OpenNetworkLinux
https://wiki.debian.org/Derivatives/Census/DANOS
https://wiki.debian.org/Derivatives/Census/CumulusLinux
https://wiki.debian.org/Derivatives/Census/OpenNetworkLinux
OpenSSH 8.6 released
Posted Apr 20, 2021 13:32 UTC (Tue) by itvirta (guest, #49997) [Link]
Removing things from the enabled-by-default list doesn't prevent enabling them when needing to talk to ancientequipment. It wasn't too long ago I used something like 'ssh -c3des' (or even 'ssh -1') to connect to some such
relic. Per-host settings for Ciphers, Protocol, KexAlgorithms and such in '.ssh/config' also help if you need to do
that often.
The problem is downgrades that can happen automatically, within the the default-enabled settings.
(And downgrading to telnet probably doesn't fit there.)
(And downgrading to telnet probably doesn't fit there.)
OpenSSH 8.6 released
Posted Apr 20, 2021 18:54 UTC (Tue) by lamikr (subscriber, #2289) [Link]
If I create the ca.key and pem file with OpenSSL 1.1.1k which I believe is the latest release by using typical command shown in many examples: openssl req -new -x509 -keyout ca.key -out ca.pem -days 45 -config ./ca.cnf
and then check the cipher used with command:
openssl asn1parse -in ca.key
From the output I can see that the des is still used as a cipher:
64:d=4 hl=2 l= 8 prim: OBJECT :des-ede3-cbc
Shouldn't openssl use something more secure by default?
OpenSSH 8.6 released
Posted Apr 20, 2021 19:41 UTC (Tue) by tamiko (subscriber, #115350) [Link]
> Shouldn't openssl use something more secure by default?It should. But this is entirely orthogonal to openssh changing it's default-enabled cipher set.
OpenSSH 8.6 released
Posted Apr 22, 2021 17:42 UTC (Thu) by jschrod (subscriber, #1646) [Link]
The topic here is complete removal, not removal from the enabled-by-default list.
OpenSSH 8.6 released
Posted Apr 22, 2021 10:30 UTC (Thu) by jezuch (subscriber, #52988) [Link]
Doing something once every couple of years does not strike me as 'incessant', and moaning about this particular one strikes me as denying reality. The reality of security is that the attacks only get better and time is *not* your friend. Thus key rotation should be routine, not an inconvenient thing you're forced to by external events.What is sad is that the designers of the SSH protocol were also denying this reality. Support for *automatic* key rotation and upgrade should have been designed into the protocol from the start. It is not, so everyone has to do it manually (or automating it themselves) and everyone suffers and security suffers even more. So, in the end, I don't really blame you for moaning.
Obviously I have a couple of decades of hindsight to benefit from so I guess it turns me into a smart-ass at this point :)
OpenSSH 8.6 released
Posted Apr 22, 2021 11:42 UTC (Thu) by pizza (subscriber, #46) [Link]
> Support for *automatic* key rotation and upgrade should have been designed into the protocol from the start.Absolutely!
I'm in a situation where I have a gerrit instance using one of these these problematic host keys (generated back in 2011), mostly hit by tools (ie git) on systems I don't control. I can't replace that problematic key with a stronger one without requiring manual intervention on every single client that hits this thing. Bleh.
OpenSSH 8.6 released
Posted Apr 22, 2021 13:59 UTC (Thu) by grawity (subscriber, #80596) [Link]
I think that clients should not completely remove support for no-so-old algorithm but instead require an extra option like '--insecure' or something like this.
I somewhat agree with this, but, fortunately, OpenSSH isn't the only SSH client for Linux. PuTTY (specifically the '
plink
' command) is actively maintained and has support for everything under the sun, from Ed448 to SUPDUP.Before you begin
Using SSH public key authentication to connect to a remote system is a robust, more secure alternative to logging in with an account password or passphrase. SSH public key authentication relies on asymmetric cryptographic algorithms that generate a pair of separate keys (a key pair), one 'private' and the other 'public'. You keep the private key a secret and store it on the computer you use to connect to the remote system. Conceivably, you can share the public key with anyone without compromising the private key; you store it on the remote system in a
.ssh/authorized_keys
directory.To use SSH public key authentication:
- The remote system must have a version of SSH installed. The information in this document assumes the remote system uses OpenSSH. If the remote system is using a different version of SSH (for example, Tectia SSH), the process outlined below may not be correct.
- The computer you use to connect to the remote server must have a version of SSH installed. This document includes instructions for generating a key pair with command-line SSH on a Linux or macOS computer, and with PuTTY on a Windows computer.
- You need to be able to transfer your public key to the remote system. Therefore, you must either be able to log into the remote system with an established account username and password/passphrase, or have an administrator on the remote system add the public key to the
~/.ssh/authorized_keys
file in your account. - Two-factor authentication using Two-Step Login (Duo) is required for access to the login nodes on IU research supercomputers, and for SCP and SFTP file transfers to those systems. SSH public key authentication remains an option for researchers who submit the 'SSH public key authentication to HPS systems' agreement (log into HPC everywhere using your IU username and passphrase), in which you agree to set a passphrase on your private key when you generate your key pair. If you have questions about how two-factor authentication may impact your workflows, contact the UITS Research Applications and Deep Learning team. For help, see Get started with Two-Step Login (Duo) at IU and Help for Two-Step Login (Duo).
Set up public key authentication using SSH on a Linux or macOS computer
To set up public key authentication using SSH on a Linux or macOS computer:
- Log into the computer you'll use to access the remote host, and then use command-line SSH to generate a key pair using the RSA algorithm.To generate RSA keys, on the command line, enter:
- You will be prompted to supply a filename (for saving the key pair) and a password (for protecting your private key):
- Filename: To accept the default filename (and location) for your key pair, press
Enter
orReturn
without entering a filename.Alternatively, you can enter a filename (for example,my_ssh_key
) at the prompt, and then pressEnter
orReturn
. However, many remote hosts are configured to accept private keys with the default filename and path (~/.ssh/id_rsa
for RSA keys) by default. Consequently, to authenticate with a private key that has a different filename, or one that is not stored in the default location, you must explicitly invoke it either on the SSH command line or in an SSH client configuration file (~/.ssh/config
); see below for instructions. - Password: Enter a password that contains at least five characters, and then press
Enter
orReturn
. If you pressEnter
orReturn
without entering a password, your private key will be generated without password-protection.If you don't password-protect your private key, anyone with access to your computer conceivably can SSH (without being prompted for a password) to your account on any remote system that has the corresponding public key.
Your private key will be generated using the default filename (for example,id_rsa
) or the filename you specified (for example,my_ssh_key
), and stored on your computer in a.ssh
directory off your home directory (for example,~/.ssh/id_rsa
or~/.ssh/my_ssh_key
).The corresponding public key will be generated using the same filename (but with a.pub
extension added) and stored in the same location (for example,~/.ssh/id_rsa.pub
or~/.ssh/my_ssh_key.pub
). - Filename: To accept the default filename (and location) for your key pair, press
- Use SFTP or SCP to copy the public key file (for example,
~/.ssh/id_rsa.pub
) to your account on the remote system (for example,[email protected]
); for example, using command-line SCP:You'll be prompted for your account password. Your public key will be copied to your home directory (and saved with the same filename) on the remote system. - Log into the remote system using your account username and password.If the remote system is not configured to support password-based authentication, you will need to ask system administrators to add your public key to the
~/.ssh/authorized_keys
file in your account (if your account doesn't have~/.ssh/authorized_keys
file, system administrators can create one for you). Once your public key is added to your~/.ssh/authorized_keys
file on the remote system, the setup process is complete, and you should now be able to SSH to your account from the computer that has your private key. - If your account on the remote system doesn't already contain a
~/.ssh/authorized_keys
file, create one; on the command line, enter the following commands:If your account on the remote system already has a~/.ssh/authorized_keys
file, executing these commands will not damage the existing directory or file. - On the remote system, add the contents of your public key file (for example,
~/id_rsa.pub
) to a new line in your~/.ssh/authorized_keys
file; on the command line, enter:You may want to check the contents of~/.ssh/authorized_keys
to make sure your public key was added properly; on the command line, enter: - You may now safely delete the public key file (for example,
~/id_rsa.pub
) from your account on the remote system; on the command line, enter:Alternatively, if you prefer to keep a copy of your public key on the remote system, move it to your.ssh
directory; on the command line, enter: - Optionally, repeat steps 3-7 to add your public key to other remote systems that you want to access from the computer that has your private key using SSH public key authentication.
- You now should be able to SSH to your account on the remote system (for example,
[email protected]
) from the computer (for example,host1
) that has your private key (for example,~/.ssh/id_rsa
):- If your private key is password-protected, the remote system will prompt you for the password or passphrase (your private key password/passphrase is not transmitted to the remote system):
- If your private key is not password-protected, the remote system will place you on the command line in your home directory without prompting you for a password or passphrase:
Wear os deezer. If the private key you're using does not have the default name, or is not stored in the default path (not~/.ssh/id_rsa
), you must explicitly invoke it in one of two ways:- On the SSH command line: Add the
-i
flag and the path to your private key.For example, to invoke the private keyhost2_key
, stored in the~/.ssh/old_keys
directory, when connecting to your account on a remote host (for example,[email protected]
), enter: - In an SSH client configuration file: SSH gets configuration data from the following sources (in this order):
- From command-line options
- From the user's client configuration file (
~/.ssh/config
), if it exists - From the system-wide client configuration file (
/etc/ssh/ssh_config
)
The SSH client configuration file is a text file containing keywords and arguments. Sqlite visual studio code. To specify which private key should be used for connections to a particular remote host, use a text editor to create a~/.ssh/config
that includes theHost
andIdentityFile
keywords.For example, for connections tohost2.somewhere.edu
, to make SSH automatically invoke the private keyhost2_key
, stored in the~/.ssh/old_keys
directory, create a~/.ssh/config
file with these lines included:Once you save the file, SSH will use the specified private key for future connections to that host.You can add multipleHost
andIdentityFile
directives to specify a different private key for each host listed; for example:Alternatively, you can use a single asterisk (*
) to provide global defaults for all hosts (specify one private key for several hosts); for example:For more about the SSH client configuration file, see the OpenSSH SSH client configuration file on the web or from the command line (man ssh_config
).
Set up public key authentication using PuTTY on a Windows 10 or Windows 8.x computer
The PuTTY command-line SSH client, the PuTTYgen key generation utility, the Pageant SSH authentication agent, and the PuTTY SCP and SFTP utilities are packaged together in a Windows installer available under The MIT License for free download from the PuTTY development team.
After installing PuTTY:
Git Config Ssh Key
- Launch PuTTYgen.
- In the 'PuTTY Key Generator' window, under 'Parameters':
- For 'Type of key to generate', select RSA. (In older versions of PuTTYgen, select SSH2-RSA.)
- For 'Number of bits in a generated key', leave the default value (
2048
).
- Under 'Actions', click Generate.
- When prompted, use your mouse (or trackpad) to move your cursor around the blank area under 'Key'; this generates randomness that PuTTYgen uses to generate your key pair.
- When your key pair is generated, PuTTYgen displays the public key in the area under 'Key'. In the 'Key passphrase' and 'Confirm passphrase' text boxes, enter a passphrase to passphrase-protect your private key.If you don't passphrase-protect your private key, anyone with access to your computer will be able to SSH (without being prompted for a passphrase) to your account on any remote system that has the corresponding public key.
- Save your public key:
- Under 'Actions', next to 'Save the generated key', click Save public key.
- Give the file a name (for example,
putty_key
), select a location on your computer to store it, and then click Save.
- Save your private key:
- Under 'Actions', next to 'Save the generated key', click Save private key.If you didn't passphrase-protect your private key, the utility will ask whether you're sure you want to save it without a passphrase. Click Yes to proceed or No to go back and create a passphrase for your private key.
- Keep 'Save as type' set to PuTTY Private Key Files (*.ppk), give the file a name (for example,
putty_private_key
), select a location on your computer to store it, and then click Save. - If you wish to connect to a remote desktop system such as Research Desktop (RED), click Conversions > Export OpenSSH key, give the file a name (for example,
putty_rsa
), select a location on your computer to store it, and then click Save.
- Under 'Actions', next to 'Save the generated key', click Save private key.
- Log into the remote system using your account username and password.If the remote system does not support password-based authentication, you will need to ask system administrators to add your public key to the
~/.ssh/authorized_keys
file in your account (if your account doesn't have~/.ssh/authorized_keys
file, system administrators can create one for you). Once your public key is added to your account's~/.ssh/authorized_keys
file on the remote system.. - If your account on the remote system doesn't already contain a
~/.ssh/authorized_keys
file, create one; on the command line, enter the following commands:If your account on the remote system already has~/.ssh/authorized_keys
, executing these commands will not damage the existing directory or file. - On your computer, in the PuTTYgen utility, copy the contents of the public key (displayed in the area under 'Key') onto your Clipboard. Then, on the remote system, use your favorite text editor to paste it onto a new line in your
~/.ssh/authorized_keys
file, and then save and close the file. - On your computer, open the Pageant SSH authentication agent. This utility runs in the background, so when it opens, you should see its icon displayed in the Windows notification area.
- In the Windows notification area, right-click on the Pageant icon, select Add Key, navigate to the location where you saved your private key (for example,
putty_private_key.ppk
), select the file, and then click Open. - If your private key is passphrase-protected, Pageant will prompt you to enter the passphrase; enter the passphrase for your private key, and then click OK.If your private key is not passphrase-protected, Pageant will add your private key without prompting you for a passphrase.Either way, Pageant stores the unencrypted private key in memory for use by PuTTY when you initiate an SSH session to the remote system that has your public key.
- On your computer, open the PuTTY SSH client:
- On the Session screen:
- Under 'Host Name (or IP address)', enter your username coupled with the hostname of the remote server that has your public key; for example:
- Under 'Connection type', make sure SSH is selected.
- In the 'Category' list on the left, navigate to the Auth screen (Connection > SSH > Auth). On the Auth screen, under 'Authentication methods', select Attempt authentication using Pageant.
- Return to the Session screen, and under 'Saved Sessions', enter a name (for example,
Deathstar
), and then click Save. - Click Open to connect to your account on the remote system. With Pageant running in the background, PuTTY will retrieve the unencrypted private key automatically from Pageant and use it to authenticate. Because Pageant has your private key's passphrase saved (if applicable), the remote system will place you on the command line in your account without prompting you for the passphrase.
Technically, at this point, the setup is complete. In the future, whenever you log into your Windows desktop, you can run Pageant, add the private key, and then use PuTTY to SSH to any remote resource that has your public key. Alternatively, you can create a shortcut in your WindowsStartup
folder to launch Pageant and load your private key automatically whenever you log into your desktop. For instructions, finish the rest of the following steps. - On the Session screen:
- Open your
Startup
folder. PressWin-r
, and in the 'Open' field, typeshell:startup
, and then pressEnter
. - Right-click inside the
Startup
folder, and then select New and Shortcut. - In the 'Type the location of the item' text box, enter the path to the Pageant executable (
pageant.exe
) followed by the path to your private key file (for example,putty_private_key.ppk
); enclose both paths in double quotes; for example: - Click Next, and then, in the 'Type a name for this shortcut' text box, enter a name for the shortcut (for example,
PAGEANT
). - Click Finish.
Ssh Config Rsa Keys
The next time you log into your Windows desktop, Pageant will start automatically, load your private key, and (if applicable) prompt you for the passphrase.