SFTP authorized_keys - no supply password during sftp

[DShinn]

Having difficulties setting up this one particular SFTP connection without supplying our password. The id_rsa.pub file has been generated and sent to several other sites - which works fine. I have tried several different permissions on the .ssh directory and authorized_keys file on the remote host. The users .ssh directory on the local host has 755 and the id_rsa permission is 600. On the remote host, there are two .ssh directories

- /.ssh (permissions 700)
- /.ssh/authorized_keys (600)

- /incoming/.ssh (permissions 700)
- /incoming/.ssh/authorized_keys (600)

I have tested with the /incoming/.ssh moved to another directory name - that has not helped either.

On our side - I have used the -vvv option and have attached one of the attempts to this message.

Any assistance with this would be greatly appreciated. Points will be assigned!

Thank-you for your assistance!

Dorothy

[Steven E. Protter]

Shalom Dorothy,

http://www.hpux.ws/?p=10

Permissions are key. If ownership or permissions is off to any degree this will not work.

try ssh -vvv for diagnostic purposes.

SEP

[DShinn]

Thank-you for the response. The attached document is from a SFTP with the -vvv option. So when there are two .ssh directories on the remote host - which one will it try to access for authentication? When I SFTP into the remote host - I am placed in the /incoming directory which has one of the .ssh directories. The directory above the "incoming" also has a .ssh directory.

Thanks,

Dorothy

[Matti_Kurkela · Accepted solution]

The correct location of the .ssh directory is determined by the sshd server configuration on the remote host. The default is $HOME/.ssh of the user. This can be changed, but it is very rare.

The fact that you can write to /.ssh (which is supposed to be the root directory of the system) indicates that the remote server is probably chrooted. The sysadmin of the remote site might have done other non-default configurations too: it is best to ask him/her.

The remote sysadmin can even disable key authentication entirely, if he/she wishes to do so. The "authentications that can continue" information in the debug output is not necessarily true. For example, if password authentication has been disabled from the server side, the client can still be offered a "password" authentication method; it just will never succeed.

The remote server will *not* tell you exactly why your connection attempt is denied. This is a security issue: until you've successfully authenticated yourself, "you" might be an intruder trying to find a way into the system. No reason to offer clues to an unknown person or malware which may be attempting an unauthorized entry, right? Instead, the reason for rejection is stored into the remote server's logs - if you are not an intruder, you can contact the remote sysadmin and troubleshoot the problem together with him/her.

MK

[DShinn]

Changed the /incoming directory to have the permissions of 700. One of the .ssh directories is located under this subdirectory. Once I changed the permissions on the incoming directory - the authentication worked!

Thanks to all, for your assistance!

Dorothy