SSH public key won't send to server
Clash Royale CLAN TAG#URR8PPP
I've been struggling with this for a couple hours so any help is greatly appreciated...
I have 2x servers both of which I can ssh
to with public keys from OSX, no issues at all there so I'm certain everything is good with sshd_config
.
I'm trying to configure a cron job for rsync
to sync the two servers and need server B (backup) to ssh
into server A using a public key.
I cannot for the life of me work out why it doesn't find my public keys - they are in ~/.ssh/
(ie. /root/.ssh
) and all file permissions are correct on A & B.
This is the output:
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
Also note it is looking for private keys which don't exist...
drwx------. 2 root root 4096 May 25 10:15 .
dr-xr-x---. 4 root root 4096 May 24 18:52 ..
-rw-------. 1 root root 403 May 25 01:37 authorized_keys
-rw-------. 1 root root 0 May 25 01:41 config
-rw-------. 1 root root 1675 May 25 02:35 id_rsa_tm1
-rw-------. 1 root root 405 May 25 02:35 id_rsa_tm1.pub
-rw-------. 1 root root 395 May 25 02:36 known_hosts
ssh key-authentication
add a comment |
I've been struggling with this for a couple hours so any help is greatly appreciated...
I have 2x servers both of which I can ssh
to with public keys from OSX, no issues at all there so I'm certain everything is good with sshd_config
.
I'm trying to configure a cron job for rsync
to sync the two servers and need server B (backup) to ssh
into server A using a public key.
I cannot for the life of me work out why it doesn't find my public keys - they are in ~/.ssh/
(ie. /root/.ssh
) and all file permissions are correct on A & B.
This is the output:
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
Also note it is looking for private keys which don't exist...
drwx------. 2 root root 4096 May 25 10:15 .
dr-xr-x---. 4 root root 4096 May 24 18:52 ..
-rw-------. 1 root root 403 May 25 01:37 authorized_keys
-rw-------. 1 root root 0 May 25 01:41 config
-rw-------. 1 root root 1675 May 25 02:35 id_rsa_tm1
-rw-------. 1 root root 405 May 25 02:35 id_rsa_tm1.pub
-rw-------. 1 root root 395 May 25 02:36 known_hosts
ssh key-authentication
please give us the output ofls -la /root/.ssh/
– mreithub
May 25 '14 at 10:16
@mreithub Thanks for the quick reply - added above.
– Danny
May 25 '14 at 10:18
try removing the_tm1
from your key file names (i.e.mv id_rsa_tm1 id_rsa
andmv id_rsa_tm1.pub id_rsa.pub
)
– mreithub
May 25 '14 at 10:20
@mreithub That worked! Thanks you very much, however i don't understand why i cannot append other strings to the file name. I do so on my iMac to connect to the servers without any issues... ie I can use id_rsa.tm1.imac.pub without any issues. What if i wanted multiple keys?
– Danny
May 25 '14 at 10:26
add a comment |
I've been struggling with this for a couple hours so any help is greatly appreciated...
I have 2x servers both of which I can ssh
to with public keys from OSX, no issues at all there so I'm certain everything is good with sshd_config
.
I'm trying to configure a cron job for rsync
to sync the two servers and need server B (backup) to ssh
into server A using a public key.
I cannot for the life of me work out why it doesn't find my public keys - they are in ~/.ssh/
(ie. /root/.ssh
) and all file permissions are correct on A & B.
This is the output:
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
Also note it is looking for private keys which don't exist...
drwx------. 2 root root 4096 May 25 10:15 .
dr-xr-x---. 4 root root 4096 May 24 18:52 ..
-rw-------. 1 root root 403 May 25 01:37 authorized_keys
-rw-------. 1 root root 0 May 25 01:41 config
-rw-------. 1 root root 1675 May 25 02:35 id_rsa_tm1
-rw-------. 1 root root 405 May 25 02:35 id_rsa_tm1.pub
-rw-------. 1 root root 395 May 25 02:36 known_hosts
ssh key-authentication
I've been struggling with this for a couple hours so any help is greatly appreciated...
I have 2x servers both of which I can ssh
to with public keys from OSX, no issues at all there so I'm certain everything is good with sshd_config
.
I'm trying to configure a cron job for rsync
to sync the two servers and need server B (backup) to ssh
into server A using a public key.
I cannot for the life of me work out why it doesn't find my public keys - they are in ~/.ssh/
(ie. /root/.ssh
) and all file permissions are correct on A & B.
This is the output:
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
Also note it is looking for private keys which don't exist...
drwx------. 2 root root 4096 May 25 10:15 .
dr-xr-x---. 4 root root 4096 May 24 18:52 ..
-rw-------. 1 root root 403 May 25 01:37 authorized_keys
-rw-------. 1 root root 0 May 25 01:41 config
-rw-------. 1 root root 1675 May 25 02:35 id_rsa_tm1
-rw-------. 1 root root 405 May 25 02:35 id_rsa_tm1.pub
-rw-------. 1 root root 395 May 25 02:36 known_hosts
ssh key-authentication
ssh key-authentication
edited May 25 '14 at 21:22
Gilles
544k12811021619
544k12811021619
asked May 25 '14 at 10:14
DannyDanny
123117
123117
please give us the output ofls -la /root/.ssh/
– mreithub
May 25 '14 at 10:16
@mreithub Thanks for the quick reply - added above.
– Danny
May 25 '14 at 10:18
try removing the_tm1
from your key file names (i.e.mv id_rsa_tm1 id_rsa
andmv id_rsa_tm1.pub id_rsa.pub
)
– mreithub
May 25 '14 at 10:20
@mreithub That worked! Thanks you very much, however i don't understand why i cannot append other strings to the file name. I do so on my iMac to connect to the servers without any issues... ie I can use id_rsa.tm1.imac.pub without any issues. What if i wanted multiple keys?
– Danny
May 25 '14 at 10:26
add a comment |
please give us the output ofls -la /root/.ssh/
– mreithub
May 25 '14 at 10:16
@mreithub Thanks for the quick reply - added above.
– Danny
May 25 '14 at 10:18
try removing the_tm1
from your key file names (i.e.mv id_rsa_tm1 id_rsa
andmv id_rsa_tm1.pub id_rsa.pub
)
– mreithub
May 25 '14 at 10:20
@mreithub That worked! Thanks you very much, however i don't understand why i cannot append other strings to the file name. I do so on my iMac to connect to the servers without any issues... ie I can use id_rsa.tm1.imac.pub without any issues. What if i wanted multiple keys?
– Danny
May 25 '14 at 10:26
please give us the output of
ls -la /root/.ssh/
– mreithub
May 25 '14 at 10:16
please give us the output of
ls -la /root/.ssh/
– mreithub
May 25 '14 at 10:16
@mreithub Thanks for the quick reply - added above.
– Danny
May 25 '14 at 10:18
@mreithub Thanks for the quick reply - added above.
– Danny
May 25 '14 at 10:18
try removing the
_tm1
from your key file names (i.e. mv id_rsa_tm1 id_rsa
and mv id_rsa_tm1.pub id_rsa.pub
)– mreithub
May 25 '14 at 10:20
try removing the
_tm1
from your key file names (i.e. mv id_rsa_tm1 id_rsa
and mv id_rsa_tm1.pub id_rsa.pub
)– mreithub
May 25 '14 at 10:20
@mreithub That worked! Thanks you very much, however i don't understand why i cannot append other strings to the file name. I do so on my iMac to connect to the servers without any issues... ie I can use id_rsa.tm1.imac.pub without any issues. What if i wanted multiple keys?
– Danny
May 25 '14 at 10:26
@mreithub That worked! Thanks you very much, however i don't understand why i cannot append other strings to the file name. I do so on my iMac to connect to the servers without any issues... ie I can use id_rsa.tm1.imac.pub without any issues. What if i wanted multiple keys?
– Danny
May 25 '14 at 10:26
add a comment |
8 Answers
8
active
oldest
votes
Have a look at your ssh man page:
-i identity_file
Selects a file from which the identity (private key) for public
key authentication is read. The default is ~/.ssh/identity for
protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2.
Identity files may also be specified on a per-host basis in the
configuration file. It is possible to have multiple -i options
(and multiple identities specified in configuration files).
or the ssh_config man page:
IdentityFile
Specifies a file from which the user's DSA, ECDSA, ED25519 or
RSA authentication identity is read. The default is
~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa,
~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
col version 2. Additionally, any identities represented by the
authentication agent will be used for authentication unless
IdentitiesOnly is set.
You see, there are a few special file names which are tried if you do not specify a key. Those are also the files you see in your log output.
To use a key in a file with different name you have three options:
- specify the file explicitly using the above
-i
option. - configure the file in your client config using the above
IdentityFile
option. - add the key to your agent using
ssh-add
.
For interactive sessions the agent is the most flexible one. For your cron job the -i
option is probably the easiest one.
add a comment |
A malformed authorized_keys file on the destination host is another reason ssh outputs the "we did not send a packet" message and asks for a password instead of using pubkey auth:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
The problem in this particular case was that the public key data, which had been pasted into .ssh/authorized_keys
at the destination host, was missing its first character:-
sh-rsa AAAA...
The solution was simply to add the missing "s".
ssh-rsa AAAA...
And so:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
...
debug1: Authentication succeeded (publickey).
1
thank you, every time I get this error it's because my authorized_keys file on the remote host (server) is malformed. I wish the error didn't make it sound like there was a problem with the client.
– tamale
Sep 18 '17 at 14:53
2
Pasting into vim without pressing 'i' first!
– Jordan Davidson
Feb 28 '18 at 4:36
For me it didn't seem malformed but I deleted the file and from the source machine I did the ssh-copy-id again to recreate it. Problem solved.
– alvarez
Jul 27 '18 at 7:34
add a comment |
This exact string of error messages in the question can also occur in the case of a miss-matched private/public key pair on the local side. No that doesn't make any sense but I just tore my hair out for a long time trying to figure out what was going on.
- Remote system A has
.ssh/mykey.pub
copied into.ssh/authorized_keys
. - Local system B has
.ssh/mykey
that is the correct private key to match system A's public key, but also has a.ssh/mykey.pub
file that is a miss-match, possibly the previous version of a replaced key.
SSH from B to A (ssh -i mykey A
)will fail with the messages in the question, most notably if you turn on -vv
from the ssh client you'll see:
Trying private key: .ssh/mykey
we did not send a packet, disable method
This is a lie because the actual key wasn't tried, it apparently used the local public key file with the matching name to figure out if it was likely to work and then didn't actually do anything when they were a mismatch. No amount of debug information on either side really hints at the problem.
Wow! This one killed quite a bit of time for me too! Lost some hair! So in my case it was this too, only my pub key was indeed in the client side authorized_keys file, except it included a name@host entry at the very end, where my sshd host did not. I did not realize you need to match the authorized_keys on each end, in fact, I don't think I've ever matched them before. This was a problem only when my client was CentOS 7, connecting to Ubuntu 12.04. Going from MacOS, or other Ubuntu systems worked just fine.
– gregthegeek
Mar 7 '17 at 0:15
So how do you fix this problem? You've described my problem to a T. My problem is further exacerbated because I'm leap frogging between a number of systems. Actually specifying the file isn't working for me
– Madivad
Apr 17 '17 at 16:55
@Madivad You fix the problem by having matched public/private keys locally (or no public keys at all).
– Caleb
Apr 17 '17 at 18:33
@Caleb That sounds more simple than it is unless (and I think the penny has dropped) this means I should be copying both public and private keys to each system that I want to use as an SSH client? I've tried creating an IdentityFile, but I'm obviously using it wrong
– Madivad
Apr 17 '17 at 22:52
Removing the orphaned id_rsa.pub file on client solved this for me. I just ran into this problem yet again on a new Centos 7 client connecting to Ubuntu 12.04 server. authorized_keys name@host issue wasn't fixing it. I matched up directories, perms, exact same id_rsa key file, but there was an extra id_rsa.pub (on client side). Removed, now it works. I had ran ssh-keygen to create directories quick, then rsync from known good system. But that left an extra pub file not matching any private key (it was not on source rsync). I re-added unmatched pub file to verify. Make sure matched or remove.
– gregthegeek
May 12 '17 at 18:35
add a comment |
The default file names ssh is looking for are id_rsa
and id_rsa.pub
.
If you want to use other file names, you either have to specify them in ssh_config
(using the IdentityFile
setting) or via the ssh command line
parameter -i
.
add a comment |
I had the same issue on RedHat; checked logs and found that home directory had incorrect user rights.
sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user
Fixing home dir rights solved this.
4
Welcome to U+L Stack Exchange site. You could make your answer more helpful to others by providing an example of what correct permissions should look like.
– Erathiel
May 20 '15 at 9:50
I had a very similar issue except with~/.ssh
dir. At least on Fedora 28 when~/.ssh
permissions were 0775, I could not connect with public/private keys. So I changed permissions to 0755 and worked like a charm :)
– PovilasB
Jun 30 '18 at 18:11
add a comment |
Try
/sbin/restorecon -r /root/.ssh
A possible problem with selling context
I'm on Ubuntu and there's no such binary.
– user7000
Apr 14 '18 at 4:18
add a comment |
After running
ssh-copy-id user@remote-host
normally it should work. But if it fails, try this: login to the remote host as the user you want to login in future and run:
ssh-keygen
It helped me.
add a comment |
client:
vim /etc/ssh/ssh_config
#add your key
IdentityFile ~/.ssh/yourkey
service sshd restart
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f131886%2fssh-public-key-wont-send-to-server%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
8 Answers
8
active
oldest
votes
8 Answers
8
active
oldest
votes
active
oldest
votes
active
oldest
votes
Have a look at your ssh man page:
-i identity_file
Selects a file from which the identity (private key) for public
key authentication is read. The default is ~/.ssh/identity for
protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2.
Identity files may also be specified on a per-host basis in the
configuration file. It is possible to have multiple -i options
(and multiple identities specified in configuration files).
or the ssh_config man page:
IdentityFile
Specifies a file from which the user's DSA, ECDSA, ED25519 or
RSA authentication identity is read. The default is
~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa,
~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
col version 2. Additionally, any identities represented by the
authentication agent will be used for authentication unless
IdentitiesOnly is set.
You see, there are a few special file names which are tried if you do not specify a key. Those are also the files you see in your log output.
To use a key in a file with different name you have three options:
- specify the file explicitly using the above
-i
option. - configure the file in your client config using the above
IdentityFile
option. - add the key to your agent using
ssh-add
.
For interactive sessions the agent is the most flexible one. For your cron job the -i
option is probably the easiest one.
add a comment |
Have a look at your ssh man page:
-i identity_file
Selects a file from which the identity (private key) for public
key authentication is read. The default is ~/.ssh/identity for
protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2.
Identity files may also be specified on a per-host basis in the
configuration file. It is possible to have multiple -i options
(and multiple identities specified in configuration files).
or the ssh_config man page:
IdentityFile
Specifies a file from which the user's DSA, ECDSA, ED25519 or
RSA authentication identity is read. The default is
~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa,
~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
col version 2. Additionally, any identities represented by the
authentication agent will be used for authentication unless
IdentitiesOnly is set.
You see, there are a few special file names which are tried if you do not specify a key. Those are also the files you see in your log output.
To use a key in a file with different name you have three options:
- specify the file explicitly using the above
-i
option. - configure the file in your client config using the above
IdentityFile
option. - add the key to your agent using
ssh-add
.
For interactive sessions the agent is the most flexible one. For your cron job the -i
option is probably the easiest one.
add a comment |
Have a look at your ssh man page:
-i identity_file
Selects a file from which the identity (private key) for public
key authentication is read. The default is ~/.ssh/identity for
protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2.
Identity files may also be specified on a per-host basis in the
configuration file. It is possible to have multiple -i options
(and multiple identities specified in configuration files).
or the ssh_config man page:
IdentityFile
Specifies a file from which the user's DSA, ECDSA, ED25519 or
RSA authentication identity is read. The default is
~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa,
~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
col version 2. Additionally, any identities represented by the
authentication agent will be used for authentication unless
IdentitiesOnly is set.
You see, there are a few special file names which are tried if you do not specify a key. Those are also the files you see in your log output.
To use a key in a file with different name you have three options:
- specify the file explicitly using the above
-i
option. - configure the file in your client config using the above
IdentityFile
option. - add the key to your agent using
ssh-add
.
For interactive sessions the agent is the most flexible one. For your cron job the -i
option is probably the easiest one.
Have a look at your ssh man page:
-i identity_file
Selects a file from which the identity (private key) for public
key authentication is read. The default is ~/.ssh/identity for
protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2.
Identity files may also be specified on a per-host basis in the
configuration file. It is possible to have multiple -i options
(and multiple identities specified in configuration files).
or the ssh_config man page:
IdentityFile
Specifies a file from which the user's DSA, ECDSA, ED25519 or
RSA authentication identity is read. The default is
~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa,
~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
col version 2. Additionally, any identities represented by the
authentication agent will be used for authentication unless
IdentitiesOnly is set.
You see, there are a few special file names which are tried if you do not specify a key. Those are also the files you see in your log output.
To use a key in a file with different name you have three options:
- specify the file explicitly using the above
-i
option. - configure the file in your client config using the above
IdentityFile
option. - add the key to your agent using
ssh-add
.
For interactive sessions the agent is the most flexible one. For your cron job the -i
option is probably the easiest one.
answered May 25 '14 at 11:34
michasmichas
15.4k33872
15.4k33872
add a comment |
add a comment |
A malformed authorized_keys file on the destination host is another reason ssh outputs the "we did not send a packet" message and asks for a password instead of using pubkey auth:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
The problem in this particular case was that the public key data, which had been pasted into .ssh/authorized_keys
at the destination host, was missing its first character:-
sh-rsa AAAA...
The solution was simply to add the missing "s".
ssh-rsa AAAA...
And so:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
...
debug1: Authentication succeeded (publickey).
1
thank you, every time I get this error it's because my authorized_keys file on the remote host (server) is malformed. I wish the error didn't make it sound like there was a problem with the client.
– tamale
Sep 18 '17 at 14:53
2
Pasting into vim without pressing 'i' first!
– Jordan Davidson
Feb 28 '18 at 4:36
For me it didn't seem malformed but I deleted the file and from the source machine I did the ssh-copy-id again to recreate it. Problem solved.
– alvarez
Jul 27 '18 at 7:34
add a comment |
A malformed authorized_keys file on the destination host is another reason ssh outputs the "we did not send a packet" message and asks for a password instead of using pubkey auth:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
The problem in this particular case was that the public key data, which had been pasted into .ssh/authorized_keys
at the destination host, was missing its first character:-
sh-rsa AAAA...
The solution was simply to add the missing "s".
ssh-rsa AAAA...
And so:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
...
debug1: Authentication succeeded (publickey).
1
thank you, every time I get this error it's because my authorized_keys file on the remote host (server) is malformed. I wish the error didn't make it sound like there was a problem with the client.
– tamale
Sep 18 '17 at 14:53
2
Pasting into vim without pressing 'i' first!
– Jordan Davidson
Feb 28 '18 at 4:36
For me it didn't seem malformed but I deleted the file and from the source machine I did the ssh-copy-id again to recreate it. Problem solved.
– alvarez
Jul 27 '18 at 7:34
add a comment |
A malformed authorized_keys file on the destination host is another reason ssh outputs the "we did not send a packet" message and asks for a password instead of using pubkey auth:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
The problem in this particular case was that the public key data, which had been pasted into .ssh/authorized_keys
at the destination host, was missing its first character:-
sh-rsa AAAA...
The solution was simply to add the missing "s".
ssh-rsa AAAA...
And so:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
...
debug1: Authentication succeeded (publickey).
A malformed authorized_keys file on the destination host is another reason ssh outputs the "we did not send a packet" message and asks for a password instead of using pubkey auth:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
The problem in this particular case was that the public key data, which had been pasted into .ssh/authorized_keys
at the destination host, was missing its first character:-
sh-rsa AAAA...
The solution was simply to add the missing "s".
ssh-rsa AAAA...
And so:-
debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
...
debug1: Authentication succeeded (publickey).
answered May 6 '16 at 19:56
jahjah
31839
31839
1
thank you, every time I get this error it's because my authorized_keys file on the remote host (server) is malformed. I wish the error didn't make it sound like there was a problem with the client.
– tamale
Sep 18 '17 at 14:53
2
Pasting into vim without pressing 'i' first!
– Jordan Davidson
Feb 28 '18 at 4:36
For me it didn't seem malformed but I deleted the file and from the source machine I did the ssh-copy-id again to recreate it. Problem solved.
– alvarez
Jul 27 '18 at 7:34
add a comment |
1
thank you, every time I get this error it's because my authorized_keys file on the remote host (server) is malformed. I wish the error didn't make it sound like there was a problem with the client.
– tamale
Sep 18 '17 at 14:53
2
Pasting into vim without pressing 'i' first!
– Jordan Davidson
Feb 28 '18 at 4:36
For me it didn't seem malformed but I deleted the file and from the source machine I did the ssh-copy-id again to recreate it. Problem solved.
– alvarez
Jul 27 '18 at 7:34
1
1
thank you, every time I get this error it's because my authorized_keys file on the remote host (server) is malformed. I wish the error didn't make it sound like there was a problem with the client.
– tamale
Sep 18 '17 at 14:53
thank you, every time I get this error it's because my authorized_keys file on the remote host (server) is malformed. I wish the error didn't make it sound like there was a problem with the client.
– tamale
Sep 18 '17 at 14:53
2
2
Pasting into vim without pressing 'i' first!
– Jordan Davidson
Feb 28 '18 at 4:36
Pasting into vim without pressing 'i' first!
– Jordan Davidson
Feb 28 '18 at 4:36
For me it didn't seem malformed but I deleted the file and from the source machine I did the ssh-copy-id again to recreate it. Problem solved.
– alvarez
Jul 27 '18 at 7:34
For me it didn't seem malformed but I deleted the file and from the source machine I did the ssh-copy-id again to recreate it. Problem solved.
– alvarez
Jul 27 '18 at 7:34
add a comment |
This exact string of error messages in the question can also occur in the case of a miss-matched private/public key pair on the local side. No that doesn't make any sense but I just tore my hair out for a long time trying to figure out what was going on.
- Remote system A has
.ssh/mykey.pub
copied into.ssh/authorized_keys
. - Local system B has
.ssh/mykey
that is the correct private key to match system A's public key, but also has a.ssh/mykey.pub
file that is a miss-match, possibly the previous version of a replaced key.
SSH from B to A (ssh -i mykey A
)will fail with the messages in the question, most notably if you turn on -vv
from the ssh client you'll see:
Trying private key: .ssh/mykey
we did not send a packet, disable method
This is a lie because the actual key wasn't tried, it apparently used the local public key file with the matching name to figure out if it was likely to work and then didn't actually do anything when they were a mismatch. No amount of debug information on either side really hints at the problem.
Wow! This one killed quite a bit of time for me too! Lost some hair! So in my case it was this too, only my pub key was indeed in the client side authorized_keys file, except it included a name@host entry at the very end, where my sshd host did not. I did not realize you need to match the authorized_keys on each end, in fact, I don't think I've ever matched them before. This was a problem only when my client was CentOS 7, connecting to Ubuntu 12.04. Going from MacOS, or other Ubuntu systems worked just fine.
– gregthegeek
Mar 7 '17 at 0:15
So how do you fix this problem? You've described my problem to a T. My problem is further exacerbated because I'm leap frogging between a number of systems. Actually specifying the file isn't working for me
– Madivad
Apr 17 '17 at 16:55
@Madivad You fix the problem by having matched public/private keys locally (or no public keys at all).
– Caleb
Apr 17 '17 at 18:33
@Caleb That sounds more simple than it is unless (and I think the penny has dropped) this means I should be copying both public and private keys to each system that I want to use as an SSH client? I've tried creating an IdentityFile, but I'm obviously using it wrong
– Madivad
Apr 17 '17 at 22:52
Removing the orphaned id_rsa.pub file on client solved this for me. I just ran into this problem yet again on a new Centos 7 client connecting to Ubuntu 12.04 server. authorized_keys name@host issue wasn't fixing it. I matched up directories, perms, exact same id_rsa key file, but there was an extra id_rsa.pub (on client side). Removed, now it works. I had ran ssh-keygen to create directories quick, then rsync from known good system. But that left an extra pub file not matching any private key (it was not on source rsync). I re-added unmatched pub file to verify. Make sure matched or remove.
– gregthegeek
May 12 '17 at 18:35
add a comment |
This exact string of error messages in the question can also occur in the case of a miss-matched private/public key pair on the local side. No that doesn't make any sense but I just tore my hair out for a long time trying to figure out what was going on.
- Remote system A has
.ssh/mykey.pub
copied into.ssh/authorized_keys
. - Local system B has
.ssh/mykey
that is the correct private key to match system A's public key, but also has a.ssh/mykey.pub
file that is a miss-match, possibly the previous version of a replaced key.
SSH from B to A (ssh -i mykey A
)will fail with the messages in the question, most notably if you turn on -vv
from the ssh client you'll see:
Trying private key: .ssh/mykey
we did not send a packet, disable method
This is a lie because the actual key wasn't tried, it apparently used the local public key file with the matching name to figure out if it was likely to work and then didn't actually do anything when they were a mismatch. No amount of debug information on either side really hints at the problem.
Wow! This one killed quite a bit of time for me too! Lost some hair! So in my case it was this too, only my pub key was indeed in the client side authorized_keys file, except it included a name@host entry at the very end, where my sshd host did not. I did not realize you need to match the authorized_keys on each end, in fact, I don't think I've ever matched them before. This was a problem only when my client was CentOS 7, connecting to Ubuntu 12.04. Going from MacOS, or other Ubuntu systems worked just fine.
– gregthegeek
Mar 7 '17 at 0:15
So how do you fix this problem? You've described my problem to a T. My problem is further exacerbated because I'm leap frogging between a number of systems. Actually specifying the file isn't working for me
– Madivad
Apr 17 '17 at 16:55
@Madivad You fix the problem by having matched public/private keys locally (or no public keys at all).
– Caleb
Apr 17 '17 at 18:33
@Caleb That sounds more simple than it is unless (and I think the penny has dropped) this means I should be copying both public and private keys to each system that I want to use as an SSH client? I've tried creating an IdentityFile, but I'm obviously using it wrong
– Madivad
Apr 17 '17 at 22:52
Removing the orphaned id_rsa.pub file on client solved this for me. I just ran into this problem yet again on a new Centos 7 client connecting to Ubuntu 12.04 server. authorized_keys name@host issue wasn't fixing it. I matched up directories, perms, exact same id_rsa key file, but there was an extra id_rsa.pub (on client side). Removed, now it works. I had ran ssh-keygen to create directories quick, then rsync from known good system. But that left an extra pub file not matching any private key (it was not on source rsync). I re-added unmatched pub file to verify. Make sure matched or remove.
– gregthegeek
May 12 '17 at 18:35
add a comment |
This exact string of error messages in the question can also occur in the case of a miss-matched private/public key pair on the local side. No that doesn't make any sense but I just tore my hair out for a long time trying to figure out what was going on.
- Remote system A has
.ssh/mykey.pub
copied into.ssh/authorized_keys
. - Local system B has
.ssh/mykey
that is the correct private key to match system A's public key, but also has a.ssh/mykey.pub
file that is a miss-match, possibly the previous version of a replaced key.
SSH from B to A (ssh -i mykey A
)will fail with the messages in the question, most notably if you turn on -vv
from the ssh client you'll see:
Trying private key: .ssh/mykey
we did not send a packet, disable method
This is a lie because the actual key wasn't tried, it apparently used the local public key file with the matching name to figure out if it was likely to work and then didn't actually do anything when they were a mismatch. No amount of debug information on either side really hints at the problem.
This exact string of error messages in the question can also occur in the case of a miss-matched private/public key pair on the local side. No that doesn't make any sense but I just tore my hair out for a long time trying to figure out what was going on.
- Remote system A has
.ssh/mykey.pub
copied into.ssh/authorized_keys
. - Local system B has
.ssh/mykey
that is the correct private key to match system A's public key, but also has a.ssh/mykey.pub
file that is a miss-match, possibly the previous version of a replaced key.
SSH from B to A (ssh -i mykey A
)will fail with the messages in the question, most notably if you turn on -vv
from the ssh client you'll see:
Trying private key: .ssh/mykey
we did not send a packet, disable method
This is a lie because the actual key wasn't tried, it apparently used the local public key file with the matching name to figure out if it was likely to work and then didn't actually do anything when they were a mismatch. No amount of debug information on either side really hints at the problem.
answered Apr 16 '16 at 15:21
CalebCaleb
51.7k9150194
51.7k9150194
Wow! This one killed quite a bit of time for me too! Lost some hair! So in my case it was this too, only my pub key was indeed in the client side authorized_keys file, except it included a name@host entry at the very end, where my sshd host did not. I did not realize you need to match the authorized_keys on each end, in fact, I don't think I've ever matched them before. This was a problem only when my client was CentOS 7, connecting to Ubuntu 12.04. Going from MacOS, or other Ubuntu systems worked just fine.
– gregthegeek
Mar 7 '17 at 0:15
So how do you fix this problem? You've described my problem to a T. My problem is further exacerbated because I'm leap frogging between a number of systems. Actually specifying the file isn't working for me
– Madivad
Apr 17 '17 at 16:55
@Madivad You fix the problem by having matched public/private keys locally (or no public keys at all).
– Caleb
Apr 17 '17 at 18:33
@Caleb That sounds more simple than it is unless (and I think the penny has dropped) this means I should be copying both public and private keys to each system that I want to use as an SSH client? I've tried creating an IdentityFile, but I'm obviously using it wrong
– Madivad
Apr 17 '17 at 22:52
Removing the orphaned id_rsa.pub file on client solved this for me. I just ran into this problem yet again on a new Centos 7 client connecting to Ubuntu 12.04 server. authorized_keys name@host issue wasn't fixing it. I matched up directories, perms, exact same id_rsa key file, but there was an extra id_rsa.pub (on client side). Removed, now it works. I had ran ssh-keygen to create directories quick, then rsync from known good system. But that left an extra pub file not matching any private key (it was not on source rsync). I re-added unmatched pub file to verify. Make sure matched or remove.
– gregthegeek
May 12 '17 at 18:35
add a comment |
Wow! This one killed quite a bit of time for me too! Lost some hair! So in my case it was this too, only my pub key was indeed in the client side authorized_keys file, except it included a name@host entry at the very end, where my sshd host did not. I did not realize you need to match the authorized_keys on each end, in fact, I don't think I've ever matched them before. This was a problem only when my client was CentOS 7, connecting to Ubuntu 12.04. Going from MacOS, or other Ubuntu systems worked just fine.
– gregthegeek
Mar 7 '17 at 0:15
So how do you fix this problem? You've described my problem to a T. My problem is further exacerbated because I'm leap frogging between a number of systems. Actually specifying the file isn't working for me
– Madivad
Apr 17 '17 at 16:55
@Madivad You fix the problem by having matched public/private keys locally (or no public keys at all).
– Caleb
Apr 17 '17 at 18:33
@Caleb That sounds more simple than it is unless (and I think the penny has dropped) this means I should be copying both public and private keys to each system that I want to use as an SSH client? I've tried creating an IdentityFile, but I'm obviously using it wrong
– Madivad
Apr 17 '17 at 22:52
Removing the orphaned id_rsa.pub file on client solved this for me. I just ran into this problem yet again on a new Centos 7 client connecting to Ubuntu 12.04 server. authorized_keys name@host issue wasn't fixing it. I matched up directories, perms, exact same id_rsa key file, but there was an extra id_rsa.pub (on client side). Removed, now it works. I had ran ssh-keygen to create directories quick, then rsync from known good system. But that left an extra pub file not matching any private key (it was not on source rsync). I re-added unmatched pub file to verify. Make sure matched or remove.
– gregthegeek
May 12 '17 at 18:35
Wow! This one killed quite a bit of time for me too! Lost some hair! So in my case it was this too, only my pub key was indeed in the client side authorized_keys file, except it included a name@host entry at the very end, where my sshd host did not. I did not realize you need to match the authorized_keys on each end, in fact, I don't think I've ever matched them before. This was a problem only when my client was CentOS 7, connecting to Ubuntu 12.04. Going from MacOS, or other Ubuntu systems worked just fine.
– gregthegeek
Mar 7 '17 at 0:15
Wow! This one killed quite a bit of time for me too! Lost some hair! So in my case it was this too, only my pub key was indeed in the client side authorized_keys file, except it included a name@host entry at the very end, where my sshd host did not. I did not realize you need to match the authorized_keys on each end, in fact, I don't think I've ever matched them before. This was a problem only when my client was CentOS 7, connecting to Ubuntu 12.04. Going from MacOS, or other Ubuntu systems worked just fine.
– gregthegeek
Mar 7 '17 at 0:15
So how do you fix this problem? You've described my problem to a T. My problem is further exacerbated because I'm leap frogging between a number of systems. Actually specifying the file isn't working for me
– Madivad
Apr 17 '17 at 16:55
So how do you fix this problem? You've described my problem to a T. My problem is further exacerbated because I'm leap frogging between a number of systems. Actually specifying the file isn't working for me
– Madivad
Apr 17 '17 at 16:55
@Madivad You fix the problem by having matched public/private keys locally (or no public keys at all).
– Caleb
Apr 17 '17 at 18:33
@Madivad You fix the problem by having matched public/private keys locally (or no public keys at all).
– Caleb
Apr 17 '17 at 18:33
@Caleb That sounds more simple than it is unless (and I think the penny has dropped) this means I should be copying both public and private keys to each system that I want to use as an SSH client? I've tried creating an IdentityFile, but I'm obviously using it wrong
– Madivad
Apr 17 '17 at 22:52
@Caleb That sounds more simple than it is unless (and I think the penny has dropped) this means I should be copying both public and private keys to each system that I want to use as an SSH client? I've tried creating an IdentityFile, but I'm obviously using it wrong
– Madivad
Apr 17 '17 at 22:52
Removing the orphaned id_rsa.pub file on client solved this for me. I just ran into this problem yet again on a new Centos 7 client connecting to Ubuntu 12.04 server. authorized_keys name@host issue wasn't fixing it. I matched up directories, perms, exact same id_rsa key file, but there was an extra id_rsa.pub (on client side). Removed, now it works. I had ran ssh-keygen to create directories quick, then rsync from known good system. But that left an extra pub file not matching any private key (it was not on source rsync). I re-added unmatched pub file to verify. Make sure matched or remove.
– gregthegeek
May 12 '17 at 18:35
Removing the orphaned id_rsa.pub file on client solved this for me. I just ran into this problem yet again on a new Centos 7 client connecting to Ubuntu 12.04 server. authorized_keys name@host issue wasn't fixing it. I matched up directories, perms, exact same id_rsa key file, but there was an extra id_rsa.pub (on client side). Removed, now it works. I had ran ssh-keygen to create directories quick, then rsync from known good system. But that left an extra pub file not matching any private key (it was not on source rsync). I re-added unmatched pub file to verify. Make sure matched or remove.
– gregthegeek
May 12 '17 at 18:35
add a comment |
The default file names ssh is looking for are id_rsa
and id_rsa.pub
.
If you want to use other file names, you either have to specify them in ssh_config
(using the IdentityFile
setting) or via the ssh command line
parameter -i
.
add a comment |
The default file names ssh is looking for are id_rsa
and id_rsa.pub
.
If you want to use other file names, you either have to specify them in ssh_config
(using the IdentityFile
setting) or via the ssh command line
parameter -i
.
add a comment |
The default file names ssh is looking for are id_rsa
and id_rsa.pub
.
If you want to use other file names, you either have to specify them in ssh_config
(using the IdentityFile
setting) or via the ssh command line
parameter -i
.
The default file names ssh is looking for are id_rsa
and id_rsa.pub
.
If you want to use other file names, you either have to specify them in ssh_config
(using the IdentityFile
setting) or via the ssh command line
parameter -i
.
answered May 25 '14 at 10:36
mreithubmreithub
2,34311417
2,34311417
add a comment |
add a comment |
I had the same issue on RedHat; checked logs and found that home directory had incorrect user rights.
sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user
Fixing home dir rights solved this.
4
Welcome to U+L Stack Exchange site. You could make your answer more helpful to others by providing an example of what correct permissions should look like.
– Erathiel
May 20 '15 at 9:50
I had a very similar issue except with~/.ssh
dir. At least on Fedora 28 when~/.ssh
permissions were 0775, I could not connect with public/private keys. So I changed permissions to 0755 and worked like a charm :)
– PovilasB
Jun 30 '18 at 18:11
add a comment |
I had the same issue on RedHat; checked logs and found that home directory had incorrect user rights.
sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user
Fixing home dir rights solved this.
4
Welcome to U+L Stack Exchange site. You could make your answer more helpful to others by providing an example of what correct permissions should look like.
– Erathiel
May 20 '15 at 9:50
I had a very similar issue except with~/.ssh
dir. At least on Fedora 28 when~/.ssh
permissions were 0775, I could not connect with public/private keys. So I changed permissions to 0755 and worked like a charm :)
– PovilasB
Jun 30 '18 at 18:11
add a comment |
I had the same issue on RedHat; checked logs and found that home directory had incorrect user rights.
sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user
Fixing home dir rights solved this.
I had the same issue on RedHat; checked logs and found that home directory had incorrect user rights.
sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user
Fixing home dir rights solved this.
edited May 20 '15 at 10:21
Erathiel
1,341621
1,341621
answered May 20 '15 at 9:25
skywalkieskywalkie
311
311
4
Welcome to U+L Stack Exchange site. You could make your answer more helpful to others by providing an example of what correct permissions should look like.
– Erathiel
May 20 '15 at 9:50
I had a very similar issue except with~/.ssh
dir. At least on Fedora 28 when~/.ssh
permissions were 0775, I could not connect with public/private keys. So I changed permissions to 0755 and worked like a charm :)
– PovilasB
Jun 30 '18 at 18:11
add a comment |
4
Welcome to U+L Stack Exchange site. You could make your answer more helpful to others by providing an example of what correct permissions should look like.
– Erathiel
May 20 '15 at 9:50
I had a very similar issue except with~/.ssh
dir. At least on Fedora 28 when~/.ssh
permissions were 0775, I could not connect with public/private keys. So I changed permissions to 0755 and worked like a charm :)
– PovilasB
Jun 30 '18 at 18:11
4
4
Welcome to U+L Stack Exchange site. You could make your answer more helpful to others by providing an example of what correct permissions should look like.
– Erathiel
May 20 '15 at 9:50
Welcome to U+L Stack Exchange site. You could make your answer more helpful to others by providing an example of what correct permissions should look like.
– Erathiel
May 20 '15 at 9:50
I had a very similar issue except with
~/.ssh
dir. At least on Fedora 28 when ~/.ssh
permissions were 0775, I could not connect with public/private keys. So I changed permissions to 0755 and worked like a charm :)– PovilasB
Jun 30 '18 at 18:11
I had a very similar issue except with
~/.ssh
dir. At least on Fedora 28 when ~/.ssh
permissions were 0775, I could not connect with public/private keys. So I changed permissions to 0755 and worked like a charm :)– PovilasB
Jun 30 '18 at 18:11
add a comment |
Try
/sbin/restorecon -r /root/.ssh
A possible problem with selling context
I'm on Ubuntu and there's no such binary.
– user7000
Apr 14 '18 at 4:18
add a comment |
Try
/sbin/restorecon -r /root/.ssh
A possible problem with selling context
I'm on Ubuntu and there's no such binary.
– user7000
Apr 14 '18 at 4:18
add a comment |
Try
/sbin/restorecon -r /root/.ssh
A possible problem with selling context
Try
/sbin/restorecon -r /root/.ssh
A possible problem with selling context
answered Mar 14 '15 at 16:39
Abdel Karim Mateos SanchezAbdel Karim Mateos Sanchez
1215
1215
I'm on Ubuntu and there's no such binary.
– user7000
Apr 14 '18 at 4:18
add a comment |
I'm on Ubuntu and there's no such binary.
– user7000
Apr 14 '18 at 4:18
I'm on Ubuntu and there's no such binary.
– user7000
Apr 14 '18 at 4:18
I'm on Ubuntu and there's no such binary.
– user7000
Apr 14 '18 at 4:18
add a comment |
After running
ssh-copy-id user@remote-host
normally it should work. But if it fails, try this: login to the remote host as the user you want to login in future and run:
ssh-keygen
It helped me.
add a comment |
After running
ssh-copy-id user@remote-host
normally it should work. But if it fails, try this: login to the remote host as the user you want to login in future and run:
ssh-keygen
It helped me.
add a comment |
After running
ssh-copy-id user@remote-host
normally it should work. But if it fails, try this: login to the remote host as the user you want to login in future and run:
ssh-keygen
It helped me.
After running
ssh-copy-id user@remote-host
normally it should work. But if it fails, try this: login to the remote host as the user you want to login in future and run:
ssh-keygen
It helped me.
answered Oct 31 '16 at 4:16
mennanovmennanov
1011
1011
add a comment |
add a comment |
client:
vim /etc/ssh/ssh_config
#add your key
IdentityFile ~/.ssh/yourkey
service sshd restart
add a comment |
client:
vim /etc/ssh/ssh_config
#add your key
IdentityFile ~/.ssh/yourkey
service sshd restart
add a comment |
client:
vim /etc/ssh/ssh_config
#add your key
IdentityFile ~/.ssh/yourkey
service sshd restart
client:
vim /etc/ssh/ssh_config
#add your key
IdentityFile ~/.ssh/yourkey
service sshd restart
edited Feb 27 at 8:12
Prvt_Yadv
2,92531327
2,92531327
answered Feb 27 at 7:46
李孝奎李孝奎
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f131886%2fssh-public-key-wont-send-to-server%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
please give us the output of
ls -la /root/.ssh/
– mreithub
May 25 '14 at 10:16
@mreithub Thanks for the quick reply - added above.
– Danny
May 25 '14 at 10:18
try removing the
_tm1
from your key file names (i.e.mv id_rsa_tm1 id_rsa
andmv id_rsa_tm1.pub id_rsa.pub
)– mreithub
May 25 '14 at 10:20
@mreithub That worked! Thanks you very much, however i don't understand why i cannot append other strings to the file name. I do so on my iMac to connect to the servers without any issues... ie I can use id_rsa.tm1.imac.pub without any issues. What if i wanted multiple keys?
– Danny
May 25 '14 at 10:26