ctlow

Q: SSH Permissions

I know this has been done, but I can't find it either here or elsewhere.

I just reinstalled my SSH protocols after replacing a hard drive on the server and restoring (data only) from a Time Machine backup. I seemed to have to start the SSH process from scratch.

I have outlined the procedures (which I learned here) at ctlow.ca/SSH-VPN_MacOSX.html.

It worked, but when I log in from the client, it just goes through without asking for passwords. I think it asked for one password the first time, the private key(?) password, but it used to ask for that (in a little text box, echoed) every time, and then the server password(?) in Terminal itself, not echoed.

Now, neither of those are happening.

So, I found some notes I had made about this, and reset permissions to the .ssh folder as 700 and to the files inside it as 600, on both the server and the client.

It ends up looking like this:

 

ClientComputer:~ ClientID$ ls -ael .ssh

total 24

drwx------   5 ClientID  staff   170 11 Sep 15:24 .

drwxr-x-wx+ 24 ClientID  staff   816 13 Sep 08:26 ..

0: group:everyone deny delete

-rw-------@  1 ClientID  staff    32 10 Feb  2012 config

-rw-------   1 ClientID  staff  1766 11 Sep 15:11 id_rsa

-rw-------   1 ClientID  staff   818 11 Sep 15:33 known_hosts

====

ServerComputer:~ ServerID$ ls -ael .ssh

total 16

drwx------   4 ServerID  staff  136 11 Sep 15:28 .

drwxr-xr-x@ 25 ServerID  staff  850 11 Sep 15:30 ..

0: group:everyone deny delete

-rw-------   1 ServerID  staff  416 11 Sep 15:28 authorized_keys

-rw-------   1 ServerID  staff  391 11 Sep 15:26 known_hosts

 

I don't think that I'm particularly at risk, but I was happy with having to use two passwords to log into the SSH tunnel. Any idea why I'm being asked for no passwords now? (I did specify a password when generating the keys.)

Thank you.

Charles

P.S. The client is running 10.9, the server 10.11.

P.P.S. The info window for the client-user showed "shared folder" which I don't know how it got like that, and have unchecked the box. I doubt if that's related to my question.

iMac, OS X El Capitan (10.11.6)

Posted on Sep 16, 2016 2:11 PM

Close

Q: SSH Permissions

  • All replies
  • Helpful answers

Page 1 Next
  • by etresoft,Helpful

    etresoft etresoft Sep 16, 2016 7:13 PM in response to ctlow
    Level 7 (29,320 points)
    Mac OS X
    Sep 16, 2016 7:13 PM in response to ctlow

    Hello Charles,

    I'm not sure what you were doing before, but it sounds correct now.

     

    Most of the internet uses the same set of instructions that tell people not to use a passphrase on the private key. It is a hassle running ssh-agent and most people struggle enough as it is with ssh. But on OS X, the Keychain serves as ssh-agent. So, when you provide a passphrase for your private key, the first time you access it, you will be prompted (via a nice Aqua user interface) for your passphrase. You can provide that and save it in the keychain, from whence, you will never be asked again. Then, if the rest of your ssh stuff is correct, it will all go through as you describe. That sounds like what is happening now and that is how it should work.

     

    If I were to speculate, I think maybe before you were running some custom build of ssh and a command-line version of ssh-agent. That would explain the double terminal passwords, one being echoed and one not.

  • by Loner T,Helpful

    Loner T Loner T Sep 16, 2016 7:18 PM in response to ctlow
    Level 7 (24,409 points)
    Safari
    Sep 16, 2016 7:18 PM in response to ctlow

    Are the public keys of Client in the authorized_keys on the Server? You can also run ssh with -v (or -vv or -vvv) and check the handshake between client and server.

  • by ctlow,

    ctlow ctlow Sep 16, 2016 7:28 PM in response to etresoft
    Level 1 (12 points)
    Mac OS X
    Sep 16, 2016 7:28 PM in response to etresoft

    Thanks, etresoft,

    Before getting specific on the technicalities, my concern is that if someone stole my laptop (client) then they could open the SSH tunnel.

    Apar from that, having it log on by itself is very convenient. I used to get  a message in Terminal about something not able to be saved in Keychain. Now I don't. And I didn't mind the inconvenience.

    I was taught to do this by rote, without really understanding it. I vaguely understand about private-public key pairs, but beyond that am not a Terminal Bash expert and for example have never typed "ssh-agent" on the command line. (The only command lines I've used are in my explanatory web page, original post.)

    But nothing has changed - that I know - except that on the new iMac hard drive, I upgraded from OS X 10.9 to 10.11. I run the tunnel from Terminal, using an ssh command.

    Anyway, this isn't life or death. I'm must trying to protect my server by keeping the tunnel password-protected without Keychain saving anything.

    Much obliged,

    Charles

  • by BobHarris,

    BobHarris BobHarris Sep 16, 2016 7:57 PM in response to ctlow
    Level 6 (19,628 points)
    Mac OS X
    Sep 16, 2016 7:57 PM in response to ctlow

    Before getting specific on the technicalities, my concern is that if someone stole my laptop (client) then they could open the SSH tunnel.

    If they can BOTH steal your Mac and get access to it as "You", then yes, they will be able to get into your server.

     

    System Preferences -> Security -> FileVault to keep them from removing your disk and accessing your ssh-keys and keychain.

     

    Require a password when waking up or after screen saver has kicked in.

     

    And that should keep your Mac fairly safe from theft.

     

    And you should verify with ssh -v server.address and look for Authentication entries to verify it is using your ssh-keys

  • by ctlow,

    ctlow ctlow Sep 16, 2016 8:03 PM in response to Loner T
    Level 1 (12 points)
    Mac OS X
    Sep 16, 2016 8:03 PM in response to Loner T

    Loner T, as you may have seen in my reply to etresoft, I don't really know what I'm doing.

    So, the answer to your question is "yes". I've inspected authorized_keys on the server and known_hosts on the client, and the public (server) key is indeed contained in the private (client) key.

    If I used the -v argument ("verbose"?), or multiple v's, I wouldn't know what to do with the output. I just tried it a moment ago and with all of the other arguments it does produce a lot of lines. I would have to "redact" them prior to posting here, but am prepared to do that.

    Thank you.

    Charles

  • by Loner T,

    Loner T Loner T Sep 16, 2016 8:52 PM in response to ctlow
    Level 7 (24,409 points)
    Safari
    Sep 16, 2016 8:52 PM in response to ctlow

    Please remove any personal information as you see fit, before you post the output of the ssh -v session.

  • by etresoft,

    etresoft etresoft Sep 16, 2016 8:52 PM in response to ctlow
    Level 7 (29,320 points)
    Mac OS X
    Sep 16, 2016 8:52 PM in response to ctlow

    Hello again Charles,

    The private key passphrase is secured in your keychain, which is, itself, encrypted with your login password. The vast majority of ssh users in the world have no passphrase at all.

     

    As far as I can tell, everything is working properly.

  • by ctlow,

    ctlow ctlow Sep 17, 2016 5:54 AM in response to Loner T
    Level 1 (12 points)
    Mac OS X
    Sep 17, 2016 5:54 AM in response to Loner T

    Thanks again Loner T. I think I have removed all identifying information from the following "ssh -v" output. (The actual command is more complicated, as in it uses "-p" and several "-L"s.)

     

    OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

    debug1: Reading configuration data /Users/UserName/.ssh/config

    debug1: /Users/UserName/.ssh/config line 1: Applying options for *

    debug1: Reading configuration data /etc/ssh_config

    debug1: /etc/ssh_config line 20: Applying options for *

    debug1: Connecting to {dynamic-IP} {IPAddress} port 12345.

    debug1: Connection established.

    debug1: identity file /Users/UserName/.ssh/id_rsa type -1

    debug1: identity file /Users/UserName/.ssh/id_rsa-cert type -1

    debug1: identity file /Users/UserName/.ssh/id_dsa type -1

    debug1: identity file /Users/UserName/.ssh/id_dsa-cert type -1

    debug1: Enabling compatibility mode for protocol 2.0

    debug1: Local version string SSH-2.0-OpenSSH_6.2

    debug1: Remote protocol version 2.0, remote software version OpenSSH_6.9

    debug1: match: OpenSSH_6.9 pat OpenSSH*

    debug1: SSH2_MSG_KEXINIT sent

    debug1: SSH2_MSG_KEXINIT received

    debug1: kex: server->client aes128-ctr hmac-sha1-etm@openssh.com none

    debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none

    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent

    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

    debug1: Server host key: RSA {RSA-key}

    debug1: Host '[{dynamic-IP}]:12345' is known and matches the RSA host key.

    debug1: Found key in /Users/UserName/.ssh/known_hosts:2

    debug1: ssh_rsa_verify: signature correct

    debug1: SSH2_MSG_NEWKEYS sent

    debug1: expecting SSH2_MSG_NEWKEYS

    debug1: SSH2_MSG_NEWKEYS received

    debug1: SSH2_MSG_SERVICE_REQUEST sent

    debug1: SSH2_MSG_SERVICE_ACCEPT received

    debug1: Authentications that can continue: publickey,keyboard-interactive

    debug1: Next authentication method: publickey

    debug1: Offering RSA public key: /Users/UserName/.ssh/id_rsa

    debug1: Server accepts key: pkalg ssh-rsa blen {xxx}

    debug1: Authentication succeeded (publickey).

    Authenticated to {dynamic-IP} ({IPAddress}:12345).

    debug1: Local connections to LOCALHOST:23456 forwarded to remote address localhost:6789

    debug1: Local forwarding listening on ::1 port 23456.

    debug1: channel 0: new [port listener]

    debug1: Local forwarding listening on 127.0.0.1 port 23456.

    debug1: channel 1: new [port listener]

    debug1: Local connections to LOCALHOST:34567 forwarded to remote address localhost:7891

    debug1: Local forwarding listening on ::1 port 34567.

    debug1: channel 2: new [port listener]

    debug1: Local forwarding listening on 127.0.0.1 port 34567.

    debug1: channel 3: new [port listener]

    debug1: Local connections to LOCALHOST:45678 forwarded to remote address localhost:5678

    debug1: Local forwarding listening on ::1 port 45678.

    debug1: channel 4: new [port listener]

    debug1: Local forwarding listening on 127.0.0.1 port 45678.

    debug1: channel 5: new [port listener]

    debug1: channel 6: new [client-session]

    debug1: Requesting no-more-sessions@openssh.com

    debug1: Entering interactive session.

    debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0

    debug1: Sending environment.

    debug1: Sending env LANG = en_CA.UTF-8

  • by ctlow,

    ctlow ctlow Sep 17, 2016 5:56 AM in response to BobHarris
    Level 1 (12 points)
    Mac OS X
    Sep 17, 2016 5:56 AM in response to BobHarris

    Thanks, Bob. It's gradually sinking into my thick cranium that the double-password procedures which occurred prior to my disk/OS upgrade were the abnormality, not this.

    If anyone wishes my not-so-interesting personal info badly enough to break into my laptop, then they can do so. I'm leery of FileVault - seems one more thing to go wrong, and if it corrupts, then I've lost everything. I have no familiarity with it, however.

     

    Also, if my laptop were stolen, I could change the SSH port on the router.

     

    Charles

  • by etresoft,

    etresoft etresoft Sep 17, 2016 9:36 AM in response to ctlow
    Level 7 (29,320 points)
    Mac OS X
    Sep 17, 2016 9:36 AM in response to ctlow

    Hello again ctlow,

    There is no reason to be wary of FileVault. It is definitely proven itself to be reliable. You should also have a Time Machine backup - and it should be encrypted with FileVault too.

     

    Even if you don't turn on Time Machine, your keychain is already encrypted. If your laptop were stolen, your ssh private key would be in accessible. They would have to steal both your laptop and your password. They could still access your personal files, but they couldn't get to anything in the keychain. Now, if you had FileVault, they wouldn't even have your files.

     

    Changing ports would be a waste of time. I don't know where your server is accessible from. But any public services on it will be discovered, no matter what port they are on. Hackers routinely use port scanning software to check all of them. They have scripts and infinite number of servers to do the work. They have plenty of time and resources available.

  • by BobHarris,

    BobHarris BobHarris Sep 17, 2016 9:48 AM in response to ctlow
    Level 6 (19,628 points)
    Mac OS X
    Sep 17, 2016 9:48 AM in response to ctlow

    I'm leery of FileVault - seems one more thing to go wrong, and if it corrupts, then I've lost everything. I have no familiarity with it, however.

    If you have a laptop and take it with you, coffee shops, work, vacations, etc..., then having FileVault enabled would be strongly recommended, as laptops can take walks the owner never expected.

     

    If the Mac never leaves the home, and you live in a safe neighborhood, less worries.

     

    But I will tell you that FileVault has been "Rock Solid" for the last few years.  We never really hear about FileVault problems in the forum (except people complaining about needing their password at boot time, because they do not know FileVault is enabled, or they shot themselves in the foot by forgetting their password).

     

    As far as corruption.  That is what backups are for.  And based on FileVault's current track record, you will more likely need the backups to recover from a disk failure, or from accidentally deleting a file, than because FileVault failed.

     

    Finally, if you are using an SSD, they you should be using FileVault because SSDs do not erase cleanly for resale.  But if your data has always been encrypted via FileVault then if you do sell your SSD equipped Mac, or replace it for some reason, no one is going to be able to read the data once you reformat the SSD and destroy the encryption key.

     

    Food for thought.

     

    Then again, it it "Ain't Broke, Done Fix It"

    Or "Fix it unit its Broke"

     

    Also, if my laptop were stolen, I could change the SSH port on the router.

    It is easier than that.  Remove the id_rsa.pub entry from the server's .ssh/authorized_keys file, and the old key will be useless.

     

    You can then generate a new ssh-keygen pair, put the new id_rsa.pub value into the server's .ssh/authorized_keys file and you are all set to go.  The old key cannot be used, and you can use your new key without worries.

  • by Loner T,

    Loner T Loner T Sep 17, 2016 10:00 AM in response to ctlow
    Level 7 (24,409 points)
    Safari
    Sep 17, 2016 10:00 AM in response to ctlow

    ctlow wrote:

     

    ...

    debug1: Server host key: RSA {RSA-key}

    debug1: Host '[{dynamic-IP}]:12345' is known and matches the RSA host key.

    debug1: Found key in /Users/UserName/.ssh/known_hosts:2

    debug1: ssh_rsa_verify: signature correct

    ...

    debug1: Authentications that can continue: publickey,keyboard-interactive

    debug1: Next authentication method: publickey

    debug1: Offering RSA public key: /Users/UserName/.ssh/id_rsa

    debug1: Server accepts key: pkalg ssh-rsa blen {xxx}

    debug1: Authentication succeeded (publickey).

    Authenticated to {dynamic-IP} ({IPAddress}:12345).

     

    The client knows the server and the public key authentication succeeds, so you are not prompted for a pasword.

    I do not see any issues with the handshake or authentication.

  • by ctlow,

    ctlow ctlow Sep 18, 2016 10:08 AM in response to etresoft
    Level 1 (12 points)
    Mac OS X
    Sep 18, 2016 10:08 AM in response to etresoft

    Thanks again, etresoft. I'm learning from all of you that my settings are good but that I should investigate FileVault.

     

    Does it slow the computer down? There are dissenters:

    https://discussions.apple.com/thread/5054282?tstart=0

     

    And proponents:

    https://discussions.apple.com/message/17606723#17606723

     

    But I don't really think I need it. I keep the sensitive stuff at the office, and use my MB-Air to SSH-tunnel in, so the only thing on the entire hard drive I really find private is the keys, and even they are in a password-protected User-folder.

     

    Thanks to everybody.

     

    Charles

  • by ctlow,

    ctlow ctlow Sep 18, 2016 10:09 AM in response to Loner T
    Level 1 (12 points)
    Mac OS X
    Sep 18, 2016 10:09 AM in response to Loner T

    Thanks so much, Loner T. You've gone to too much trouble and I've found it very helpful.

    Charles

Page 1 Next