CODEWITHSUNDEEP
macossshremote-access
Arefe
Arefe

Reputation: 12397

Setup passphraseless ssh

I was trying to run Hadoop in Mac OS and I get the following errors, 

$ hstart


WARNING: Attempting to start all Apache Hadoop daemons as chaklader in 10 seconds.
WARNING: This is not a recommended production deployment configuration.
WARNING: Use CTRL-C to abort.
Starting namenodes on [localhost]
localhost: Permission denied (publickey,password,keyboard-interactive).
Starting datanodes
localhost: Permission denied (publickey,password,keyboard-interactive).
Starting secondary namenodes [macs-MacBook-Pro.local]
macs-MacBook-Pro.local: Permission denied (publickey,password,keyboard-interactive).
2018-08-14 13:59:34,949 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Starting resourcemanager
Starting nodemanagers
localhost: Permission denied (publickey,password,keyboard-interactive).

I looked into the Google and find a similar post. I mentioned that Permission denied is the error, and I didn't set up passwordless ssh correctly. For example, ssh localhost should not ask for a password.

I run the ssh localhost and it did ask for the password. As a solution to the problem, it was mentioned to execute the command, 

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

I did that and afterward when I run the ssh localhost, I was asked for the passphrase (than the password). 

$ ssh localhost

Enter passphrase for key '/Users/chaklader/.ssh/id_rsa': 
Last login: Tue Aug 14 14:03:30 2018 from ::1

The original problem was not solved. There was another post mentioned to execute the command chmod og-wx ~/.ssh/authorized_keys and after I did that, it still keeps that same.

I tried to check what is inside the id_rsa and find the info, 

$ cat ~/.ssh/id_rsa.pub
ssh-rsa 

AAAAB3NzaC1yc2EAAAADAQABAAABAQDB/1Ryk4mB2/9rxpvF21JWKBOyx+hgo572zp9ZNcLmj1FcNN9saJ0AfYcmkILowEoCKgzOCbAvapd+JsPomPMsuKD37AGvfF88YWAjKPYOg3wo5JMwIp/CEyk349satGWUy+Q99288iJcS5NKkhLEN1bMOyIpgbFFxmpCdFXNSl9UfeCN4oyndWJzmnHkI6C9mu4BWibcW3PkKkwI2HVPop14m3jRjHJvmwGzRQxp/bjUVRqSZ52KTuVMYRrCsKdd048tBHOK0ujjshpBCoedtFoXt3xP0B78WZyvgFr2Pj9DrgdFI+T7gkJUv4xbmtKfCOZR7yFVwoUtgAF5k/FC1 [email protected]


$ cat ~/.ssh/authorized_keys 
ssh-rsa 

AAAAB3NzaC1yc2EAAAADAQABAAABAQDB/1Ryk4mB2/9rxpvF21JWKBOyx+hgo572zp9ZNcLmj1FcNN9saJ0AfYcmkILowEoCKgzOCbAvapd+JsPomPMsuKD37AGvfF88YWAjKPYOg3wo5JMwIp/CEyk349satGWUy+Q99288iJcS5NKkhLEN1bMOyIpgbFFxmpCdFXNSl9UfeCN4oyndWJzmnHkI6C9mu4BWibcW3PkKkwI2HVPop14m3jRjHJvmwGzRQxp/bjUVRqSZ52KTuVMYRrCsKdd048tBHOK0ujjshpBCoedtFoXt3xP0B78WZyvgFr2Pj9DrgdFI+T7gkJUv4xbmtKfCOZR7yFVwoUtgAF5k/FC1 [email protected]

The remote login is checked

enter image description here

I debugged and get the info,

$ ssh -v localhost

OpenSSH_7.5p1, LibreSSL 2.5.4
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /Users/chaklader/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/chaklader/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/chaklader/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/chaklader/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/chaklader/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/chaklader/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/chaklader/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/chaklader/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5
debug1: match: OpenSSH_7.5 pat OpenSSH* compat 0x04000000
debug1: Authenticating to localhost:22 as 'chaklader'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:R9cek2xWHJN6rgvBKr4JZMKisZbifnxvPoSzIb5z5Ik
debug1: Host 'localhost' is known and matches the ECDSA host key.
debug1: Found key in /Users/chaklader/.ssh/known_hosts:2
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/chaklader/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279

The key is generated as follows,

ssh-keygen -t rsa

What is here missed?

Note

I find another way to generate the keys,

ssh-keygen -t dsa -P ” -f ~/.ssh/id_dsa

Should I try this method?

Upvotes: 1

Views: 823

Answers (1)

l&#39;L&#39;l
l&#39;L&#39;l

Reputation: 47169

The advantage of course of using a passphrase on an RSA key is that it gives you some protection if someone somehow obtains your private key (the passphrase should prevent them from using it). Although that's is a nice idea, it defeats the purpose of a 'passwordless' ssh login. If you have to enter a passphrase each time the key is used then it's not exactly passwordless one would argue. If someone is able to access the private key, you might assume they would have full access to the machine where it resides or you were careless with the keys.

There are some 'safeguarding' measures you can take perhaps in regards to private keys; really the most important thing is to keep private keys only where needed and not have them laying around your machines.

Upvotes: 1

Related Questions