How do admins typically distribute Ansible .pub keys to clients in an early environment? Do they just script that can run ssh-copy-id to multiple machines? I've looked at other forums and users said to use Ansible to distribute keys, but how can you distribute keys if there's not already one on the client? (I'm not that deep into Ansible, I'm just trying to connect the dots) EDIT: I created a inventory file for my lab environment called "inv.ini". Running the command ansible -i inv.ini clients -m ping shot back "Permission Denied" errors for each client within the group. I used ssh-keygen to generate a RSA key for my admin account, and copied them to each client (manually). After this, the above command worked.

How to generate SSHFP records for a Dropbear instance at OpenWrt? I have **dropbearconvert** and **openssh-keygen** installed, but nothing works. Always invalid format or similar errors. There are two host key files available: /etc/dropbear/dropbear_dss_host_key /etc/dropbear/dropbear_rsa_host_key Any ideas how to get a SSHFP record?

The ssh-keygen generates the following output: The key fingerprint is: dd:e7:25:b3:e2:5b:d9:f0:25:28:9d:50:a2:c9:44:97 user@machine The key's randomart image is: +--[ RSA 2048]----+ | .o o.. | | o +Eo | | + . | | . + o | | S o = * o| | . o @.| | . = o| | . o | | o. | +-----------------+ What is the purpose of this image, does it provide any value for the user? Note this is a client (user) key, not a host key.

I'm trying to import an RSA key pair onto an older version of Cisco IOS (16.6.4). That old version seems to only accept PEM-encoded private keys that are encrypted with DES or 3DES. At least, those ciphers are the only options when exporting a key pair generated on IOS:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,AD1E5D9E9F639C34

5Mjt+X9hZ6UCEi12axx6YTf4tvrf4xs61+90/YaGAZPPcL+Tyk2AKtq8jY5kzQxf
...
8K0+Fl8xKFtTdnaiyuN1jKgBg7WcwkmlBAmh3UxrmQ5awuuZUETuiA==
-----END RSA PRIVATE KEY-----

This is a PKCS#1 encrypted, PEM-encoded file. I want to import a generated key pair from my Linux box. I gather I need the file to looks like like the export shown above that is encrypted with either DES or 3DES. Here is my failed attempt. First I generate an unencrypted RSA key pair using OpenSSL 3.4.0:

$ openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:1024 \
	-out key.pem -outpubkey pub.pem
$ cat key.pem
-----BEGIN PRIVATE KEY-----
MIICdAIBADANBgkqhkiG9w0BAQEFAASCAl4wggJaAgEAAoGBAOC7vNjQatCODHKq
...
ImgXjyNR9xs=
-----END PRIVATE KEY-----

It looks like this is a PKCS#8-encoded private key (BEGIN PRIVATE KEY vs BEGIN RSA PRIVATE KEY; also openssl asn1parse shows a structure that identifies this as rsaEncryption and then a binary blob instead of just a dump of the private key material). I read that ssh-keygen can convert PKCS#8 to PKCS#1 and encrypt it. My version of OpenSSH (9.9p1) shows in [ssh-keygen(1)]: > **-Z cipher** > > Specifies the cipher to use for encryption when writing an > OpenSSH-format private key file. The list of available ciphers may > be obtained using "ssh -Q cipher". The default is “aes256-ctr”. So I list all the ciphers SSH knows about:

$ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

Then I try:

$ ssh-keygen -Z 3des-cbc -f key.pem -m pem -p -N foobarbaz
Your identification has been saved with the new passphrase.

However:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,40F4524E862B346BC384C20AEEC89C1C

VhjXes5OMDEfIkSiGWI89v2jZlxiPJ3KpBfhI0fr3d1ffVXvATK6F3K86SFfvikY
...
7K6eCoJ1+LE/e71Nrsm/SW3qcPJIEP3I8+DtwGerw5TYIH2wnFv/J6X6zfnLJjDn
-----END RSA PRIVATE KEY-----

It says it encrypted it with AES-128-CBC, despite being told to use 3des-cbc (and despite the manual saying that aes-256-ctr is the default). Whatever available cipher I put in from ssh -Q cipher, it will always output a file with AES-128-CBC. Where am I going wrong or what am I overlooking? ## Edit Reading closer, I just noticed the manual says > Specifies the cipher to use for encryption when writing an > **OpenSSH-format** private key file. And indeed:

$ ssh-keygen -Z 3des-cbc -p -N foobarbaz -f priv.key
$ tail -n +2 priv.key | head -n -1 | base64 -d | xxd -l 32
00000000: 6f70 656e 7373 682d 6b65 792d 7631 0000  openssh-key-v1..
00000010: 0000 0833 6465 732d 6362 6300 0000 0662  ...3des-cbc....b

So it uses AES-128-CBC when converting to PEM, but respects the -Z switch when using its own format. ## New Question Then the question becomes: what tool can I use to encrypt my private RSA key with 3DES?

Popular methods of adding an ssh public key to a remote host’s authorized_keys file include using the ssh-copy-id command, and using bash operators such as >> to append to the file. An issue with ssh-copy-id is that this command does not check if a key already exists. This creates a hassle for scripts and automation because subsequent runs can add duplicate key entries. so I am using the following script ( on rhel server version 7.8 ) more /tmp/test.sh #!/bin/bash PUB_KEY= cat /root/.ssh/id_rsa.pub grep -q -F \"$PUB_KEY\" ~/.ssh/authorized_keys 2>/dev/null || echo \"$PUB_KEY\" >> ~/.ssh/authorized_keys I an not sure if this is the best approach , so I will appreciate to get other ideas out of the box*

I am trying to generate SSH key using FIDO2 HW token (GoTrust Idem Key, USB-A) connected with command:

ssh-keygen -O no-touch-required -t ed25519-sk -vvv

and it fails with following error:

Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug3: start_helper: started pid=4683
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: start_helper: starting /usr/lib/ssh/ssh-sk-helper 
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", userid "(null)", flags 0x00, challenge len 0
debug1: sshsk_enroll: using random challenge
debug1: sk_probe: 1 device(s) detected
debug1: sk_probe: selecting sk by touch
debug1: ssh_sk_enroll: using device /dev/hidraw0
debug1: ssh_sk_enroll: fido_dev_make_cred: FIDO_ERR_UNSUPPORTED_ALGORITHM
debug1: sshsk_enroll: provider "internal" failure -2
debug1: ssh-sk-helper: Enrollment failed: requested feature not supported
debug1: main: reply len 8
debug3: ssh_msg_send: type 5
debug1: client_converse: helper returned error -59
debug3: reap_helper: pid=4683
Key enrollment failed: requested feature not supported

I tried upgrading my system (Manjaro Linux, SSH version OpenSSH_9.1p1, OpenSSL 3.0.7 1 Nov 2022), but this did not solved it. I found [this issue](https://github.com/google/OpenSK/issues/90) , [this thread](https://askubuntu.com/questions/1364440/cant-generate-ssh-ed25519-sk-key) and [official manual](https://gotrustid.com/download/idemkey_docs/how_to_use_ssh_with_IdemKey.pdf) (which does not mention ed25519-sk keys, only ecdsa-sk), but I am unable to create ed25519-sk key. Has anybody found anything, which could help me solve it, or prove me, that I want something impossible? **Note**: Generation of ecdsa-sk was successful (running ssh-keygen -O no-touch-required -t ecdsa-sk), so I am using it for now.

I have a situation where a program requires to open an additional SSH login session to its own SERVER. For example - I have a server with IP 10.100.1.100 and when I run the said script it tries to ssh 10.100.1.100 with the same user which prompts for password. I want to escape the said prompt. I tried using the following steps however I am unable to successfully configure the same. Server - LINUX RHEL 1. ssh-keygen -t rsa 2. mkdir ~/.ssh/authorized_keys 3. cp ~/.sshid_rsa.pub ~/.ssh/authorized_keys 4. chmod -R 700 ~/.ssh 5. chmod -R 600 ~/.ssh/authorized_keys

I have an automated process that regularly SSHes to about 120 different machines over a VPN. Occasionally these machines switch IP addresses and use addresses that were previously used by different machines. This causes problems with host key checking when logging in via SSH. To circumvent this, the process runs ssh-keygen -R to remove the host key from *known_hosts* prior to accessing each machine via SSH. Unfortunately, each time this command runs, it seems to create a backup file of *known_hosts* named *known_hosts.ABCDEFGH* where "ABCDEFGH" is a random sequence of letters. Recently I discovered approximately 750,000 of these backup files, taking up 34GB of hard drive space, on the server that runs the automated process. Short of removing *known_hosts.\** each time I run ssh-keygen, is there a way to prevent this build-up of files? I.e. is there a way to prevent ssh-keygen from backing up the *known_hosts* file when it modifies it? I've noticed this behavior on both Ubuntu 22.04 and on MacOS 13.6.6.

I am trying to add a public key to a server but I don't want to restart the sshd service for it to take effect. The reason is that restarting the ssh service seems to be disruptive for other users who could use the ssh service at that time. Most documentation suggest to add a public key to $HOME/.ssh/authorized_keys and then to restart the sshd service (systemctl restart sshd). The OS of interest is Linux. My questions are: 1. Is the restart of sshd needed? 2. If sshd is restarted, is there a service outage at that time? 3. Is there a way to set up passwordless auth using ssh without needing to restart the sshd service after adding new public keys to $HOME/.ssh/authorized_keys?

(note this question uses both 'openssh' and 'openssl' in the text, I am not confusing the two.) If I use openssh to general an RSA keypair (ssh-keygen) then I can use 'openssl rsa -in ...' to view the key parameters (modulus, exponents, primes etc). If I generate an RSA key but store it using the openssh format (using the -o option to ssh-keygen) I cannot directly read that file by openssl. I first use ssh-keygen -p -f and remove the password. The resulting file is an "RSA PRIVATE KEY". Then I can proceed in the usual way with openssl to view the parameters. Using openssl's 'ec' and 'ecparam' commands I can generate files and view the parameters that make up EC keys. If I generate an ed25519 keypair using ssh-keygen -t ed25519 I get a file of the format "OPENSSH PRIVATE KEY". Obviously if I use 'ssh-keygen -p ...' as above on this file I'm never going to get an 'RSA' output because its not an RSA key. So how can I get my "OPENSSH PRIVATE KEY" file generated by ssh-keygen using ed25519 into a format such that I can see the parameters? openssl EC commands produce files such as "BEGIN EC PARAMETERS" and "BEGIN EC PRIVATE KEY". So is there a method to see the ed25519 parameters in the OPENSSH PRIVATE KEY? or a method to turn that file format into one of the EC formats that openssl understands?

Question in the title, but let me detail more. Excluding the ID/Password method on git CLI, we generate a SSH key and add the public key to the remote server. Why don't we have SSH-less public-key cryptography methods? We are not even connecting to remote a machine's terminal, we don't even need to connect a remote machine's terminal (do we?), so why is it named as SSH key? Is it just about naming convention, or something else? What is the history behind that?

The man page for ssh-keygen on my system (Fedora 35) says that the following types of keys are supported: -t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa Specifies the type of key to create. The possible values are “dsa”, “ecdsa”, “ecdsa-sk”, “ed25519”, “ed25519-sk”, or “rsa”. Is there a way to consult this list at runtime, by passing some special flags to ssh-keygen or some other script? Or is this list of types hardcoded and only specified in this man page? The reason I ask this is that I want to teach my shell how to autocomplete the -t parameter.

I am trying to setup *SSH key based login* from server A to server B. I ran ssh-keygen on server A and used ssh-copy-id to copy the id_rsa.pub to server B. When I try to ssh user@serverB from server A, I keep getting the error: Permission denied (publickey). I have double checked my /etc/ssh/sshd_config file to make sure everything is setup correctly. Also have SELinux disabled on both servers. Any idea what could be causing this problem.

Is there an easy way to generate hashed hostnames to be added to the ~/.ssh/known_hosts file? I'd like to add a @cert-authority line to the ~/.ssh/known_hosts file. Obviously the ssh-keygen command would not get the CA cert.  I think it also needs a connection to the server, and I'm not sure I can get it to hash a wildcard. So, how would I hash "*.bar.com", for example, so that it can be used in the ~/.ssh/known_hosts file? **Edit**: Having thought about it, hashed wildcards probably can't work, as it would be too difficult for the client to match a wildcard after it has been hashed. But, if I can still get a method to hash a domain without requiring a connection to the server (as ssh-keygen does), that would be great.

In the **server** exists in the /etc/ssh/ directory files such as: ssh_hosts_rsa_key.pub ssh_hosts_ecdsa_key.pub ssh_hosts_ed25519_key.pub They contain the public keys according with a key type, such as rsa, ecdsa etc If in the **client** are executed the following commands: # Retrieve and Show all the public keys content ssh-keyscan 192.168.1.X # Retrieve all the public keys content and Show the fingerprint of them ssh-keyscan 192.168.1.X | ssh-keygen -lf - The outputs are the public keys and fingerprint respectively ### Observation * The data shown through the ssh-keyscan command comes from the files available in the /etc/ssh directory located in the server ### Concern * I read in the web that the server could be replaced by one fake OR the communication between the client/server can be intercepted and therefore compromised So therefore even is if executed the following command: ssh-keyscan [-H] 192.168.1.X >> ~/home//public_keys Where public_keys is a custom file just to keep the data received from the server and do later a verification/analysis. So ... **Question** * How confirm that the _public keys_ asked and received through the ssh-keygen command are really authentic? The purpose is avoid execute ssh-keyscan [-H] 192.168.1.X >> ~/.ssh/known_hosts and add tainted data in the ~/.ssh/known_hosts file, and finally send crucial data to a fake destination, starting with the _public key_ of the client itself. I thought the admin in the server would share to the client these .pub files, it through * by email * by a ftp access and thus the client can: * use the mentioned public_keys file to do a simple comparison with content of the .pub files. Should be equal * use the ssh-keygen command with the -lvf options to generate the fingerprint directly of the .pub files and do a quick comparison against ssh-keyscan 192.168.1.X | ssh-keygen -lf - command. Should be equal too It would be the most obvious approach at a first glance, it perhaps for a "small" LAN/WAN would have sense, but assuming the admin don't want share these files due of any policy ... how to answer my question? - Of course the other worst scenario is if the admin's email/ftp was compromised too.

I need to add a check if the hostname is already present in the known_hosts file. Normally I would do something like that: ssh-keygen -H -F hostname However, that does not seem to work for me in this particular case. I connect to the host using port 2102, like that: ssh user@myhost -p 2102 I was asked to add the hostname to the known_hosts file, I say yes. After that I run ssh-keygen -H -F myhost but receive empty result. To make the matter worse, the known_hosts is hashed. That works perfectly with port 22, so if I login to ssh user@myotherhost, save the known host and run ssh-keygen -H -F myotherhost I receive the exact line from the file. So, how can I adjust the command to work with port 2102?

I read this question: * [How do I extract fingerprints from .ssh/known_hosts?](https://superuser.com/questions/529132/how-do-i-extract-fingerprints-from-ssh-known-hosts) The answer is valid, so I tried some variations: ssh-keygen -lf ~/.ssh/known_hosts -F 192.168.1.X ssh-keygen -lvf ~/.ssh/known_hosts -F 192.168.1.X ssh-keygen -E md5 -lvf ~/.ssh/known_hosts -F 192.168.1.X ssh-keygen -E sha256 -lvf ~/.ssh/known_hosts -F 192.168.1.X All work as expected. How an observation: for any command share above, it shows all the _fingerprint_ together based in their own _key types_, such as rsa, ecdsa etc .... I am ok with this, but ... the reason of this post **Question:** * How to execute the ssh-keygen command with a filter for a specific key type? Something similar as the ssh-keyscan has with the -t option, therefore something like: ssh-keygen -lf ~/.ssh/known_hosts -F 192.168.1.X -? rsa ssh-keygen -lf ~/.ssh/known_hosts -F 192.168.1.X -? ecdsa So what could be ?? - I saw the ssh-keygen --help and seems there is no that support.

I have read through a number of sites to no avail. So I need to see if someone else can see what I am doing wrong. I am using ubuntu 18. Here is ssh -v output:

debug1: Found key in /home/leithner/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:5nOs3DjENMsvwbU2jHNE2GOv6u/1L5TyFCgc3zPYNDM /home/leithner/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/leithner/.ssh/id_dsa
debug1: Trying private key: /home/leithner/.ssh/id_ecdsa
debug1: Trying private key: /home/leithner/.ssh/id_ed25519
debug1: Next authentication method: password

ssh with port output:
Host '[elm.pa...]:53999' is known and matches the ECDSA host key.
debug1: Found key in /home/leithner/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:5nOs3DjENMsvwbU2jHNE2GOv6u/1L5TyFCgc3zPYNDM /home/leithner/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/leithner/.ssh/id_dsa
debug1: Trying private key: /home/leithner/.ssh/id_ecdsa
debug1: Trying private key: /home/leithner/.ssh/id_ed25519
debug1: Next authentication method: password

From /var/log/auth.log file:
Aug 19 14:44:55 birch sshd: Accepted publickey for leithner from 129.244.22.126 port 57912 ssh2: RSA SHA256:qLTekbB8a22YWHqRHPZjVSJ0dNEHTSoI3nFN97PEyuc
Aug 19 14:44:55 birch sshd: pam_unix(sshd:session): session opened for user leithner by (uid=0)
Aug 19 14:44:55 birch systemd-logind: New session 38875 of user leithner.
Aug 19 14:45:01 birch CRON: pam_unix(cron:session): session opened for user root by (uid=0)

Aug 19 14:43:44 birch sshd: pam_unix(sshd:session): session closed for user leithner
Aug 19 14:44:55 birch sshd: Accepted publickey for leithner from 129.244.22.126 port 57912 ssh2: RSA SHA256:qLTekbB8a22YWHqRHPZjVSJ0dNEHTSoI3nFN97PEyuc
Aug 19 14:44:55 birch sshd: pam_unix(sshd:session): session opened for user leithner by (uid=0)
Aug 19 14:44:55 birch systemd-logind: New session 38875 of user leithner.
Aug 19 14:45:01 birch CRON: pam_unix(cron:session): session opened for user root by (uid=0)
Aug 19 14:45:01 birch CRON: pam_unix(cron:session): session closed for user root
Aug 19 14:47:25 birch sshd: Received disconnect from 129.244.22.126 port 57912:11: disconnected by user



.ssh directory 
directory permissions are drwx------  2 leithner users  4096 Aug 19 15:27 .ssh

leithner@birch:~/.ssh$ ls -l
total 20
-rw------- 1 leithner users  394 Aug 19 14:43 authorized_keys
-rw------- 1 leithner users   26 Aug 19 15:23 config
-rw------- 1 leithner users 1675 Aug 19 15:26 id_rsa
-rw------- 1 leithner users  396 Aug 19 15:26 id_rsa.pub
-rw------- 1 leithner users  888 Aug 19 15:28 known_hosts

.ssh directory on server
directory permissions on server are: drwx------  2 leithner ppa    4096 Aug 19 14:27  .ssh



leithner@elm:~/.ssh$ ls -l
total 20
-rw------- 1 leithner ppa  396 Aug 19 14:27 authorized_keys
-rw------- 1 leithner ppa   85 Aug 19 14:23 config
-rw------- 1 leithner ppa 1823 Aug 19 13:36 id_rsa
-rw------- 1 leithner ppa  394 Aug 19 13:36 id_rsa.pub
-rw------- 1 leithner ppa 1992 Aug 19 14:20 known_hosts

I created keys with ssh-keygen and copied them to server with ssh-copy-id leithner@elm Ssh is requesting a password instead of using keys. ssh -p 53997 elm leithner@elm's password: Here is the auth.log on server: Aug 22 11:59:03 elm sshd: Authentication refused: bad ownership or modes for directory /home/leithner Aug 22 11:59:12 elm sshd: Accepted password for leithner from 129.244.22.120 port 43340 ssh2 What permissions should my directory be: **Solved: The issues is my home directory was 775 it needs to be 755. drwxr-xr-x 24 leithner ppa 4096 Aug 22 12:55 leithner** Any ideas would be appreciated, I have redone the keys multiple times.

On a remote server I want to create a normal user and ONLY allow access via a key but I do NOT want to create the account with a password first and then disable password access later. In my admin account on the remote server I have done the following:

sudo adduser --disabled-password normaluser

Trying to connect as 'normaluser' is rejected, as desired with: > normaluser@server: Permission denied (publickey) According to adduser man page: > The --disabled-password option will not set a password, but login is still possible (for example with SSH RSA keys). Not being sure how ssh keys should be generated in this instance, I sudo su to the normaluser account and generated keys using ssh-keygen. I've then tried to use the public and the private key file (copied to my local machine) to then ssh into the remote machine as normaluser, specifying the appropriate key file with ssh -i but I am still getting access denied (publickey)

I have a pair of keys generated using: ssh-keygen -t rsa -b 4096 -f ~/.ssh/keys/my_key -C "blah@gmail.com". This yielded 2 files my_key and my_key.pub. Now I need to convert that pair to a .pem key that is *filezilla* compatible (to connect over sftp). I already tried something like ssh-keygen -f my_key -m 'PEM' -e > my_key.pem but *filezilla* kept complaining It doesn't contain a private key. I am running *Ubuntu 22.04 x64*. Please advise.