I am able to connect with Putty with my public/private key without being prompted for the passphrase (or password). I have pageant running in the background.
However, trying to connect with plink won't work (form the same windows machine) :(... It is telling me that the key is refused by the server :(.. See the output below.
Any idea why?
C:\Windows\System32>plink -v -agent -i C:\Users\ed\.ssh\id_rsa.pkk ed#bla.nl
Looking up host "bla.nl"
Connecting to 82.94.165.254 port 22
Server version: SSH-2.0-OpenSSH_4.3
Using SSH protocol version 2
We claim version: SSH-2.0-PuTTY_Release_0.62
Doing Diffie-Hellman group exchange
Doing Diffie-Hellman key exchange with hash SHA-1
Host key fingerprint is:
ssh-rsa 2048 83:15:11:84:8f:d8:f9:3a:16:b0:e4:8d:ef:4c:18:c4
Initialised AES-256 SDCTR client->server encryption
Initialised HMAC-SHA1 client->server MAC algorithm
Initialised AES-256 SDCTR server->client encryption
Initialised HMAC-SHA1 server->client MAC algorithm
Reading private key file "C:\Users\ed\.ssh\id_rsa.pkk"
Unable to use this key file (unable to open file)
Unable to use key file "C:\Users\ed\.ssh\id_rsa.pkk" (unable to open file)
Pageant is running. Requesting keys.
Pageant has 1 SSH-2 keys
Using username "ed".
Trying Pageant key #0
Server refused our key
Using SSPI from SECUR32.DLL
Attempting GSSAPI authentication
GSSAPI authentication request refused
ed#bla.nl's password:
The first error message says it's not finding the key file you're trying to pass it. Might the problem be that the name ends in .ppk, not .pkk?
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.
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.
BizTalk sees thumbprint for an internal SFTP test as
ssh-rsa 2048 33:88:f0:ff:63:78:a9:2b:3f:09:cb:05:81:db:59:86
WinSCP shows: ssh-ed25519 256 ff:2e:5e:33:7a:15:de:69:18:cf:82:ae:f0:4e:7b:d2
(when I click "Session", then "Server/Protocol Information")
Is it possible to convert one to the other?
Is it possible to get the ssh-rsa thumbprint from WinSCP, PuTTY or some other tool?
WinSCP uses Ed25519 host key. It's a different key, than the RSA host key used by BizTalk. You cannot convert one to another.
WinSCP defaults to Ed25519 hostkey as that's preferred over RSA. You can only make WinSCP use RSA using raw session settings HostKey.
Alternativelly, if you can connect with SSH terminal (e.g. PuTTY) to the server, use ssh-keygen to display a fingerprint of the RSA host key:
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
(this assumes common *nix server with OpenSSH)
Note that this makes sense only, if you had verified the host key, that the SSH terminal uses, upfront.
See WinSCP FAQ on Where do I get SSH host key fingerprint to authorize the server?, which covers all this.
ssh-rsa 2048 33:88:f0:ff:63:78:a9:2b:3f:09:cb:05:81:db:59:86
and
ssh-ed25519 256 ff:2e:5e:33:7a:15:de:69:18:cf:82:ae:f0:4e:7b:d2
Are same fingerprint types, but different key types (one is RSA and the other ED25519 -- elliptic curve). There is no way one to the other, because they are fingerprints of different keys.
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.
I can't ssh from client "A" to server "B" (but I can from many other ssh clients on the same subnet than "A" - all are *nux machines)
serverA>ssh -v -p PORT user#serverB
OpenSSH_5.3p1 Debian-3ubuntu5, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to serverB [serverB] port PORT.
debug1: Connection established.
debug1: identity file /home/user_A/.ssh/id_rsa type -1
debug1: identity file /home/user_A/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: checking without port identifier
Host key verification failed.
I've already checked these following pts on client A - as server A looks to be the point - :
user_A/.ssh directory permissions : 700 (see man ssh)
user_A/.ssh/known_hosts permissions: 644 (see man ssh)
user_A/.ssh/known_hosts: does NOT content serverB host public key
otherusers/.ssh/known_hosts: does NOT content serverB host public key
I've tried :
deleting known_hosts on server A: same error remains
to empty known_hosts on server A: same error
checking if host key names are matching the ssh server config: ok (HostKey /etc/ssh/ssh_host_rsa_key)
regenerating server B host keys (ssh-keygen -t dsa/rsa -f /etc/ssh/ssh_host_dsa/rsa_key) : same error
ssh -p PORT me#localhost on serverB: it also works as from other ssh clients
So I'm really stacked now ! ssh specialists welcome home.
Thx in advance
Don't understand what exactly I did wrong for this particular server..
What remains "strange" is that destroying "known_hosts" on the client side did not drive to the expected positive effect.
Anyway pls find hereafter what I did manually, quite ugly but works:
Note: This assumes full access to both machines (client and server)
server side : regenerate the 2 pairs of keys (rsa and dsa)
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
client side:
generate a pair of dsa keys (private and public) for the user "foo"
ssh-keygen -t dsa -f /home/foo/.ssh/my_client_key
add this new key to the ssh-agent if running
ssh-add /home/foo/.ssh/my_client_key
add the content of the server ssh_host_rsa_key.pub to the client /home/foo/.ssh/known_hosts, after the IP/port:
[server_ip]:server_port copy/paste here the server public rsa key (ctrl+shift+C/V)
[server_ip]:server_port copy/paste here the server public dsa key (ctrl+shift+C/V)
now back to the server side :
copy/paste the client public key /home/foo/.ssh/my_client_key.pub into /home/bar/.ssh/.authorized_keys in order to allow connection to the user "foo" to connect to "bar" account:
make sure of the path consistency with /etc/ssh/sshd_config to be able tu use the file .authorized_keys :
AuthorizedKeysFile %h/.ssh/.authorized_keys
restart the ssh server
/etc/init.d/ssh restart
client: now the client "foo" can ssh to the user "bar" on the server :
foo#client>$ ssh -p PORT bar#server_ip
Note: in my case, both client and server are running locally within VM's. Do not use these settings for production obviously.
EDIT: Reading a bit more carefully the man ssh pages, it should be possible to get around this in a much proper manner, ref to the man: "The StrictHostKeyChecking option can be used to control logins to machines whose host key is not known or has changed."
I had the same problem, on an embedded system that I have no control over. I think the way I fixed it was to install all of the public keys on both sides, manually.
The problem started with ssh complaining that 'ssh-askpass' wasn't found. The work around for this was to unset the $DISPLAY environment variable (yes, totally obvious). I read somewhere that OpenSSH will try to use ssh-askpass if DISPLAY is set. So I did this
unset DISPLAY
Then I basically got the error message in the OP. So, continuing on, I did everything on this page to create and copy the public key from A to B.
http://knol.google.com/k/how-to-use-ssh-keygen#
I created both an RSA key and DSA key. I guess RSA is older and DSA is newer. (It looks like it was using the RSA key.) Anyways, this didn't solve the problem alone.
Then I tried copying server "B" public key back to client "A"'s known_hosts. And that worked!
From server B, grab
/etc/ssh/ssh_host_rsa_key.pub
Then add the contents of that to
~/.ssh/known_hosts
on client "A", with the IP address of server "B" prepended to the beginning (and one space)
192.168.0.200 ssh-rsa QbJfEdeu4rsgeAAAAAB3Nza.... etc ... ==
A useful debugging tip is to use the -vvv option to ssh to get super verbose output.
For future reference I fixed what I think was the same issue by doing (from the client)
$ ssh-keyscan [HOST-SERVER-IP]
# [HOST-SERVER-IP] SSH-2.0-OpenSSH_6.7
[HOST-SERVER-IP] ssh-rsa AAAAB3NzaC1yc2EAAAADA ... etc ... +Zl
# [HOST-SERVER-IP] SSH-2.0-OpenSSH_6.7
[HOST-SERVER-IP] ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTI ... etc ... +1w=
I then removed everything in ~/.ssh/known_hosts and copy pasted the two keys exactly the way they appeared into ~/.ssh/known_hosts.
I actually copy pasted the ssh-rsa one only at first, because I thought that's what I was using. For some reason that didn't work, when I copy pasted the second key in it worked like a charm. Of note as well that I enabled PasswordAuthentication in my sshd config on the server so as to not worry about keys.