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.
Related
I have successfully been connecting to Bitbucket cloud via my SSH key set up on my laptop for the past three years with no issue, but suddenly today I started seeing this error when trying to pull from remote branch:
kex_exchange_identification: write: Broken pipe
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I followed the instructions here: https://support.atlassian.com/bitbucket-cloud/docs/set-up-an-ssh-key/ for Mac OS (I am using Big Sur). So I deleted the old ssh key, both from my machine and from my Bitbucket account, and replaced it with a newly generated one.
My .ssh config file contains this as recommended:
Host *
UseKeychain yes
So I have added the new key id_rsa to ssh agent:
ssh-add -K ~/.ssh/id_rsa
and added id_rsa.pub to my Bitbucket account as described in the instructions.
Still when I run ssh -T git#bitbucket.org I see: "kex_exchange_identification: write: Broken pipe"
Here is the output with the -v flag enabled:
daniel#North ~ % ssh -T -v git#bitbucket.org
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/daniel/.ssh/config
debug1: /Users/daniel/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to bitbucket.org port 22.
debug1: Connection established.
debug1: identity file /Users/daniel/.ssh/id_rsa type 0
debug1: identity file /Users/daniel/.ssh/id_rsa-cert type -1
debug1: identity file /Users/daniel/.ssh/id_dsa type -1
debug1: identity file /Users/daniel/.ssh/id_dsa-cert type -1
debug1: identity file /Users/daniel/.ssh/id_ecdsa type -1
debug1: identity file /Users/daniel/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/daniel/.ssh/id_ed25519 type -1
debug1: identity file /Users/daniel/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/daniel/.ssh/id_xmss type -1
debug1: identity file /Users/daniel/.ssh/id_xmss-cert type -1
kex_exchange_identification: write: Broken pipe
The strange thing is, when I try the exact same steps on a different Macbook, also running Big Sur, it actually works and I see 'authenticated via ssh key' when running the above command.
Anyone have any idea what might be causing the failure to connect?
my colleague has the same problem, strange thing is that it works when putting the mac in safe mode.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 11 months ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I'm unable to ssh to my EC2 server and am getting the error:
ssh -i /Users/Skeniver/Keepass/skeniver.pem ubuntu#xx.xxx.xx.xxx
Identity file /Users/Skeniver/Keepass/skeniver.pem not accessible: No such file or directory
The file is definitely in the directory and I've chmod'd the directory to 755 and the file to 600:
drwxr-xr-x 14 Skeniver staff 476 28 Nov 2012 Keepass
-rw------- 1 Skeniver staff 1696 5 Oct 2012 skeniverkey.pem
I'm pretty sure it's a permissions problem, but can't figure out why...
Here is the output of the ssh command using -v, in case it's of any use:
Warning: Identity file /Users/Skeniver/Keepass/skeniver.pem not accessible: No such file or directory.
OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to xx.xxx.xx.xxx [xx.xxx.xx.xxx] port 22.
debug1: Connection established.
debug1: identity file /Users/Skeniver/.ssh/identity type -1
debug1: identity file /Users/Skeniver/.ssh/id_rsa type 1
debug1: identity file /Users/Skeniver/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
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: Host 'xx.xxx.xx.xxx' is known and matches the RSA host key.
debug1: Found key in /Users/Skeniver/.ssh/known_hosts:8
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
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/Skeniver/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/Skeniver/.ssh/identity
debug1: Trying private key: /Users/Skeniver/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
You need the identity file to login to the box. Use the command:
ssh -i (identity_file) username#hostname"
This worked for me. Write just the filename (without any slashes), unlike Amazon EC2 tutorial which asks you to enter:
ssh -i /path/key_pair.pem ec2-user#public_dns_name
It worked for me after putting the identity file in the .ssh (hidden) folder on home. To view hidden folders on home, use ctrl+h
I had similar issue and found that there was hidden char in command, pasting to plain text editor and copy back helped me.
I was having this same issue. Storing the identity file in my ~/.ssh directory and running cd ~/.ssh before ssh -i (identity_file) username#hostname worked. I only ran into the issue when trying to run the ssh command from outside the ~/.ssh directory. Hopefully that helps
For your case just
just execute the following command to change permission
sudo chmod 400 /Users/Skeniver/Keepass/skeniver.pem
and then execute the command that will connect you to EC2
ssh -i /Users/Skeniver/Keepass/skeniver.pem ubuntu#xx.xxx.xx.xxx
I had the same problem and i found that the issue with the file path.
Right click on the your key_pair.pem (identical file) go the properties and copy and now your comment is like
ssh -i /path/skeniver.pem user#your_public_ip
for example in my case command like
ssh -i /home/anil/.ssh/webKey.pem ec2-user#ec2-45-349-50-38.us-west-2.compute.amazonaws.com
chmod 600 ~/.ssh/public_key_file solved for me
Looks like you typed the wrong filename. You're specifying the filename skeniver.pem in your command, but it looks like your filename is actually skeniverkey.pem.
There are multiple reasons to occurring this error.
1 you are trying to access from whatever path which is not match
2 either you do not have permission to do access
3 if you do not have access to that particular file you can try to change the mode of permission
like the above solution
sudo chmod 400 /Users/Skeniver/Keepass/skeniver.pem
even if not then you can co-ordinate with the network or your cloud team whoever manage your cloud server
This is weird, but in my case I was copying the command from a slack message and that repeatedly caused this error, even though I met all the above requirements. Typing the whole command without copying anything from clipboard worked for me. Posting this here and I hope this helps someone one day.
When connecting from a windows environment what did the trick for me was putting the path in quotation marks " as follows:
ssh -i "C:\Users\XXXX\Desktop\XXXX\testing_amazon_linux.pem" ubuntu#XXXX.amazonaws.com
I replaced identifiable things with XXXX but let the rest in place to improve example clarity.
run the command from .ssh directory i.e/Users//.ssh and then execute the command
ssh -v -i #
this worked for me after many failed attempt.
note: please make sure .pem file has necessary permission
chmod 400 <.pem file> before executing the command
I got here while solving same or similar problem. After trying a few things this works for me eventually. I am on MacBook Pro and trying to connect to Ec2 Amazon Linux 2 using VSCode Remote SSH.
I have to update this file
/Users/MrRobot/.ssh/config
There is a config in the file like below.
IdentityFile xx.pem
I have to update this to full path wherever your id_rsa or pem file is.
IdentityFile /Users/MrRobot/.ssh/xx.pem
my solution is move it to the path which is all the english chars
(i am a chinese, and use the chinese windows, when i run the command from the path which contains the chinese chars, it will return "Warning: Identity file debao-visa.pem not accessible: No such file or directory.")
A similar issue occurred and the problem was that the file extension was hidden.
So the real filename was skeniver.pem.txt instead of skeniver.pem
A simple way to determine this is to press tab while typing the filename. So type part of the filename like skenive then hit tab, it should print the rest of the file in the terminal and you should see if it has any part after .pem like .pem.txt.
Try
ssh -i /Users/Skeniver/Keepass/skeniver.pem.txt ubuntu#xx.xxx.xx.xxx
or remove the .txt or any other extension from the name.
You can try a different idea, here's what I did. I couldn't upload to a folder, so I put the uploaded folder to “ ubuntu#xxx.xxx.xx.xx:/tmp ” ,then I uploaded successfully and cp the file on the server afterwards.
Try using
ssh -i Users/Skeniver/Keepass/skeniver.pem ubuntu#xx.xxx.xx.xxx
instead of
ssh -i **/**Users/Skeniver/Keepass/skeniver.pem ubuntu#xx.xxx.xx.xxx
You need the identity file to login to the box.
Use the command
ssh -i (identity_file) username#hostname
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.
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.
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.