The downloadable version of this article is available here:
http://downloads.techrepublic.com.com/abstract.aspx?docid=240667
What is your current choice for SSH implementation? How important is SSH to your organization?
Discussion on:
View:
Show:
most distros tend to have ssh configured to allow root login and to forward xsession data by default.
I personally make ssh use public and private key pairs for remote access, and if the key pair is sent electronically it is not acceptable on a critial system, since most likely the danged email that carried it wasn't encrypted at all.
The reason for the keys is to make sure that the remote user is someone who you want access to be granted. it does limit the user to only accessing from one system, unless they choose to go through the hastle of importing the key data into other system's ssh client tools.
I personally make ssh use public and private key pairs for remote access, and if the key pair is sent electronically it is not acceptable on a critial system, since most likely the danged email that carried it wasn't encrypted at all.
The reason for the keys is to make sure that the remote user is someone who you want access to be granted. it does limit the user to only accessing from one system, unless they choose to go through the hastle of importing the key data into other system's ssh client tools.
In some respects it makes sense for it to default to allowing root logins, especially to someone coming from the Windows world who might think lack of remote root login capability means something is broken. I'd still prefer a default of disallowing remote root logins, however, with the ability to gain root access via su once you're already logged in if necessary.
Using keys rather than per-connection authentication has its ups and downs, of course. For instance, if your purpose is to have access from anywhere so that you can check email while traveling without having to use webmail, you may not be able to use a prior key exchange as your means of authentication. In many cases, however, using keys for access control is the better option -- as you indicated.
Using keys rather than per-connection authentication has its ups and downs, of course. For instance, if your purpose is to have access from anywhere so that you can check email while traveling without having to use webmail, you may not be able to use a prior key exchange as your means of authentication. In many cases, however, using keys for access control is the better option -- as you indicated.
the su as non root login is a much better option for remote admin, and that is where a keys config is the best option.
if you are allowing non root per connection for checking email, no su ability that is fine.
the problem is getting a single box to allow the more secure option for remote admin, while still allowing the per connection for non admin tasks.
I haven't figured out how to have ssh use either as needed yet.
if you are allowing non root per connection for checking email, no su ability that is fine.
the problem is getting a single box to allow the more secure option for remote admin, while still allowing the per connection for non admin tasks.
I haven't figured out how to have ssh use either as needed yet.
The problem is that su access is handled by su, and not OpenSSH. Once you've logged in via SSH, though, su can't tell you're acting remotely. As such, it might be necessary to use a separate VPN solution for administrative access rather than (or perhaps tunneled through, if you really want to) an SSH connection.
If su could somehow be made SSH-aware so that it can check how one has been authenticated, it might solve the problem you've posed, but this would probably require changing the way SSH works such that it breaks the intended operation of SSH. After all, part of the point of SSH is the remote user's ability to access the machine as though using a TTY console locally, without any operational side-effects due to the remote connection.
If su could somehow be made SSH-aware so that it can check how one has been authenticated, it might solve the problem you've posed, but this would probably require changing the way SSH works such that it breaks the intended operation of SSH. After all, part of the point of SSH is the remote user's ability to access the machine as though using a TTY console locally, without any operational side-effects due to the remote connection.
it's just that currently ssh only allows one type of authentication per server, which is what is usually wanted.
having a user account that has su enabled or not depending on how ssh authenticatedwould just be a means of distancing regular use from admin use. locking the admin to specific machines is better for the overall security and stability of the server.
I'll have to drop this as a discussion idea into both openssh and su dev teams. see if they like the idea enough to work on the alterations both would require to actually get this functionality, without hurting the functionality of the ssh session as it currently exists.
having a user account that has su enabled or not depending on how ssh authenticatedwould just be a means of distancing regular use from admin use. locking the admin to specific machines is better for the overall security and stability of the server.
I'll have to drop this as a discussion idea into both openssh and su dev teams. see if they like the idea enough to work on the alterations both would require to actually get this functionality, without hurting the functionality of the ssh session as it currently exists.
Actually, when you don't configure it to behave otherwise, sshd will automatically try each of four different approaches to authentication, in the following order:
1. host-based authentication
2. public key authentication
3. challenge-response authentication
4. password authentication
That order can even be modified in configuration when you're using the SSH 2 protocol. Some of these can be disabled for a given system in sshd configuration as well, if you prefer.
The problem, as I already tried to convey, isn't really in what SSH allows you to do, but in the fact that the shell on the remote system is not aware of the authentication method that was used to connect in the first place. In particular, this would probably require a rewrite of both the shell (generally bash) and the su utility, most likely, as well as of OpenSSH. It might be possible to do something involving a VPN tunneled through SSH, as I mentioned, to execute a root shell while preventing standard su use from a standard user shell, but there isn't much else for options related to SSH I'm afraid -- even if you wanted to rewrite OpenSSH.
There's a bright side, however: if you wish, you may disable su entirely, allow password authentication for standard user accounts, and use configuration options for the PermitRootLogin item in sshd_config to restrict root logins to public key authentication only. It doesn't do what you were looking for (su available only to an account that authenticates via keys but non-su capability for password logins), but it does separate root access from password-login while still allowing remote root access. Check out the section on PermitRootLogin in the sshd_config manpage for details (if your distro has that manpage -- if not, look it up in the online manpages for Debian, which has manpages for EVERY damned thing).
1. host-based authentication
2. public key authentication
3. challenge-response authentication
4. password authentication
That order can even be modified in configuration when you're using the SSH 2 protocol. Some of these can be disabled for a given system in sshd configuration as well, if you prefer.
The problem, as I already tried to convey, isn't really in what SSH allows you to do, but in the fact that the shell on the remote system is not aware of the authentication method that was used to connect in the first place. In particular, this would probably require a rewrite of both the shell (generally bash) and the su utility, most likely, as well as of OpenSSH. It might be possible to do something involving a VPN tunneled through SSH, as I mentioned, to execute a root shell while preventing standard su use from a standard user shell, but there isn't much else for options related to SSH I'm afraid -- even if you wanted to rewrite OpenSSH.
There's a bright side, however: if you wish, you may disable su entirely, allow password authentication for standard user accounts, and use configuration options for the PermitRootLogin item in sshd_config to restrict root logins to public key authentication only. It doesn't do what you were looking for (su available only to an account that authenticates via keys but non-su capability for password logins), but it does separate root access from password-login while still allowing remote root access. Check out the section on PermitRootLogin in the sshd_config manpage for details (if your distro has that manpage -- if not, look it up in the online manpages for Debian, which has manpages for EVERY damned thing).
That it is possible to have some signon's log in via public/private keys while others allowing to use password authentication?
Because of ssh brute force attacks I ended up shutting down a home system to only private/public key authentication. I found that I was still able to password authenticate even if I didn't have the keys present till I turned that off.
I also found a way to not allow specific users/groups/hosts not be allowed to ssh at all and utilized that for certain accounts.
But, I haven't found anything that would allow some users to key authenticate and others to not. When I mean key authenticate, that being the only allowed authentication.
I apologize if this seams like a stupid question, but it is something I was looking into and would like a better understanding of.
dan
Because of ssh brute force attacks I ended up shutting down a home system to only private/public key authentication. I found that I was still able to password authenticate even if I didn't have the keys present till I turned that off.
I also found a way to not allow specific users/groups/hosts not be allowed to ssh at all and utilized that for certain accounts.
But, I haven't found anything that would allow some users to key authenticate and others to not. When I mean key authenticate, that being the only allowed authentication.
I apologize if this seams like a stupid question, but it is something I was looking into and would like a better understanding of.
dan
if you leave ssh config authentication at default it will work through the 4 main types of authentication.
user groups to controll ssh access is the easiest way to control it.
blocking ips isn't as effective as it seems, dhcp means the ip can and will change.
user groups to controll ssh access is the easiest way to control it.
blocking ips isn't as effective as it seems, dhcp means the ip can and will change.
As I understand it, you're asking whether it's possible to configure one normal user account to restrict logins to key-based authentication while another normal user account is configured to allow password-based authentication for SSH. Unfortunately, that doesn't seem to be possible. As far as I'm aware, at any rate, there isn't a way to do that. There is no "PermitBobLogin" configuration option in sshd_config.
Thus, it seems that only root can be given a different authentication requirement from all other accounts.
You can, however, disallow specific accounts, or allow only specific accounts while disallowing all others by default.
That's one thing about OpenSSH that I would like to see changed: the addition of the ability to set authentication requirements differently for different user accounts aside from root. I should double-check to make sure it's not a capability I'm overlooking, though. I suppose it's possible that this is just something about OpenSSH that I don't know.
Thus, it seems that only root can be given a different authentication requirement from all other accounts.
You can, however, disallow specific accounts, or allow only specific accounts while disallowing all others by default.
That's one thing about OpenSSH that I would like to see changed: the addition of the ability to set authentication requirements differently for different user accounts aside from root. I should double-check to make sure it's not a capability I'm overlooking, though. I suppose it's possible that this is just something about OpenSSH that I don't know.
Here is the steps as outlined by someone on the ssh help mailing list who uses this to limit admin [ root ] access for ssh users:
Easy... Compile sshd with the match keyword patch
(http://bugzilla.mindrot.org/show_bug.cgi?id=1180),
and use it to ensure that members of the admin group can only log in using public/private key
authentication.
Also make these users a member of the wheel group, and ensure that only they can su - check out etc/pam.d/su.
For example, in /etc/ssh/sshd_config add:
Match Group admins
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
In /etc/pam.d/su ensure the following is uncommented:
# Uncomment the following line to require a user to be in the "wheel" group.
auth required
/lib/security/$ISA/pam_wheel.so use_uid
I use this method to ensure that admins can only log in using public/private keys and have access to perform admin functions while (hopefully) ensuring that "normal" users cannot mess about.
This also has the advantage that if any user uploads their own keys to ~/.ssh that they will not be able to gain admin rights!!!
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
