Is anyone using public key certificates to log in interactive on the box? Most security policies recommend this over password authentication.
Are there any issues with only allowing public key authentication?
Hello,
The default SSH setup does not allow login to ESX as root, which is really the only user that can do anything meaningful. Once you change ESX to ALLOW this your security stance has been weakened quite a bit. My suggestion has always been to leave the SSH configuration alone and use sudo to run commands.
The Vizioncore products use SSH to access an administrative user and then an su command to access the root account where it runs or access the data necessary.
Judicious use of public keys and sudo make for a well monitored system and the capability to revoke access at any time if you are the administrator. This way no one need know the root password but a few people.
The only issue with public key authentication is that depending on how it is setup, if someone gets a hold of the public key credential file and spoofs a real system IP and Mac Address, then you now have direct access to the system in question without having to know the password. If no one can get the credential file, and your systems are not susceptible to an end point attack then you should be safe.
Or you could use a passphrase as well as a public key to alleviate any possible issues.
Best regards,
Edward
as always - it depends
Regarding security public key authentiction is a plus compared to password authentication.
It also has some advantages when remote scripting things.
Most users though tend to prefer password authentication since they are used to it and there's nothing wrong with it if you use strong passwords - tokens.
It looks like this might not be an options since products like esxRanger require SSH access.
you could use two (or more) different SSH servers doing different types of authentication
Yeah I guess I could...although the extra trouble does seem a bit overkill.
Hello,
The default SSH setup does not allow login to ESX as root, which is really the only user that can do anything meaningful. Once you change ESX to ALLOW this your security stance has been weakened quite a bit. My suggestion has always been to leave the SSH configuration alone and use sudo to run commands.
The Vizioncore products use SSH to access an administrative user and then an su command to access the root account where it runs or access the data necessary.
Judicious use of public keys and sudo make for a well monitored system and the capability to revoke access at any time if you are the administrator. This way no one need know the root password but a few people.
The only issue with public key authentication is that depending on how it is setup, if someone gets a hold of the public key credential file and spoofs a real system IP and Mac Address, then you now have direct access to the system in question without having to know the password. If no one can get the credential file, and your systems are not susceptible to an end point attack then you should be safe.
Or you could use a passphrase as well as a public key to alleviate any possible issues.
Best regards,
Edward
Keep in mind that while key-based SSH is more secure than passwords, it might not be up to snuff for your audit requirements. There is no way to assure password complexity, there is no way to assure that there is a password for the private key and there is no way to blacklist private keys. These types of things can be problem for auditors for PCI, etc. You might need to look at using a real two-factor authentication system.
HTH,
nick
Hello,
If you use pass phrase locked SSH keys, then there is no way to impose a passphrase strength or complexity. In addition, there is no way to determine the pass phrase strength or complexity. You can however set the size of the key to create. The default is a 1024 key but it can be MUCH larger. 1K may be sufficient, but I know people using 4K bit keys.
As for blacklisting, in order to use the public key access, the public key must be in the ~user/.ssh/authorized_keys file on the host you wish to access, and you must have the key in the appropriate place on the source host. If it is not in there, it will not work. So if you want to blacklist a key, just remove it from the authorized_keys file or move it to a different file and it will not be read or available for use.
If there was a BIO authentication method for an SSH client, then that would be a possible way to go as well. I.e. THe BIO auth unlocks the SSH shared key before it can be used.
Best regards,
Edward
I agree, however that a real two-factor auth system would be great for access to the Service Console.
I agree, however that a real two-factor auth system would be great for access to the Service Console.
Whats the problem doing this?
Since the COS is Linux you can use any PAM compatible product.
Safeword from Secure Computing works and I guess RSA's SecurID works too.
I tested this a while ago with WiKID Strong Authentication. The problem I had was that the console seemed to require multiple authentication checks, like a web page. Of course, the second time it tried to check the OTP, it failed.
Here is the original post: http://www.vmware.com/community/thread.jspa?messageID=420923񦰻
IIRC, I could log into the console, but then I could not log into a specific vmware instance. I would like to get this working, especially now that we have a certified VMware WiKID server.
I've only tested it with Safeword...
With Safeword I only had to add the PAM module to the PAM connfiguration and change the system module to sufficient (to login with the OTP only).
If you want to use both (password and OTP) leave the system module at required and add the secondary module with the required option.
Message was edited by:
oreeh
and make sure to enable PAM authentication in /etc/sshd_config
Interesting. I'll have to test again. It's been awhile - though I was not using ESX. Plus i was using pam_radius.
The type of the PAM plugin or the underlying host shouldn't make any difference.
ok, I have edited /etc/pam.d/vmware-authd thusly:
#%PAM-1.0
auth sufficient /lib/security/pam_radius_auth.so
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
I am able to login to the VMWare server console, but when I try to start up a server, I get this
Unable to connect to the MKS: Login (username/password) incorrect.
/var/log/secure shows:
Jun 8 10:40:13 support xinetd\[1889]: START: vmware-authd pid=10888 from=xxx.xx.xx.xx
Jun 8 10:40:13 support vmware-authd\[10888]: pam_radius_auth: DEBUG: getservbyname(radius, udp) returned 12782496.
Jun 8 10:40:14 support vmware-authd\[10888]: pam_radius_auth: RADIUS server 127.0.0.1 failed to respond
Jun 8 10:40:14 support vmware-authd\[10888]: pam_radius_auth: DEBUG: getservbyname(radius, udp) returned 12782496.
Jun 8 10:40:14 support vmware-authd\[10888]: Deprecated pam_stack module called from service "vmware-authd"
Jun 8 10:40:14 support vmware-authd\[10888]: login from 65.182.34.78 as nowen
The successful connection by the console, then when I try to access the server console:
Jun 8 10:41:19 support xinetd\[1889]: START: vmware-authd pid=10894 from=xx.xx.xx.xx
Jun 8 10:41:19 support vmware-authd\[10894]: pam_radius_auth: DEBUG: getservbyname(radius, udp) returned 12782496.
Jun 8 10:41:20 support vmware-authd\[10894]: pam_radius_auth: RADIUS server 127.0.0.1 failed to respond
Jun 8 10:41:20 support vmware-authd\[10894]: pam_radius_auth: DEBUG: getservbyname(radius, udp) returned 12782496.
Jun 8 10:41:20 support vmware-authd\[10894]: Deprecated pam_stack module called from service "vmware-authd"
Jun 8 10:41:20 support vmware-authd\[10894]: pam_unix(vmware-authd:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=nowen
I have also tried with:
auth sufficient /lib/security/pam_radius_auth.so
auth sufficient pam_stack.so service=system-auth
I can see it going back to the WiKID server with the same OTP.
I was talking about SSH / console login not the Server console.
Anyways - according to your log there's something wrong with your RADIUS setup.
I believe you are logging in to the console using the auth required pam_stack.so service=system-auth (since it is required) after the RADIUS login actually fails.
Do you see something in your RADIUS server logs?
Ahh, I see. I also have no problem logging via SSH with one-time passcodes, but it seemed to me that the Server Console should also be locked down.
I'm logging into the console with an OTP. The WiKID server logs show that as successful:
2007-06-08 10:44:26.183199-04 General RADIUS Message : <117> Access-Accept(2) LEN=83 65.182.34.70:11942 Access-Request by nowen succeeded (110) N/A N/A N/A N/A N/A
2007-06-08 10:44:26.173115-04 Successful Online Passcode Validation (138) Mal-aware N/A nowen extranet N/A
2007-06-08 10:44:21.747831-04 Passcode Request Successful (128) Mal-aware -846786078213817578 nowen internal N/A
Then, the WiKID server gets a second request and rejects it because it is using the same one-time pascode again:
2007-06-08 10:44:33.0709-04 General RADIUS Message : <60> Access-Request(1) LEN=83 65.182.34.70:11959 Access-Request by nowen Failed: AccessRejectException: Access Denied (110) N/A N/A N/A N/A N/A
2007-06-08 10:44:33.067336-04 Bad Passcode (137) N/A N/A N/A extranet N/A
The VMware console is not requesting a second OTP. I think it is just resending the first.
The VMware console is not requesting a second OTP. I think it is just resending the first.
This might be the case - but I'm unsure how to fix this.
I guess the console caches the authentication information and I don't know a setting to change this.
One workaround could be: login using ssh and create a SSH portforwarding for the console.
Hello,
You will want to start with a /etc/pam.d/system-conf like the following. Note however, that for UID < 500 you really do not want to call pam_radius, so you may also want the pam_succeed_if.so module. Since neither this module nor the pam_radius module are part of ESX, you are pretty much on your own. This is modeled after pam_ldap.so actually which is part of ESX. This should only ask for one password....
\-----
account required /lib/security/$ISA/pam_unix.so
account sufficient /lib/security/$ISA/pam_radius.so
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_radius.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so
password required /lib/security/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/pam_unix.so nullok try_first_pass use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_radius.so use_first_pass
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
Still not working for me. Seems to be something with the VMware server console that is expecting to use a static password. Perhaps it is incapable of requesting a password from the user at that point as pam_radius is incapable of providing a session. It may have to wait until we add Kerberos support.
Hello,
Since pam_radius is not really part of ESX, I would be surprised if it works. Pam_radius is really old code and it does not understand the use_authtok option, which is really what it needs by then, the use of use_first_pass should work, but not sure why. You could check with the pam_radius folks.
I also do not like the fact that you can not restrict pam modules by uid. I like to exclude all uid < 500 from the advanced auth methods so that root is never authenticated against remote services. But that is also an ESX limitation.
Best regards,
Edward