Kerberos and ssh

[Elena Leontieva]

Hello,

We are implementing SSH on HP-UX servers. My understandig is that ssh will allow to send both the data and the passwords in encrypted format. If ssh-2 version is enabled than ssh will use kerberos5 as authentication method. What ssh uses by default, /ets/passwd? Does the password sent encrypted?
We also want to tunnel X-Windows (CDE) through SSH, to secure connections between PC and Unix servers.

I wonder if we do all of the above, what will be the advantages in setting up Unix hosts as clients in a Windows 2003 Active Directory domain OR in setting up a cross-realm trust between a Unix Kerberos realm & Active Directory?

Thank you for sharing your thoughts.
Elena.

[Bill Thorsteinson]

ssh by default uses the password file.
Passwords are encryupted or passed as data
in an encrypted channel.

The advantage of configuring as a client
to Windows 2003 Active Directory is
the ability to change the password in one
location.

Disadvantages:
- All windows users have access to Unix.
- Security problems introduced by single password.
- UID mapping issues between Windows and Unix.

[Bill Thorsteinson · Accepted solution]

ssh by default uses the password file.
Passwords are encryupted or passed as data
in an encrypted channel.

The advantage of configuring as a client
to Windows 2003 Active Directory is
the ability to change the password in one
location.

Disadvantages:
- All windows users have access to Unix.
- Security problems introduced by single password.
- UID mapping issues between Windows and Unix.

If you want your Windows users to have
simpler access to Unix, consider using
ssh key files and avoid the login.
This allows access to be controlled quite
effectively.

[Steven E. Protter]

Shalom Elena,

By default ssh will always encrypt passwords, whether it be ssh1 or ssh2 mode.

There are advantages and disadvantages of the various solutions in the last paragraph.

Unix can be upgraded to Kerberos v5 and work quite well with Windows 2003 Active Directory. Kerberos can be used across the organization and servers.

I'm not a big fan of using Microsoft this way, but this seems to be a rare chance to do both.

Sorry for the post gap, got called away mid type.

SEP

[TEC-HP]

we are trying to implement the same:
final goal:
all non-system users managed centraly in the active directory
kerberos for authentication
authorisation info stored in active directory

almost ready for implementation:
kerberos authentication (towards AD KDC)
-users are still created on UX host but left disabled (active in AD): meaning authorisation is still locally
-users can only login using their windows passwd (kerberos) when using ssh: defined in pam.conf
-root is explicitly excluded from kerberos authentication: pam_user.conf. Note: should also be done for the other system accounts, unless you also manage the ADStill Issue to be solved: ssh key-based authentication: needed for batch users (also stored in AD) but should be prohibited for normal users as key-based logon is still possible even if the account is dissabled in AD: bad integration PAM-kerberos-SSH

Next steps to be done: complete integration with AD
-Since Win2003 RC2: Posix scheme (RFC2307) should be standard in AD
-Authorisation on unix done by logonscript using netgroups
Note: LDAPUX client isn't yet ready as it still uses the MSSFU and AD needs a proxy-user (can be changed in AD butperhaps prohibited by your local security rules)

[Andrew Cowan]

The only problem with using SSH key login is:

Standard keys never expire
You cannot prevent users having a blank passphrase
SSH is now one of the most attacked protocols, therefore if users are not choosing adequate passphrases, or not adequately protecting their keys, then you are asking for trouble.

There are ways around this, however it requires thought and planning.