I'm currently experiencing issues generating a U2F public/private key-pair in the terminal with the following command:
ssh-keygen -t ecdsa-sk -vv
Running this command provides the following error:
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
debug1: start_helper: starting /usr/local/Cellar/openssh/8.3p1/libexec/ssh-sk-helper
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", userid "(null)", flags 0x01, challenge len 0
debug1: sshsk_enroll: using random challenge
debug1: ssh_sk_enroll: using device IOService:/AppleACPIPlatformExpert/PCI0#0/AppleACPIPCI/XHC1#14/XHC1#14000000/HS07#14200000/Yubikey 4 OTP+U2F+CCID#14200000/IOUSBHostInterface#1/AppleUserUSBHostHIDDevice
debug1: ssh_sk_enroll: fido_dev_make_cred: FIDO_ERR_RX
debug1: sshsk_enroll: provider "internal" returned failure -1
debug1: ssh-sk-helper: Enrollment failed: invalid format
debug1: ssh-sk-helper: reply len 8
debug1: client_converse: helper returned error -4
Key enrollment failed: invalid format
I'm running MacOS with the latest version of OpenSSH updated to:
OpenSSH_8.3p1, OpenSSL 1.1.1g 21 Apr 2020
My current version of libfido2 is: 1.4.0 installed via Homebrew.
My Yubikey model is: Yubikey C Nano FIPS
My Yubikey firmware is: 4.4.5
Does anyone know what the origins of this error are? Does the Yubikey FIPS series not support this command?
It appears that the issue causing this problem was an admin password placed on U2F functionality before I ever received the Yubikey from my work. You can't generate a U2F ecdsa-sk public/private keypair with an admin password in place.
Related
I know questions with the same title have been asked many times, but I still think mine may be different.
I have two PCs, win10 and win7, and an ubuntu18.04 server. win10 and win7 can both login the server with a shared private key. win10 and win7 can login each other with the same private key, too. With these settings I did two experiments.
(1) From win7 first ssh to win10, then ssh to ubuntu, with two consecutive simple commands. This one succeeds.
# win7 powershell
ssh userA#win10 -v
ssh userB#ubuntu -v
(2) From win10 first ssh to win7, then ssh to ubuntu.
# win10 powershell
ssh userC#win7 -v
ssh userB#ubuntu -v
Then I got this error in the second step, which asked me to use password instead. The password authentication works fine, by the way.
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\user/.ssh/id_rsa RSA
SHA256:JFf56HHFG6CPHdGaAxtf0SsrzVXoTlLADCN/zD3DQxw agent
debug1: Server accepts key: C:\\Users\\user/.ssh/id_rsa RSA
SHA256:JFf56HHFG6CPHdGaAxtf0SsrzVXoTlLADCN/zD3DQxw agent
sign_and_send_pubkey: signing failed for RSA "C:\\Users\\user/.ssh/id_rsa" from agent: agent refused operation
debug1: Trying private key: C:\\Users\\user/.ssh/id_ecdsa
...
debug1: Next authentication method: password
...
Solutions I have tried:
(1) Modify permission of the private key and keep myself as the only user that has permission.
(2) Modify ~/.ssh/config and sshd_config file for entries such as AllowTcpForwarding, AllowAgentForwading, and comment out the Match Group administrators part.
(3) Restart sshd service on the hosts.
(4) Run ssh-add command to register the key on win7 and win10, and make sure both hosts have a running ssh-agent.
Yet none has fixed the problem.
ssh-keygen -vvvv -t ecdsa-sk -O resident
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator:
debug3: start_helper: started pid=16581
debug3: ssh_msg_send: type 5
debug3: ssh_msg_recv entering
debug1: start_helper: starting /usr/lib/openssh/ssh-sk-helper
debug1: sshsk_enroll: provider "internal", device "(null)", application "ssh:", userid "(null)", flags 0x21, challenge len 0 with-pin
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/hidraw2
debug1: ssh_sk_enroll: fido_dev_make_cred: FIDO_ERR_PIN_AUTH_BLOCKED
debug1: sshsk_enroll: provider "internal" returned failure -1
debug1: ssh-sk-helper: Enrollment failed: invalid format
debug1: ssh-sk-helper: reply len 8
debug3: ssh_msg_send: type 5
debug1: client_converse: helper returned error -4
debug3: reap_helper: pid=16581
Key enrollment failed: invalid format
No one had this error on Google, or at least there are no solutions for that.
What is happening? My yubikey is plugged and I tried to touch it or put the PIN
I got a similar issue but with the debug error FIDO_ERR_PIN_NOT_SET. And that was due to the fact that my FIDO2 pin wasn't set in the Yubikey manager (Applications -> FIDO2)...
So I would assume that your error is due to a locked pin somehow. I would try to change the FIDO2 PIN and/or reset it completely if I were you.
I had similar issue, error was Key enrollment failed: invalid format. I fixed it (on Manjaro) by installing newer version of libfido2 (version 1.12.0-5) and upgrading system, and then this worked:
ssh-keygen -O no-touch-required -t ecdsa-sk -vvv
It printed some info about codes, which was different then previous ones, and I am able to use this key.
So I am using a SSH.Net library to do some stuff from my .Net application to trigger stuff on a remote Mac OS device.
After I changed user's password I managed to break the functionality somehow and system.log shows me the following message:
WARNING: no suitable primes in /etc/ssh/primes
The library itself gives me this message:
An exception of type 'Renci.SshNet.Common.SshAuthenticationException' occurred in Renci.SshNet.dll but was not handled in user code
Additional information: No suitable authentication method found to complete authentication.
SSHD debug gives me this message:
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 9
debug1: inetd sockets after dupping: 5, 5
Connection from 172.16.115.19 port 44670 on 192.168.202.110 port 2222
debug1: Client protocol version 2.0; client software version Renci.SshNet.SshClient.0.0.1
debug1: no match: Renci.SshNet.SshClient.0.0.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug2: fd 5 setting O_NONBLOCK
debug2: Network child is on pid 569
debug1: list_hostkey_types: [preauth]
No supported key exchange algorithms [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: Killing privsep child 569
debug1: audit_event: unhandled event 12
I am guessing this has something to do with the keys that have changed after the password was changed, but I am not 100% sure here.
I am guessing this has something to do with the keys that have changed after the password was changed, but I am not 100% sure here.
No.
No supported key exchange algorithms [preauth]
talks about key exchange algorithms. The log is not complete (-ddd will tell you more) and from older version that is not much verbose in this level. But I can guess your server does not support anymore the method offered by your SSH.Net library.
I would go for upgrading the library in the first place. The second possibility is to allow legacy Kex algorithms on server, such as:
KexAlgorithms curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
in your sshd_config (basically adding diffie-hellman-group1-sha1 and diffie-hellman-group-exchange-sha1 which are not considered as a safe these days!).
Again I have a question about an ssh issue:
On a embedded system (no display, no keyboard) my only login interface was ssh. Telnet is disabled too. (I am currently trying to enable it with only little hope...)
My only interaction at the moment is receiving a ping answer and browsing my shared files via smb://!
ssh's answer is always:
$ ssh -vvvvl root 192.168.0.3
OpenSSH_5.5p1 Debian-4ubuntu4, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.3 [192.168.0.3] port 22.
debug1: Connection established.
debug1: identity file /home/simon/.ssh/id_rsa type -1
debug1: identity file /home/simon/.ssh/id_rsa-cert type -1
debug1: identity file /home/simon/.ssh/id_dsa type -1
debug1: identity file /home/simon/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-8
debug1: match: OpenSSH_4.3p2 Debian-8 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu4
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
But I direct access to the hdd through pulling it out of the device and manipulating files on it while it is connected to another machine.
One of my last steps before I logged off and get locked out was sudo rm /etc/ssh/*host*key* followed by dpkg-reconfigure openssh-server, what failed because dpkg-reconfigure was not found. So I guess the problem is, that the keys are deleted.
My question is now: how can I off-shore create keys and provide them to sshd without running any command on the target system OR how can I make sshd let me log in without having a key?
Thanks for your help if there is any..?!
You can generate a new set of host keys on a handy Linux system as follows:
ssh-keygen -t rsa -b 2048 -f ssh_host_rsa_key
ssh-keygen -t dsa -b 1024 -f ssh_host_dsa_key
When ssh-keygen asks you for a passphrase, hit Enter without typing anything. Host keys must have an empty passphrase.
This creates the following files in your current directory:
ssh_host_rsa_key
ssh_host_rsa_key.pub
ssh_host_dsa_key
ssh_host_dsa_key.pub
You can then mount your device's hard drive and copy these four files into etc/ssh.
Note that when you try to ssh to the system afterwards, your ssh client will complain that the keys are different than expected, and probably refuse to connect. If you're running the OpenSSH client, you can correct this by using ssh-keygen again:
ssh-keygen -R <your_server_hostname>
ssh -vvvvl root 192.168.0.3
should be:
ssh -vvvvl root#192.168.0.3
I don't know if that is just a typo you made while posting on stackoverflow or if you typed it in on the command line.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm trying to set-up SSH connections without password to many servers, using RSA key. It works well for most of them but one is giving me some trouble.
The most common issue I've found in the past is permissions problems on .ssh or authorized_keys on the remote host, but here they seem correct, like this:
drwx------ ~/.ssh
-rw-r--r-- ~/.ssh/authorized_keys
Here is output of ssh -v command to this server (I just changed hostname and IP):
Sun_SSH_1.1.3, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to myhost.mydomain.com [123.123.123.123] port 22.
debug1: Connection established.
debug1: identity file /export/home/webdev1/.ssh/identity type -1
debug1: identity file /export/home/webdev1/.ssh/id_rsa type 1
debug1: identity file /export/home/webdev1/.ssh/id_dsa type -1
debug1: Remote protocol version 1.5, remote software version 1.2.31
debug1: match: 1.2.31 pat 1.2.1*,1.2.2*,1.2.3*
debug1: Local version string SSH-1.5-Sun_SSH_1.1.3
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host 'myhost.mydomain.com' is known and matches the RSA1 host key.
debug1: Found key in /export/home/webdev1/.ssh/known_hosts:6
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Doing password authentication.
I suspect it could be due to the SSH version. Another server which works gives me the following output (remote protocol version 2.0 instead of 1.5):
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3
debug1: match: Sun_SSH_1.1.3 pat Sun_SSH_1.1.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.3
Any clue?
Thanks for your help.
chmod 744 ~/.ssh/authorized_keys
works for me.
Make sure your home directory(/export/home/webdev1) too has 700 permission.
The server may be configured to refuse public-key-based, password-less authentication. I do not know about Sun_SSH, but in OpenSSH (the most prevalent SSH implementation on Linux/*BSD systems) this is a matter of changing some settings in /etc/ssh/sshd_config (options RSAAuthentication for v1 protocol, PubkeyAuthentication for v2).
try just
chmod -R 600 ~/.ssh/
Maybe the group/global read permission is causing an issue.
Maybe your user was locked on the unix box. If you usually login with your own account and then "be" the functional user, if that user has "password login" functionalities enabled but you are not using it, it may be locked (password expired for example).
Howerver, even if it is locket it will not prevent you from sudo it with the "be" command, but it will definitly prevent any ssh login even if the keys are trusted.