Why is my ssh connection unauthorized although I have updated my key on the remote machine?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
On my local machine I have a public key stored in
.ssh/id_rsa.pub
To be able to log in to a remote machine I copy this key using ssh-copy-id
:
ssh-copy-id user@remote-host
On the remote host, I see two lines added to the file .ssh/authorized_keys
starting with ssh-dss
and ssh-rsa
, and ending with the local machine information.
However, when I now log in to the remote machine with
ssh user@remote-host
I am still asked for a password. Why is that and how can this be fixed?
- The file permissions of
authorized_keys
are correct. The following is the result of
ssh -v
:OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to xxx [xxx] port 22.
debug1: Connection established.
debug1: identity file /home/alexander/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alexander/.ssh/id_rsa-cert type -1
debug1: identity file /home/alexander/.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: identity file /home/alexander/.ssh/id_dsa-cert type -1
debug1: identity file /home/alexander/.ssh/id_ecdsa type -1
debug1: identity file /home/alexander/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.52
debug1: no match: dropbear_0.52
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
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: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA XXXX
debug1: Host 'remote_host' is known and matches the RSA host key.
debug1: Found key in /home/alexander/.ssh/known_hosts:26
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 DSA public key: /home/alexander/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /home/alexander/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/alexander/.ssh/id_ecdsa
debug1: Next authentication method: password
user@remote_host's password:
linux ssh authentication
add a comment |
up vote
1
down vote
favorite
On my local machine I have a public key stored in
.ssh/id_rsa.pub
To be able to log in to a remote machine I copy this key using ssh-copy-id
:
ssh-copy-id user@remote-host
On the remote host, I see two lines added to the file .ssh/authorized_keys
starting with ssh-dss
and ssh-rsa
, and ending with the local machine information.
However, when I now log in to the remote machine with
ssh user@remote-host
I am still asked for a password. Why is that and how can this be fixed?
- The file permissions of
authorized_keys
are correct. The following is the result of
ssh -v
:OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to xxx [xxx] port 22.
debug1: Connection established.
debug1: identity file /home/alexander/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alexander/.ssh/id_rsa-cert type -1
debug1: identity file /home/alexander/.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: identity file /home/alexander/.ssh/id_dsa-cert type -1
debug1: identity file /home/alexander/.ssh/id_ecdsa type -1
debug1: identity file /home/alexander/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.52
debug1: no match: dropbear_0.52
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
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: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA XXXX
debug1: Host 'remote_host' is known and matches the RSA host key.
debug1: Found key in /home/alexander/.ssh/known_hosts:26
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 DSA public key: /home/alexander/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /home/alexander/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/alexander/.ssh/id_ecdsa
debug1: Next authentication method: password
user@remote_host's password:
linux ssh authentication
The log only says that your client has offered the key to the server, but apparently the server didn't accept that, so it reverts to password authentication. the reasons for tjat should be on server side, maybe PubkeyAuthentication or AuthorizedKeysFile aren't set on the server?
– replay
Nov 8 '13 at 9:15
Permissions on authorized_keys file on remote host?
– jirib
Nov 8 '13 at 9:20
The permissions on the authorized_keys are correct, and unfortunately I have no log files available I can take a look (because the remote host runs a non-standard linux and is highly configured.). Which file(s) usually contain ssh settings?
– Alex
Nov 8 '13 at 9:34
1
I have found the error: The modes of the overlaying directories where incorrect! After fixing all the permissions and ownerships the passwordless ssh login works. Thanks for the suggestions.
– Alex
Nov 8 '13 at 9:52
So the .ssh dir must be600
permission and the files inside700
?
– Timo
Jan 23 at 9:55
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
On my local machine I have a public key stored in
.ssh/id_rsa.pub
To be able to log in to a remote machine I copy this key using ssh-copy-id
:
ssh-copy-id user@remote-host
On the remote host, I see two lines added to the file .ssh/authorized_keys
starting with ssh-dss
and ssh-rsa
, and ending with the local machine information.
However, when I now log in to the remote machine with
ssh user@remote-host
I am still asked for a password. Why is that and how can this be fixed?
- The file permissions of
authorized_keys
are correct. The following is the result of
ssh -v
:OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to xxx [xxx] port 22.
debug1: Connection established.
debug1: identity file /home/alexander/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alexander/.ssh/id_rsa-cert type -1
debug1: identity file /home/alexander/.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: identity file /home/alexander/.ssh/id_dsa-cert type -1
debug1: identity file /home/alexander/.ssh/id_ecdsa type -1
debug1: identity file /home/alexander/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.52
debug1: no match: dropbear_0.52
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
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: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA XXXX
debug1: Host 'remote_host' is known and matches the RSA host key.
debug1: Found key in /home/alexander/.ssh/known_hosts:26
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 DSA public key: /home/alexander/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /home/alexander/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/alexander/.ssh/id_ecdsa
debug1: Next authentication method: password
user@remote_host's password:
linux ssh authentication
On my local machine I have a public key stored in
.ssh/id_rsa.pub
To be able to log in to a remote machine I copy this key using ssh-copy-id
:
ssh-copy-id user@remote-host
On the remote host, I see two lines added to the file .ssh/authorized_keys
starting with ssh-dss
and ssh-rsa
, and ending with the local machine information.
However, when I now log in to the remote machine with
ssh user@remote-host
I am still asked for a password. Why is that and how can this be fixed?
- The file permissions of
authorized_keys
are correct. The following is the result of
ssh -v
:OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to xxx [xxx] port 22.
debug1: Connection established.
debug1: identity file /home/alexander/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alexander/.ssh/id_rsa-cert type -1
debug1: identity file /home/alexander/.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: identity file /home/alexander/.ssh/id_dsa-cert type -1
debug1: identity file /home/alexander/.ssh/id_ecdsa type -1
debug1: identity file /home/alexander/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.52
debug1: no match: dropbear_0.52
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
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: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA XXXX
debug1: Host 'remote_host' is known and matches the RSA host key.
debug1: Found key in /home/alexander/.ssh/known_hosts:26
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 DSA public key: /home/alexander/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: /home/alexander/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/alexander/.ssh/id_ecdsa
debug1: Next authentication method: password
user@remote_host's password:
linux ssh authentication
linux ssh authentication
edited Nov 8 '13 at 9:35
asked Nov 8 '13 at 9:05
Alex
1,724154270
1,724154270
The log only says that your client has offered the key to the server, but apparently the server didn't accept that, so it reverts to password authentication. the reasons for tjat should be on server side, maybe PubkeyAuthentication or AuthorizedKeysFile aren't set on the server?
– replay
Nov 8 '13 at 9:15
Permissions on authorized_keys file on remote host?
– jirib
Nov 8 '13 at 9:20
The permissions on the authorized_keys are correct, and unfortunately I have no log files available I can take a look (because the remote host runs a non-standard linux and is highly configured.). Which file(s) usually contain ssh settings?
– Alex
Nov 8 '13 at 9:34
1
I have found the error: The modes of the overlaying directories where incorrect! After fixing all the permissions and ownerships the passwordless ssh login works. Thanks for the suggestions.
– Alex
Nov 8 '13 at 9:52
So the .ssh dir must be600
permission and the files inside700
?
– Timo
Jan 23 at 9:55
add a comment |
The log only says that your client has offered the key to the server, but apparently the server didn't accept that, so it reverts to password authentication. the reasons for tjat should be on server side, maybe PubkeyAuthentication or AuthorizedKeysFile aren't set on the server?
– replay
Nov 8 '13 at 9:15
Permissions on authorized_keys file on remote host?
– jirib
Nov 8 '13 at 9:20
The permissions on the authorized_keys are correct, and unfortunately I have no log files available I can take a look (because the remote host runs a non-standard linux and is highly configured.). Which file(s) usually contain ssh settings?
– Alex
Nov 8 '13 at 9:34
1
I have found the error: The modes of the overlaying directories where incorrect! After fixing all the permissions and ownerships the passwordless ssh login works. Thanks for the suggestions.
– Alex
Nov 8 '13 at 9:52
So the .ssh dir must be600
permission and the files inside700
?
– Timo
Jan 23 at 9:55
The log only says that your client has offered the key to the server, but apparently the server didn't accept that, so it reverts to password authentication. the reasons for tjat should be on server side, maybe PubkeyAuthentication or AuthorizedKeysFile aren't set on the server?
– replay
Nov 8 '13 at 9:15
The log only says that your client has offered the key to the server, but apparently the server didn't accept that, so it reverts to password authentication. the reasons for tjat should be on server side, maybe PubkeyAuthentication or AuthorizedKeysFile aren't set on the server?
– replay
Nov 8 '13 at 9:15
Permissions on authorized_keys file on remote host?
– jirib
Nov 8 '13 at 9:20
Permissions on authorized_keys file on remote host?
– jirib
Nov 8 '13 at 9:20
The permissions on the authorized_keys are correct, and unfortunately I have no log files available I can take a look (because the remote host runs a non-standard linux and is highly configured.). Which file(s) usually contain ssh settings?
– Alex
Nov 8 '13 at 9:34
The permissions on the authorized_keys are correct, and unfortunately I have no log files available I can take a look (because the remote host runs a non-standard linux and is highly configured.). Which file(s) usually contain ssh settings?
– Alex
Nov 8 '13 at 9:34
1
1
I have found the error: The modes of the overlaying directories where incorrect! After fixing all the permissions and ownerships the passwordless ssh login works. Thanks for the suggestions.
– Alex
Nov 8 '13 at 9:52
I have found the error: The modes of the overlaying directories where incorrect! After fixing all the permissions and ownerships the passwordless ssh login works. Thanks for the suggestions.
– Alex
Nov 8 '13 at 9:52
So the .ssh dir must be
600
permission and the files inside 700
?– Timo
Jan 23 at 9:55
So the .ssh dir must be
600
permission and the files inside 700
?– Timo
Jan 23 at 9:55
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
You will need to cat out the contents to the remote host directory or it will not acknowledge the new key and chmod 700 (not 600) both .ssh directories (local and remote host).
After generating the new keypair, enter the command on the local host cat .ssh/id_rsa.pub | ssh <user>@<remotehost> 'cat >> .ssh/authorized_keys'
This will take the output of your authorized keys on your local machine and place it on the remote machine as well. Moreover, you'll need to ensure you have RWX access, and not just RW.
1
ssh-copy-id
does exactly the catting you describe (except for all public keys not just RSA) with some added errorchecking AND setting the permisssions for you.
– dave_thompson_085
Jul 7 '16 at 8:23
This will take the output of your authorized keys on your local machine
: No, you copy theid_rsa.pub
file content to authorized_keys on the remote.
– Timo
Jan 23 at 9:52
add a comment |
up vote
-2
down vote
try chmod 0600 ~/.ssh
And make sure your directory permissions are valid.
I have encountered directories of .ssh with ??????? options when doing an ls -l due to restoring from backups.
This is incorrect.chmod 0600 ~/.ssh
will make it so you can't evencd ~/.ssh
anymore. You probably meantchmod 0700 ~/.ssh
.
– dg99
Nov 8 '13 at 19:15
.ssh is chmod 700 and .ssh/authorized_keys chmod 640.
– GiannakopoulosJ
Jun 13 '16 at 21:50
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
You will need to cat out the contents to the remote host directory or it will not acknowledge the new key and chmod 700 (not 600) both .ssh directories (local and remote host).
After generating the new keypair, enter the command on the local host cat .ssh/id_rsa.pub | ssh <user>@<remotehost> 'cat >> .ssh/authorized_keys'
This will take the output of your authorized keys on your local machine and place it on the remote machine as well. Moreover, you'll need to ensure you have RWX access, and not just RW.
1
ssh-copy-id
does exactly the catting you describe (except for all public keys not just RSA) with some added errorchecking AND setting the permisssions for you.
– dave_thompson_085
Jul 7 '16 at 8:23
This will take the output of your authorized keys on your local machine
: No, you copy theid_rsa.pub
file content to authorized_keys on the remote.
– Timo
Jan 23 at 9:52
add a comment |
up vote
0
down vote
You will need to cat out the contents to the remote host directory or it will not acknowledge the new key and chmod 700 (not 600) both .ssh directories (local and remote host).
After generating the new keypair, enter the command on the local host cat .ssh/id_rsa.pub | ssh <user>@<remotehost> 'cat >> .ssh/authorized_keys'
This will take the output of your authorized keys on your local machine and place it on the remote machine as well. Moreover, you'll need to ensure you have RWX access, and not just RW.
1
ssh-copy-id
does exactly the catting you describe (except for all public keys not just RSA) with some added errorchecking AND setting the permisssions for you.
– dave_thompson_085
Jul 7 '16 at 8:23
This will take the output of your authorized keys on your local machine
: No, you copy theid_rsa.pub
file content to authorized_keys on the remote.
– Timo
Jan 23 at 9:52
add a comment |
up vote
0
down vote
up vote
0
down vote
You will need to cat out the contents to the remote host directory or it will not acknowledge the new key and chmod 700 (not 600) both .ssh directories (local and remote host).
After generating the new keypair, enter the command on the local host cat .ssh/id_rsa.pub | ssh <user>@<remotehost> 'cat >> .ssh/authorized_keys'
This will take the output of your authorized keys on your local machine and place it on the remote machine as well. Moreover, you'll need to ensure you have RWX access, and not just RW.
You will need to cat out the contents to the remote host directory or it will not acknowledge the new key and chmod 700 (not 600) both .ssh directories (local and remote host).
After generating the new keypair, enter the command on the local host cat .ssh/id_rsa.pub | ssh <user>@<remotehost> 'cat >> .ssh/authorized_keys'
This will take the output of your authorized keys on your local machine and place it on the remote machine as well. Moreover, you'll need to ensure you have RWX access, and not just RW.
answered Jul 7 '16 at 4:21
SomeGuy
212112
212112
1
ssh-copy-id
does exactly the catting you describe (except for all public keys not just RSA) with some added errorchecking AND setting the permisssions for you.
– dave_thompson_085
Jul 7 '16 at 8:23
This will take the output of your authorized keys on your local machine
: No, you copy theid_rsa.pub
file content to authorized_keys on the remote.
– Timo
Jan 23 at 9:52
add a comment |
1
ssh-copy-id
does exactly the catting you describe (except for all public keys not just RSA) with some added errorchecking AND setting the permisssions for you.
– dave_thompson_085
Jul 7 '16 at 8:23
This will take the output of your authorized keys on your local machine
: No, you copy theid_rsa.pub
file content to authorized_keys on the remote.
– Timo
Jan 23 at 9:52
1
1
ssh-copy-id
does exactly the catting you describe (except for all public keys not just RSA) with some added errorchecking AND setting the permisssions for you.– dave_thompson_085
Jul 7 '16 at 8:23
ssh-copy-id
does exactly the catting you describe (except for all public keys not just RSA) with some added errorchecking AND setting the permisssions for you.– dave_thompson_085
Jul 7 '16 at 8:23
This will take the output of your authorized keys on your local machine
: No, you copy the id_rsa.pub
file content to authorized_keys on the remote.– Timo
Jan 23 at 9:52
This will take the output of your authorized keys on your local machine
: No, you copy the id_rsa.pub
file content to authorized_keys on the remote.– Timo
Jan 23 at 9:52
add a comment |
up vote
-2
down vote
try chmod 0600 ~/.ssh
And make sure your directory permissions are valid.
I have encountered directories of .ssh with ??????? options when doing an ls -l due to restoring from backups.
This is incorrect.chmod 0600 ~/.ssh
will make it so you can't evencd ~/.ssh
anymore. You probably meantchmod 0700 ~/.ssh
.
– dg99
Nov 8 '13 at 19:15
.ssh is chmod 700 and .ssh/authorized_keys chmod 640.
– GiannakopoulosJ
Jun 13 '16 at 21:50
add a comment |
up vote
-2
down vote
try chmod 0600 ~/.ssh
And make sure your directory permissions are valid.
I have encountered directories of .ssh with ??????? options when doing an ls -l due to restoring from backups.
This is incorrect.chmod 0600 ~/.ssh
will make it so you can't evencd ~/.ssh
anymore. You probably meantchmod 0700 ~/.ssh
.
– dg99
Nov 8 '13 at 19:15
.ssh is chmod 700 and .ssh/authorized_keys chmod 640.
– GiannakopoulosJ
Jun 13 '16 at 21:50
add a comment |
up vote
-2
down vote
up vote
-2
down vote
try chmod 0600 ~/.ssh
And make sure your directory permissions are valid.
I have encountered directories of .ssh with ??????? options when doing an ls -l due to restoring from backups.
try chmod 0600 ~/.ssh
And make sure your directory permissions are valid.
I have encountered directories of .ssh with ??????? options when doing an ls -l due to restoring from backups.
answered Nov 8 '13 at 10:32
user2927304
1
1
This is incorrect.chmod 0600 ~/.ssh
will make it so you can't evencd ~/.ssh
anymore. You probably meantchmod 0700 ~/.ssh
.
– dg99
Nov 8 '13 at 19:15
.ssh is chmod 700 and .ssh/authorized_keys chmod 640.
– GiannakopoulosJ
Jun 13 '16 at 21:50
add a comment |
This is incorrect.chmod 0600 ~/.ssh
will make it so you can't evencd ~/.ssh
anymore. You probably meantchmod 0700 ~/.ssh
.
– dg99
Nov 8 '13 at 19:15
.ssh is chmod 700 and .ssh/authorized_keys chmod 640.
– GiannakopoulosJ
Jun 13 '16 at 21:50
This is incorrect.
chmod 0600 ~/.ssh
will make it so you can't even cd ~/.ssh
anymore. You probably meant chmod 0700 ~/.ssh
.– dg99
Nov 8 '13 at 19:15
This is incorrect.
chmod 0600 ~/.ssh
will make it so you can't even cd ~/.ssh
anymore. You probably meant chmod 0700 ~/.ssh
.– dg99
Nov 8 '13 at 19:15
.ssh is chmod 700 and .ssh/authorized_keys chmod 640.
– GiannakopoulosJ
Jun 13 '16 at 21:50
.ssh is chmod 700 and .ssh/authorized_keys chmod 640.
– GiannakopoulosJ
Jun 13 '16 at 21:50
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f99327%2fwhy-is-my-ssh-connection-unauthorized-although-i-have-updated-my-key-on-the-remo%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
The log only says that your client has offered the key to the server, but apparently the server didn't accept that, so it reverts to password authentication. the reasons for tjat should be on server side, maybe PubkeyAuthentication or AuthorizedKeysFile aren't set on the server?
– replay
Nov 8 '13 at 9:15
Permissions on authorized_keys file on remote host?
– jirib
Nov 8 '13 at 9:20
The permissions on the authorized_keys are correct, and unfortunately I have no log files available I can take a look (because the remote host runs a non-standard linux and is highly configured.). Which file(s) usually contain ssh settings?
– Alex
Nov 8 '13 at 9:34
1
I have found the error: The modes of the overlaying directories where incorrect! After fixing all the permissions and ownerships the passwordless ssh login works. Thanks for the suggestions.
– Alex
Nov 8 '13 at 9:52
So the .ssh dir must be
600
permission and the files inside700
?– Timo
Jan 23 at 9:55