Is the file argument required or optional. I have no intention of moving every user's $HOME/.ssh/authorized_keys file into a single file in /etc If it is required can I use the path above, like
The default location, if no file= argument is specified, is /etc/security/authorized_keys
As of version 0.8, you may use file=~/.ssh/authorized_keys, or equivalently file=%h/.ssh/authorized_keys to achieve this functionality ... Note however, that there are major security implications in doing so, and of course, allowing the user to provide the authentication key, would only make sense at all for things like sudo.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I may wind up feeling dumb after this, but here goes...
Could you elaborate on the security implications of using user specific authorized_keys files? I'm having a hard time imagining how user files are markedly worse than a single system wide file.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For sudo, using per-user authorized_keys files is still better than requiring authentication via password; its semantically the same in the sense that users are still able to self-manage the credential they use to authenticate, but relies on a cryptographic signature of a packet containing random bytes given from ssh-agent instead of a constant string.
However, if you wanted to maintain a list of keys you wished to explicitly permit to operate non-interactively, using a central authorized_keys file would remain preferable. Remembering of course that one of the reasons sudo requires authentication is to ensure that it is _still_ you sitting on the keyboard, and that you haven't walked off and left your terminal unprotected.
However, for things other than sudo, for instance, su, it would be a catastrophe to permit user-owned authorized_keys files, as it would practically identical to making /etc/shadow 0666;
Basically, for things asking for a users own credential, user-owned authorized_keys files are usually fine, but allow any user to authenticate in an unattended fashion, regardless of the freshness of their login (of course, they could use ssh-agent's auto-lock feature to regain that protection, but because you cannot mandate this, you are at the mercy and discretion of the client.) Whereas, for things asking for the target-user's credential, user-owned authorized_keys files must never be used, as that would allow any user to authenticate as the target-user simply by running an ssh-agent.
So, you shouldn't feel dumb, but I must remain mindful that this PAM module could also be used for things other than sudo.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. I get now the issue of unattended authentication and the trouble that could be around that. I can see how, while not disastrous, it is short circuiting the mechanism to ensure that the user is actually at the keyboard.
But I still don't get the su thing. If you are an unprivileged user and you put your own ssh public key in your own authorized_keys file, and I as an admin have my pam set up to use sshagentauth all the time, then how is that a problem for su? If you try to use su to access root, just as you would need the root password, so would you need a key that is in the authorized_keys file for root.
I tried it out myself. I ran "su -", and your module looks at root's authorized_keys file, not my own. I agree, if it had looked at my authorized_keys file when I was authenticating for root, then yes, that would be spectacularly stupid. However, it isn't doing that, at least from my testing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that you've reminded me of a few things, I'm honestly at a loss as to why I felt this would be so scary... I have the same file-permissions checks and sanity checks as ssh itself; which means that this would simply be authenticating for su the same as ssh user@localhost... but far lighter...
So, you've convinced me.
I think _I_ was the one with my head stuck in sudo, which pam_start's with the user as yourself, whereas most things pam_start with the user set to the target-user.
I'm finishing up 0.9, hopefully before the weekend... I'll add some test-cases for this, just to make sure I don't get my head stuck somewhere it ought not to be in the future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the clarifications. I'll keep an eye out for the new release then. Looking forward to it. I really like this concept of authentication, and I'll probably start using it on my boxes soon. So thank you for all the effort making this work.
I'm going to roll some ubuntu packages for this. I'll pass them along if you want.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is the file argument required or optional. I have no intention of moving every user's $HOME/.ssh/authorized_keys file into a single file in /etc If it is required can I use the path above, like
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
Thanks,
The default location, if no file= argument is specified, is /etc/security/authorized_keys
As of version 0.8, you may use file=~/.ssh/authorized_keys, or equivalently file=%h/.ssh/authorized_keys to achieve this functionality ... Note however, that there are major security implications in doing so, and of course, allowing the user to provide the authentication key, would only make sense at all for things like sudo.
I may wind up feeling dumb after this, but here goes...
Could you elaborate on the security implications of using user specific authorized_keys files? I'm having a hard time imagining how user files are markedly worse than a single system wide file.
Thanks
For sudo, using per-user authorized_keys files is still better than requiring authentication via password; its semantically the same in the sense that users are still able to self-manage the credential they use to authenticate, but relies on a cryptographic signature of a packet containing random bytes given from ssh-agent instead of a constant string.
However, if you wanted to maintain a list of keys you wished to explicitly permit to operate non-interactively, using a central authorized_keys file would remain preferable. Remembering of course that one of the reasons sudo requires authentication is to ensure that it is _still_ you sitting on the keyboard, and that you haven't walked off and left your terminal unprotected.
However, for things other than sudo, for instance, su, it would be a catastrophe to permit user-owned authorized_keys files, as it would practically identical to making /etc/shadow 0666;
Basically, for things asking for a users own credential, user-owned authorized_keys files are usually fine, but allow any user to authenticate in an unattended fashion, regardless of the freshness of their login (of course, they could use ssh-agent's auto-lock feature to regain that protection, but because you cannot mandate this, you are at the mercy and discretion of the client.) Whereas, for things asking for the target-user's credential, user-owned authorized_keys files must never be used, as that would allow any user to authenticate as the target-user simply by running an ssh-agent.
So, you shouldn't feel dumb, but I must remain mindful that this PAM module could also be used for things other than sudo.
Thanks. I get now the issue of unattended authentication and the trouble that could be around that. I can see how, while not disastrous, it is short circuiting the mechanism to ensure that the user is actually at the keyboard.
But I still don't get the su thing. If you are an unprivileged user and you put your own ssh public key in your own authorized_keys file, and I as an admin have my pam set up to use sshagentauth all the time, then how is that a problem for su? If you try to use su to access root, just as you would need the root password, so would you need a key that is in the authorized_keys file for root.
I tried it out myself. I ran "su -", and your module looks at root's authorized_keys file, not my own. I agree, if it had looked at my authorized_keys file when I was authenticating for root, then yes, that would be spectacularly stupid. However, it isn't doing that, at least from my testing.
Now that you've reminded me of a few things, I'm honestly at a loss as to why I felt this would be so scary... I have the same file-permissions checks and sanity checks as ssh itself; which means that this would simply be authenticating for su the same as ssh user@localhost... but far lighter...
So, you've convinced me.
I think _I_ was the one with my head stuck in sudo, which pam_start's with the user as yourself, whereas most things pam_start with the user set to the target-user.
I'm finishing up 0.9, hopefully before the weekend... I'll add some test-cases for this, just to make sure I don't get my head stuck somewhere it ought not to be in the future.
Thanks for the clarifications. I'll keep an eye out for the new release then. Looking forward to it. I really like this concept of authentication, and I'll probably start using it on my boxes soon. So thank you for all the effort making this work.
I'm going to roll some ubuntu packages for this. I'll pass them along if you want.