Permission Denied (Publickey) from OS X to Ubuntu

Question

I am working on an Electron app that has a package.json file in the root folder. There are 3 build variants that we release for the same.

1. Base App
2. Base App + Feature1
3. Base App + Feature1 + Feature2

I am facing an issue since point 3 needs some npm modules that my Base app doesn't need. Hence there is a change in package.json file for each build variant. Here are my doubts,

• Can there be multiple package.json files which will build specific build variant?
• Can this be done using one package.json file, If yes, how?

Thanks in advance.

Solution

Check the following in your servers's sshd_config

PubkeyAuthentication yes
AuthorizedKeysFile     %h/.ssh/authorized_keys

For some reason, your sshd is trying to open /root/.ssh/authorized_keys file (from you sshd log) though you are trying to log in with user 'git', so it should actually read /home/git/.ssh/authorized_keys. I suspect the AuthorizedKeysFile entry is miss-configured. Typically, AuthorizedKeysFile entry does not need to be set as it defaults to above value.

Comments

[Jeff Kranenburg]

The /var/log/auth.log is empty - if that is what you are referring to?

[Jeff Kranenburg]

Still no luck in getting auth.log to show anything - changed LogLevel from INFO to DEUG

[Jeff Kranenburg]

@dawud Is this what you require?

[Jeff Kranenburg]

my ~/.ssh/ folder is under the git user home folder and I am wanting to log in as [email protected]

[dawud]

access.redhat.com/solutions/83933

[Jeff Kranenburg]

Still no luck - added UseDNS no to my sshd_conf file

[sardean]

By what means did you copy your public key into the authorized_keys file on the server? Also, can you verify that you are using the correct user accounts on both client and server side i.e. use whoami on your client to make sure you are in the account of the user that's key you've copied to the server. Additionally, make sure the user account you are attempting to authenticate via ssh on the server has to contain the public key in its authorized_keys.

[Jeff Kranenburg]

Hi @dean I have used several ways to copy. 1) I did a copy and paste with mouse and cmd-c / cmd-v in terminal. I have also done cat ~/.ssh/id_rsa.pub | ssh [email protected] 'cat >> ~/.ssh/authorized_keys' 2) whoami and pwd are both in the expected paths. 3) the authorised_keys has the id_rsa.pub key in it.

[Jeff Kranenburg]

ok - I just re did the cat command for the I don't how many-th time and it accepted it. - No idea why this time is different

[Jeff Kranenburg]

What does this achieve? It is great that you provided an answer, but would be good to explain what your answer achieves - kinds the point here :-)

[peterh]

Please explain why and how answers your code snippet the question. Only copypasting some lines of a script is not enough here.

[dave_thompson_085]

The question says password auth works which implies, and the log proves, that the server already has a perfectly good and already-recorded RSA key. Changing the server key(s) would cause problems, namely a "possible attack" mismatch, not solve them.

[kasperd]

@JeffKranenburg As far as I can tell what these lines do is not to solve the problem but rather to add another one, which is likely going to be harder to solve than the first one.

[kasperd]

Another possibility is that the user's home directory is specified incorrectly in /etc/passwd.