0

Short Summary:

I am trying to connect to a Mac mini from a Windows PC through SSH to execute a shell script on the Mac mini. I do not want to store the user password in my script. I would rather use the passphrase that protects the private key.


I have everything set up as described in these tutorials:

https://www.techrepublic.com/article/how-to-generate-ssh-keys-on-macos-mojave/

and here (since ssh-copy-id didn't work)

https://www.techrepublic.com/article/how-to-manually-add-ssh-keys-for-key-authentication/


The Process:

  • Generate key on client using ssh-keygen -t rsa

  • Enter passphrase and verify it

  • Make file "authorized_keys" in /Users/Username/.ssh on host and copy public key from client into it

  • chmod 640 authorized_keys and chmod 700 .ssh

Also:

  • Enable remote connection on Mac mini

Result:

I can connect to my client but the shell asks me for the user password instead of the private key passphrase.

ssh -vv result:

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Users\Developer>ssh -vv systemtest@139.22.224.52
OpenSSH_7.9p1, OpenSSL 1.1.1a  20 Nov 2018
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 139.22.224.52 is address
debug2: ssh_connect_direct
debug1: Connecting to 139.22.224.52 [139.22.224.52] port 22.
debug1: Connection established.
debug1: identity file /c/Users/Developer/.ssh/id_rsa type 0
debug1: identity file /c/Users/Developer/.ssh/id_rsa-cert type -1
debug1: identity file /c/Users/Developer/.ssh/id_dsa type -1
debug1: identity file /c/Users/Developer/.ssh/id_dsa-cert type -1
debug1: identity file /c/Users/Developer/.ssh/id_ecdsa type -1
debug1: identity file /c/Users/Developer/.ssh/id_ecdsa-cert type -1
debug1: identity file /c/Users/Developer/.ssh/id_ed25519 type -1
debug1: identity file /c/Users/Developer/.ssh/id_ed25519-cert type -1
debug1: identity file /c/Users/Developer/.ssh/id_xmss type -1
debug1: identity file /c/Users/Developer/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9
debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000
debug2: fd 4 setting O_NONBLOCK
debug1: Authenticating to 139.22.224.52:22 as 'systemtest'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-
group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sh
a2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sh
a2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,aes256-cbc,aes192-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,aes256-cbc,aes192-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-1
28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-1
28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-
group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-1
28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-1
28@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:BAHjy5hPVFMIB7JF+rwobrjLgXQ30C5zgoNlBC5ENRw
debug1: Host '139.22.224.52' is known and matches the ECDSA host key.
debug1: Found key in /c/Users/Developer/.ssh/known_hosts:3
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /c/Users/Developer/.ssh/id_rsa RSA SHA256:M7GM7bLi357XePOpkX+E6AhGD7Ay/JZ0xSBwSgan9kY
debug1: Will attempt key: /c/Users/Developer/.ssh/id_dsa
debug1: Will attempt key: /c/Users/Developer/.ssh/id_ecdsa
debug1: Will attempt key: /c/Users/Developer/.ssh/id_ed25519
debug1: Will attempt key: /c/Users/Developer/.ssh/id_xmss
debug2: pubkey_prepare: done
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>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /c/Users/Developer/.ssh/id_rsa RSA SHA256:M7GM7bLi357XePOpkX+E6AhGD7Ay/JZ0xSBwSgan9kY
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /c/Users/Developer/.ssh/id_dsa
debug1: Trying private key: /c/Users/Developer/.ssh/id_ecdsa
debug1: Trying private key: /c/Users/Developer/.ssh/id_ed25519
debug1: Trying private key: /c/Users/Developer/.ssh/id_xmss
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:

ls -al in .ssh directory in mac result

systemtestsmini:.ssh systemtest$ ls -al

total 24

drwx------   5 systemtest  staff   160 28 Aug 04:42 .

drwxr-xr-x+ 20 systemtest  staff   640 28 Aug 04:03 ..

-rw-------   1 systemtest  staff  1896 28 Aug 04:05 id_rsa

-rw-r--r--   1 systemtest  staff   419 28 Aug 04:05 id_rsa.pub

-rw-r--r--   1 systemtest  staff   175 28 Aug 04:20 known_hosts
  • So, when you say "client" you mean the Windows PC, and when you say "host" you mean the Mac mini? If so, then in your final sentence, why are you talking about connecting to your client? Also, why are you talking about running a "batch file" on a Mac? "batch files" are a DOS/Windows concept. Did you mean "shell script" or "AppleScript script"? Where did you store your private key in Windows when you generated it? Did you make sure you set things up in your Windows SSH client such that it would use that private key when connecting to the Mac mini? – Spiff Aug 29 at 10:09
  • When I say I am trying to connect to a macMini from a Windows PC that means the mac is the client and the windows is the host. So the Windows PC is the machine that I am using to connect to the macMini. You're right about the batch file though, I got those names confused. I was just talking about a very simple shell script on the mac. The script isn't the main problem though. The private key that I generated on the mac is stored in the default directory /Users/USERNAME/.ssh. The public key from the mac is stored on the Windows PC in /Users/USERNAME/.ssh/authorized_keys. – Spook Aug 29 at 10:53
  • paste the result of `ssh -vv <destination ip-address> here – Prado Aug 29 at 11:10
  • @Prado Everything? It's quite long. – Spook Aug 29 at 11:16
  • Please edit your question to include the ssh -vv output. Format it as a code block. Don't worry about how long it is; lots of ssh questions include that output. It would also be helpful for you to run ls -al in the .ssh directory on the mac and include that output. – Kenster Aug 29 at 12:18
0

It sounds like you may have swapped the client and server roles in your mind and thus accidentally performed the client steps on the server and the server steps on the client. It sounds like you generated the key pair on the machine you wanted to connect to (the Mac mini), and then copied the public key to the machine you wanted to connect from (the Windows PC).

From the additional logs and info you provided, it seems like you already have an RSA key pair on your Windows PC at C:\Users\Developer\.ssh\id_rsa (and there should be an id_rsa.pub in the same location)

You should copy that id_rsa.pub from the Windows box to the Mac, and then append it to the ~/.ssh/authorized_keys file under the home directory of the user account you want to log into on the Mac.

Edited to add more explanation per your follow-up question:

Think of it this way: Your private key is private. You keep it to yourself. You only keep it on your primary machine that you sit at. You even protect it "at rest" (i.e. on your local disk) by encrypting it with a passphrase so that even if someone steals the file, they can't use your private key.

Your public key is public. You distribute your public key to all the servers you want to be able to log into, and mark it as one that is authorized to log you in. But when you try to log in you still have to prove you're really you, so you have to prove that you possess the private key that forms the matched set with the authorized public key. (This is done mathematically in a way that doesn't reveal the private key.)

The reason you can log into the Mac, even without your keys set up right, is that you fall back to not using those keys at all. You fall back to good ol' username+password credentials for authentication: The same credentials that the Mac's GUI login window accepts.

  • This is the first SSH connection I am setting up myself and the two machines are physically adjacent, which might explain the mix up. Since it looks like I haven't understood SSH correctly yet, would you mind reviewing my thought process? I thought you have the private key on the machine you want to connect to and when someone tries to connect they send the public key to identify and the passphrase to verify. Since the Mac is the singular machine I want to connect to I thought it needed to be the one to hold the private key. Also how does this explain that I can already connect to the Mac? – Spook Aug 29 at 13:19
  • @Spook Answering your followup question was too much for the comment box so I edited my main Answer to address your further questions. – Spiff Aug 29 at 15:40
  • Thanks for clarifying. Especially the last part because me being able to connect despite having it set up wrong confused me a lot. Everything makes sense now. – Spook Aug 29 at 17:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.