ssh host key verification failed on one of the clients only - ssh

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.

Related

Should the ssh fingerprint change when the sshd port changes

After changing the sshd port in OpenSSH 8.2, I found that the ssh fingerprint changed. This surprised me since I had assumed it was just dependent on the public key.
What does the fingerprint depend on? Is the port part of it?
On closer examination it looks like the key changed from ssh-rsa to ecdsa-sha2-nistp256. It looks like the server has multiple key files. What determines which key is used and what might have caused a change?
I haven't found the official documentation, but ran into a similar confusion so just experimented a bit.
The hostnames in fingerprints (in .ssh/known_hosts) are hashed, but you can check them with ssh-keygen -H -F 'remote' (you'd see Host remote found...)
It seems that if you're using the default port (22), when you run ssh remote the first time, the fingerprint will only contain the hostname.
You can check this with ssh-keygen -H -F 'remote' (you'd see Host remote found...)
Now, if you change the sshd port on remote (say, to 1234), seems that ssh is still happy with it, because it tries matching against the hostname without the port.
You can see that with the -v flag:
$ ssh -v remote -p 1234
debug1: Authenticating to remote:1234 as 'user'
...
debug1: checking without port identifier
debug1: Host 'remote' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:11
However -- if the first time you ssh onto remote is with a custom port (ssh remote -p 1234), then it seems to remember the hostname with port:
ssh-keygen -H -F 'remote' -- doesn't result in anything
ssh-keygen -H -F '[remote]:1234' -- results in a match
The ssh output changes slightly too, it's checking both host and port now:
$ ssh -v remote -p 1234
...
debug1: Host '[remote]:1234' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:12
...
Now if you change the remote sshd port to something else, say back to 22, and run ssh remote, ssh won't be able to verify the host, because it only knows about [remote]:1234, not remote.
(I guess in theory it could still check all 65535 ports against .ssh/known_hosts and give a friendlier error message).
Regarding the key choice: same -v flag might be helpful here:
...
debug1: Will attempt key: /home/user/.ssh/id_rsa RSA <redacted> agent
debug1: Will attempt key: /home/user/.ssh/id_dsa
debug1: Will attempt key: /home/user/.ssh/id_ecdsa
debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/user/.ssh/id_ed25519
debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/user/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<redacted>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa RSA <redacted> agent
debug1: Server accepts key: /home/user/.ssh/id_rsa RSA <redacted> agent
...

"Failed to connect to the host via ssh: Permission denied (publickey).", [duplicate]

I generate a ssh key pair on my mac and add the public key to my ubuntu server(in fact, it is a virtual machine on my mac),but when I try to login the ubuntu server,it says:
###########################################################
# WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0644 for '/Users/tudouya/.ssh/vm/vm_id_rsa.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /Users/tudouya/.ssh/vm/vm_id_rsa.pub
Permission denied (publickey,password).
I have tried many ways to solve this, change the key file mode, change the folder mode,as some answer on stackoverflow,but it doesn't work.
the key file permission:
vm dir:
drwxr-xr-x 4 tudouya staff 136 4 29 10:37 vm
key file:
-rw------- 1 tudouya staff 1679 4 29 10:30 vm_id_rsa
-rw-r--r-- 1 tudouya staff 391 4 29 10:30 vm_id_rsa.pub
please give me some idea...
=========================================
I write the host infomation to ssh_config:
Host ubuntuvm
Hostname 10.211.55.17
PreferredAuthentications publickey
IdentityFile /Users/tudouya/.ssh/vm/vm_id_rsa.pub
I run command "ssh -v ubuntuvm",it displays:
ssh -v ubuntuvm
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 103: Applying options for *
debug1: /etc/ssh_config line 175: Applying options for ubuntuvm
debug1: Connecting to 10.211.55.17 [10.211.55.17] port 22.
debug1: Connection established.
debug1: identity file /Users/tudouya/.ssh/vm/vm_id_rsa.pub type 1
debug1: identity file /Users/tudouya/.ssh/vm/vm_id_rsa.pub-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-8
debug1: match: OpenSSH_6.6.1p1 Ubuntu-8 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm#openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm#openssh.com 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: Server host key: RSA 55:6d:4f:0f:23:51:ac:8e:70:01:ec:0e:62:9e:1c:10
debug1: Host '10.211.55.17' is known and matches the RSA host key.
debug1: Found key in /Users/tudouya/.ssh/known_hosts:54
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/tudouya/.ssh/vm/vm_id_rsa.pub
debug1: Server accepts key: pkalg ssh-rsa blen 279
###########################################################
# WARNING: UNPROTECTED PRIVATE KEY FILE! #
###########################################################
Permissions 0644 for '/Users/tudouya/.ssh/vm/vm_id_rsa.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /Users/tudouya/.ssh/vm/vm_id_rsa.pub
debug1: No more authentication methods to try.
Permission denied (publickey,password).
I suggest you to do:
chmod 400 ~/.ssh/id_rsa
It works fine for me.
debug1: identity file /Users/tudouya/.ssh/vm/vm_id_rsa.pub type 1
It appears that you're trying to use the wrong key file. The file with the ".pub" extension contains the public portion of the key. The corresponding file without the ".pub" extension contains the private part of the key. When you run an ssh client to connect to a remote server, you have to provide the private key file to the ssh client.
You probably have a line in the your .ssh/config file (or /etc/ssh_config) which looks like this:
IdentityFile .../.ssh/vm/vm_id_rsa.pub
You need to remove the ".pub" extension from the filename:
IdentityFile .../.ssh/vm/vm_id_rsa
Key should be readable by the logged in user.
Try this:
chmod 400 ~/.ssh/Key file
chmod 400 ~/.ssh/vm_id_rsa.pub
chmod 400 path/to/filename
This work for me. When I did this file I am able to connect to my EC2 instance
change your KEY permission to
chmod 400 your_key.pem
It should work !
After running below command it works for me
sudo chmod 600 /path/to/my/key.pem
In my case, it was a .pem file. Turns out holds good for that too. Changed permissions of the file and it worked.
chmod 400 ~/.ssh/dev-shared.pem
Thanks for all of those who helped above.
SSH keys are meant to be private so a 644 permission is too open.
Binary references to set Permissions
r(read) = 4
w(write) = 2
x(execute) = 1
So by adding these numbers and by passing the summed digit to chmod command,We set the permission of file/directory.
The first digit sets permission for the owner, second digit for group and the third one for all other users on the system who have no right to the file.
A permission of 644 means
(4+2) = read/write permission for the owner
(4) = read permission for the group
(4) = read permission for all other users
By changing the the permission of the file to 400 using
chmod 400 <filename>
solves the issue. As it makes the key read-only accessible to the owner.
Ref: https://www.linux.com/training-tutorials/understanding-linux-file-permissions/
Lot's of similar answers but no explanations...
The error is thrown because the private key file permissions are too open. It is a security risk.
Change the permissions on the private key file to be minimal (read only by owner)
Change owner chown <unix-name> <private-key-file>
Set minimal permissions (read only to file owner) chmod 400 <private-key-file>
If the keys are in the ~/.ssh directory , use
chmod 400 ~/.ssh/id_rsa
If the keys are in different directory, use
chmod 400 directory_path/id_rsa
This worked for me.
chmod 600 id_rsa
Run above command from path where key is stored in vm ex: cd /home/opc/.ssh
I have similar issue and solved it by changing the permission of the respective files and folder worked for me.
This is the solution which is worked for me:
$ chmod 0600 ~/.ssh/id_rsa.pub
$ chmod 0600 ~/.ssh/authorized_keys
$ chmod 0600 ~/.ssh/id_rsa
$ chmod 0700 ~/.ssh
You have to run the command bellow
chmod 400 /path/to/my/key.pem
As for me, the default mode of id_rsa is 600, which means readable and writable.
After I push this file to a git repo and pull it from another pc, sometimes the mode of the private key file becomes -rw-r--r--.
When I pull the repo with ssh after specify the private key file, it failed and prompted warnings the same with you. Following is my script.
ssh-agent bash -c "ssh-add $PATH_OF_RSA/id_rsa; \
git pull git#gitee.com:someone/somerepo.git "
I fix this problem just by changing the mode to 600.
chmod 600 $PATH_TO_RSA/id_rsa
giving permision 400 makes the key private and not accessible by someone unknown. It makes the key as a protected one.
chmod 400 /Users/tudouya/.ssh/vm/vm_id_rsa.pub
Just run below to your pem's
sudo chmod 600 /path/to/my/key.pem
If youre using a .ssh/config file try to
chmod 0400 .ssh/config
then:
chmod 0400 .ssh/<<KEYFILE_PATH>>
This should do the trick:
chmod 600 id_rsa
chmod 400 /etc/ssh/* works for me.
Those who suggested chmod 400 id_rsa.pub did not sound right at all. It was quite possible that op used pub key instead of private key to ssh.
So it might be as simple as ssh -i /Users/tudouya/.ssh/vm/vm_id_rsa (the private key) user#host to fix it.
--- update ---
Check this article https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2 for how to set up ssh key
I had this issue with a macbook m1, I later realized that i was missing sudo from the connection script
sudo ssh -i "key.pem" ubuntu#IP_Address
Ensure you are not missing the sudo in your connection script if you are using a macbook.
This problem had a quick and easy fix. You just had to change the permissions on the pem file using the following command.
chmod 400 /Users/yourUserName/pathOfYourFile/fileName.pem
This command will make the file read only and remove all other permissions on the file
There has been a lot of great explanation above, so I recommend reading and understanding.
Here is my simple step by step solution:
On your terminal, run:
open ~/.ssh/config
In your file, you will see something similar to this (in my personal case):
Host *
IgnoreUnknown UseKeychain
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519.pub
or like this (as per the example in this question).
Hostname 10.211.55.17
PreferredAuthentications publickey
IdentityFile /Users/tudouya/.ssh/vm/vm_id_rsa.pub
Remove the ".pub" extention from the last line, which should look like:
Hostname 10.211.55.17
PreferredAuthentications publickey
IdentityFile /Users/tudouya/.ssh/vm/vm_id_rsa
or in my case:
Host *
IgnoreUnknown UseKeychain
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519
Save the file and test your ssh connection.
i had similar issues and this was what i did and it worked.
sudo ssh -i webhost.pem ubuntu#ipaddress
I removed the .pub file, and it worked.

CentOS scp without password not working

I have been trying to connect from one EC2 instance to another using ssh public keys and have been having a very tough time.
Here is the scenario:
I need to have box 2 scp a file from box 1 in a script. This script will need to be able to scp without a password so I need to setup public keys.
On box 2 I ran ssh-keygen –t rsa and generated id_rsa and id_rsa.pub
I copied id_rsa.pub to box 1
I moved id_rsa.pub to .ssh and ran cat id_rsa.pug >> authorized_keys
I changed permissions of all .ssh directory to 700 on both boxes and the files themselves to 600.
I have changed the sshd_config settings on box 1 to:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
And then restarted ssh
/sbin/service sshd restart
When I try to scp or ssh into box1 from box1 I get the error:
Address 67.22.33.1 maps to ec2-67-22-33-1.compute-1.amazonaws.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
tomcat#tomcat1.****.com's password:
Any ideas?
I made that change and tried scp to tomcat1 and it failed. Here is the output:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to tomcat1.****.com [67.22.33.15] port 22.
debug1: Connection established.
debug1: identity file /home/tomcat/.ssh/identity type -1
debug1: identity file /home/tomcat/.ssh/id_rsa type 1
debug1: identity file /home/tomcat/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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
The authenticity of host 'tomcat1.****.com (67.22.33.15)' can't be established.
RSA key fingerprint is 5a:3e:fe:be:b8:0e:05:63:bf:ab:c8:4f:e5:91:db:a0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'tomcat1.****.com,67.22.33.15' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/tomcat/.ssh/identity
debug1: Offering public key: /home/tomcat/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/tomcat/.ssh/id_dsa
debug1: Next authentication method: password
Your authorized keys line should be
AuthorizedKeysFile %h/.ssh/authorized_keys
The server is looking in the wrong directory for your server.
UPDATE - FIXED IT
restorecon -R -v -d /root/.ssh
This is a known issue with RH where directories get mislabelled and PAM prevends sshd from reading authorized_hosts when run as init script. You'll see the errors if you stumble across /var/log/audit/audit.log. Rare it seems but painful when it happens!
More details at https://bugzilla.redhat.com/show_bug.cgi?id=499343
ORIGINAL POST
I've just hit what looks like exactly this problem. I had a poorly tuned VirtualBox (I hadn't told vbox to use 64bit) -- which when I cloned and restarted (in vbox RedHat 64-bit mode), started asking me for a password.
The original image was fine -- with identical settings -- so I think the suggestion of being networking-related might be relevant, or else to do with server keys.
The weird thing however is that if on the box, I kill the sshd process which autostarted, then manually run /usr/sbin/sshd as root, I can log in passwordless fine. A silly workaround, but usable.
So it is an /etc/init.d/sshd issue. But I haven't been able to track down what it is ... have tried chucking out most of the stuff in that script but it still prompts for password when invoked as /etc/init.d/sshd start but not when at /usr/sbin/sshd.
Maybe these comments can help, and someone can then help further!?
Try removing box1 IP from ~/.ssh/known_hosts, so it renews. Perhaps ssh disables key authentication due to possible 'man in the middle' attack.
If it won't help, add line
GSSAPIAuthentication no
in your /etc/ssh/ssh_config file.
I think this link will solve your problem and I use it to solve my ssh not login problem. The keypoint is to run
ssh root#node02 'restorecon -R -v /root/.ssh'
this command will fix SE
http://blog.firedaemon.com/2011/07/27/passwordless-root-ssh-public-key-authentication-on-centos-6/
After following previous steps I had to set the permission to ".." in the .ssh folder:
Once I had for ~/.ssh:
drwx------ 2 build build 4096 Nov 4 14:35 .
drwx------ 6 build build 4096 Nov 4 14:34 ..
-rw------- 1 build build 400 Nov 4 14:35 authorized_keys
It worked!
Thanks. Damian
I had the exact same problem and have been scratching my head for an entire afternoon.
It turned out to be a small sshd_config file issue.
first, change access mod on .ssh folder of the remote host to user access only.
chmod 700 ~/.ssh
next, go to /etc/ssh/sshd_config, change StrictModes yes to StrictModes no. If it's commented out, then specifically add StrictModes no into the file.
That solved the issue.
And one more thing I just found, I had to edit the .ssh/authorized_keys file to and make hostname fully qualified. Otherwise, I couldn't use the fully qualified name in the scp/ssh command. Now both fully qualified (like "host.company.com") & the relative name ("host") work, given that both hosts are in the "company.com" domain. ssh-keygen created the public key file with just the hostname.

Manually get ssh access back on a embedded system (direct hdd access possible)

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.

ssh connection using RSA key keep asking password [closed]

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.