HP-UX Secure Shell:  Part 1: Installation, Keys, and Default Authentication

By Chris Wong


In June 2002 HP released their supported version of the Secure Shell (ssh).  This release (3.10) is based on OpenSSH3.1p1 and supports both the SSH-1 and SSH-2 protocols. SSH-1 should no longer be used as it contains several known protocol level design flaws that can be exploited.  There are also advisories regarding the use of versions prior to OpenSSH 3.4 (http://www.openssh.org/txt/preauth.adv). The HP-UX Secure Shell (HP-SSH) includes support for Kerberos (4 and 5), IPv6, TCP Wrapper, and PAM. HP-SSH should be used in place of services such as telnet, FTP, and the Berkley “r” commands. All of which pass text in the clear. This series of articles will cover the various aspects of running HP-SSH.  This first article deals with the installation of the product and using SSH with the default configuration.


Check to make sure you have installed the recommended patches (or their replacements) and their dependencies. Always check the HP site for the latest recommendations.

11i   PHCO_24839

11.0 PHCO_25527


These should already be installed if a recent support plus patch bundle is installed.

Download the Secure Shell depot from:  http://software.hp.com (Internet & Security Solutions, hp-ux secure shell) or use the September 2002 or later applications CDs.

swinstall -s /wherever/T1471AA_whatever-version.depot


15,732 Kbytes will be installed and a reboot is not required.


HP-SSH has been added as a startup/shutdown routine via the /etc/rc.config.d/sshd configuration file and is automatically started after install.  Make sure it is running:


ctg701#: ps -ef | grep ssh

    root  3807     1  0 08:51:01 ? 0:00 /opt/ssh/sbin/sshd


The root user will now have a .ssh directory:


drwx------   2 root       sys             96 Aug  8 08:49 .ssh


and the following file will be under it:


-rw-------   1 root       sys           1024 Aug  8 08:51 prng_seed


The following entry is added to the syslog.log file:


Aug  8 08:51:01 ctg701 sshd[3807]: Server listening on port 22.


HP SSH can be started and stopped using the following commands:


# /sbin/init.d/secsh stop

HPUX Secure Shell stopped


# /sbin/init.d/secsh start

HPUX Secure Shell started


Please note that these are named secsh and not sshd. (Don't you hate it when the configuration file is given a different name?).


The following files are placed in the /opt/ssh/etc directory:


moduli                                    ssh_host_key                         ssh_prng_cmds

ssh_config                              ssh_host_key.pub                   sshd_config

ssh_host_dsa_key                  ssh_host_rsa_key

ssh_host_dsa_key.pub           ssh_host_rsa_key.pub


Let's take a few minutes and talk about terms, keys, and algorithms.




Symmetric: One key that is used for both encrypting and decrypting. Think of this as the key to the front door of your house.  You use your key to lock the door and when you come home you use the same key to unlock the door.  You have just one key. In this scenario you are limited to who can unlock your front door, which is a good thing when you are talking about your front door.  But, what about in a dynamic environment?  Take the example of a building superintendent who must manage issues regarding the distribution of keys, lost keys, tracking who has keys, and ensuring the return of keys from those who should no longer have them.


Asymmetric: A pair of keys, where each key "undoes" the other key. Together these keys are referred to as a pair; one is known as the private key, the other as the public. The private key must be kept private and well secured. The public key can be openly distributed -- even posted on a web site. What is encrypted with the private key can only be decrypted by the public key; not even the same private key can decrypt it. Likewise, what is encrypted with the public key can only be decrypted by the private key. Since the public key can be openly shared without concern for the integrity of the key-pair, the key management problems described with symmetric keys is (mostly) addressed.


Hashed: A hash is an "encrypted" value that cannot be decrypted. The best example of this is a UNIX user password. The ASCII password is combined with a salt and both these are passed through crypt to produce the "encrypted" password. However, this password is not encrypted, it is hashed. Programs such as Crack do not decrypt the password, they simply search for a match. (Due to the salt, each unique password can be hashed 4096 different ways.) 


The value of a good hash routine (in database systems or cryptography) is that a large amount of data can be reduced to a fairly short, extremely unique, and randomly distributed "signature" of the hashed information. With a good hash algorithm, even one changed bit should yield a very different hash value.


Persistent: A key that does not change. This key will exist for a long period of time. Typically changing a persistent key will cause additional administrative tasks on multiple servers and/or clients.


Generated or non-persistent: A key that is not persistent. This key is generated based on either an event or at a specific interval.  Generated keys are temporary. These are sometimes called session keys.


Algorithm: A procedure for solving a mathematical problem (as of finding the greatest common divisor) in a finite number of steps that frequently involves repetition of an operation. (Source: Merriam-Webster Dictionary).


SSH uses a combination of hash functions and key algorithms. What is used is determined by configuration settings and by elimination of methods that are not common between the server and client. Understanding the in-depth workings of these algorithms isn't necessary. Learn one, and you'll forget it by the time you are learning the third one.


Common Asymmetric (Public) Key algorithms used with SSH:  RSA (Rivest-Shamir-Adleman), DSA (Digital Signature Algorithm), and Diffie-Hellman.


Common Symmetric (Secret) Key algorithms used with SSH: DES (Data Encryption Standard), IDEA (International Data Encryption Algorithm), Triple-DES (3DES), Blowfish, and AES (Advanced Encryption Standard). AES is available in 3 flavors: 128, 192, and 256 bits.  Those supported with HP-SSH: 3DES, Blowfish, CAST (Carlisle Adams and Stafford Tavares)-128, ARCFOUR, AES-128,192, and 256.


Common Hash algorithms used with SSH: MD5 (Message Digest), CRC (Cyclic Redundancy Check)-32, and SHA-1 (Secure Hash Algorithm).


Asymmetric and symmetric algorithms have different strengths and are used to address different problems. Asymmetric algorithms are slower but are required for dynamic communication. They are designed to address the problems that are associated with the management of key distribution.  Symmetric algorithms are fast. In SSH they are used to authenticate and negotiate a non-persistent symmetric key.


Keys in SSH:


Host Key: This key is the unique ID of the SSH server. It is a persistent key.  It is asymmetric.  The private key is not encrypted, as you might expect, but rather must be protected by file permissions. On SSH1 implementations you will see one key pair per hostname. On SSH2 implementations there will be one DSA host key pair and one RSA host key pair per socket.  Typically, there is only one SSH server running on a host, so it is easy to associate the Host Key with an individual HP-UX system.  However, if multiple SSH instances are running on the one system, each instance could have their own Host Key pairs. Let's look at the specific files on the HP-UX SSH server:


The ssh_host_key is a 1024 bit private key for the host. The ssh_host_key.pub is the corresponding public key. These 2 keys are only used with SSH1.


It is imperative that the private key be kept secure while the public key is available for distribution. This is accomplished through the permissions on the 2 key files:


-rw-------   1 root       sys        526 Aug  8 08:49 ssh_host_key

-rw-r--r--   1 root       sys        330 Aug  8 08:49 ssh_host_key.pub


and the permission on the parent directory:


drwxr-xr-x   2 bin        bin       1024 Aug  8 08:50 /opt/ssh/etc


Note that /etc/opt/ssh is linked to /opt/ssh/etc


Found in the same directory is a key pair for both DSA and RSA:


-rw-------   1 root       sys     668 Aug  8 08:50 ssh_host_dsa_key

-rw-r--r--   1 root       sys     601 Aug  8 08:50 ssh_host_dsa_key.pub


-rw-------   1 root       sys     883 Aug  8 08:50 ssh_host_rsa_key

-rw-r--r--   1 root       sys     221 Aug  8 08:50 ssh_host_rsa_key.pub


The host authentication process is only as reliable as the security of the private key.  When thinking of a private key imagine a key with a trench coat on, the coat should always be kept closed!  The public key on the other hand is distributed fairly freely. (I won't give you anything to imagine for this one).  Keep in mind all avenues of access to the private key (file/directory permissions, back up tapes, and root access).


All these keys are built during the installation process. For the sake of learning, we will create a new set of RSA Host Keys. If you already have SSH implemented, you do not want to do this.


ctg701#: ssh-keygen -t rsa -f /opt/ssh/etc/ssh_host_rsa_key

Generating public/private rsa key pair.

/opt/ssh/etc/ssh_host_rsa_key already exists.

Overwrite (y/n)? y

Enter passphrase (empty for no passphrase): [press return]

Enter same passphrase again: [press return]

Your identification has been saved in /opt/ssh/etc/ssh_host_rsa_key.

Your public key has been saved in /opt/ssh/etc/ssh_host_rsa_key.pub.

The key fingerprint is:

6b:0f:f9:ae:e1:ba:54:c2:b5:87:77:30:cf:3a:11:5b root@ctg701


ctg701#: ll *rsa*

-rw-------   1 root       sys    883 Aug 22 13:59 ssh_host_rsa_key

-rw-r--r--   1 root       sys    221 Aug 22 13:59 ssh_host_rsa_key.pub


Remember, the Host Private Key is never protected with a passphrase. This is why when generating a new Host Key, we pressed return twice instead of entering a password. (This allows the ssh daemon to read the key at startup without waiting for someone to enter the passphrase.) When a new Host Key is generated, the SSH daemon needs to be restarted to use the new key.  Take a look at the contents of the keys:


ctg701#: more ssh_host_rsa_key

















ctg701#: more ssh_host_rsa_key.pub

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA4ALBpsnxd16lxVX4SwpMP5pesheyZ6V+TPTc8RLAHl/2ogPhxJ/4Hd9klzVXufJXqYFRAjncHfB3jBq9eH3jZ2K5lyy5GNK6rw4m9ywtvrp+JZLAia3eJTHEPqJlxjYoSi41VXbQTspNabdzakMhmdni4atpc9ZA4P1lOX3hmks= root@ctg701


The above public key has a few interesting fields. The first field shows that this is using RSA as its public key algorithm. The last field shows the server name. 


A look at the DSA public host key shows the similar format:


ctg701#: more ssh_host_dsa_key.pub

ssh-dss AAAAB3NzaC1kc3MAAACBAPXUUu+FamOVbt9II5LWgJzMhtHbJz8XVKlvagELpIxMItlpe0T+n0eb7rcIzX3SMVRPZNudJiJBL7CiPDGJQuufiPPAGTtjVHcY4yZfK2CYu3SRTweT4LdybOG6xYBOiX+X582W8gTjSlowVax6Kvdu3kkolVDbLJSPRSTc76p/AAAAFQDQGpI0P60lm2dqdBklsY/ZJmGjtQAAAIEAofBIs5rNniPMDYCFIMA2YkAhOmNUKTDbElRV0EAmof6Hx9ElgXCaH4J+btlj8ZeaUFE+CeSIRA75EXNDF8oOy1M+LiSvq884aKBLqHwkOYbgSPXNIcjLsttsT7+jRzFlptl3MIgn6P5e/KdCzYNN9HgsPaOE5jgTl168xQYQm8YAAACBALKDw1AHx5bMr27kQZPQzisFx+CDSfZnsevkfsunwTCQLrZO4iiL5MMkZ0Map2xeUsVvO1lA52ompSmIIMvn78dq/PwXZ04pSzVI90piCzoB2WZZENgxhQ9ciVt+SLy6Q/tbKutmopSF+uoZyNfST4Qe/gFx32UU1TMtDs9QuGnq root@ctg701


But, instead of saying "DSA" it says "DSS". This is because DSA is part of the Digital Signature Standard.


When a client connects to the SSH server, a copy of the Public Host Key gets copied to the client. This is used by the client to verify the server in future sessions.  Since each client has a copy of this Public key, you can imagine the mess if you change the Host keys.


In fact, this is an added security feature that prevents someone from mounting a man-in-the-middle attack. If that stored host key should change, SSH on the client will issue all sorts of dire warning.







ID of SSH Server

Asymmetric Persistent

Private not encrypted


Used to create Session Key


Not Persistent

Only used with SSH-1


ID of SSH Client

Asymmetric Persistent

Private is encrypted


Used to encrypt the session


Persistent for the session only

Secret Key


Server Key:  These keys are never stored on disk and are generated every "n" seconds. The default being one hour.  Server keys are only used with SSH1 and are asymmetric.


User Keys: As the host key identifies the host, the user keys are used to identify the user. These are also asymmetric keys, but the private key is encrypted with a user specified passphrase.  These keys are also typically persistent. Users may have more than one key pair.


Session Keys: A session key is generated between the client and server and used for the entire session for encryption.  SSH1 uses the Server Key to generate the Session Key. SSH2 generates two session keys (one for server-client, the other client-server). On HP-SSH the Diffie-Hellman key exchange is used with AES as the generator.  This symmetric key, also known as the secret key, is used to encrypt the session. This is probably why you are interested in SSH, to use an encrypted session instead of having traffic passed in clear text across the network with services such as telnet. The session keys are handled by the SSH server and the client.


To help demonstrate the purpose of the Host Key, let's initiate a ssh session:


client: ssh ctg701

The authenticity of host 'ctg701 (' can't be established.

RSA key fingerprint is 6b:0f:f9:ae:e1:ba:54:c2:b5:87:77:30:cf:3a:11:5b.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'ctg701,' (RSA) to the list of known hosts.

jrice@ctg701's password: [enter your UNIX login password]

Last login: Thu Aug 22 16:02:52 2002 from client



"ssh" is the command used to start an ssh client session in HP-UX.  I have followed that with the name of the host.  Basically, I have replaced telnet with ssh. Using the default configuration setting provided with HP-SSH:


1). The client requests a session from the SSH server using port 22

2). The server sends back its Public Host Key and if using SSH-1, its Public Server Key.

3). The client checks its system's ssh_known_hosts file to see if the Public Host Key exists.  If it exists, the host is authenticated. If it does not exist:

4). The client checks its user's known_hosts file to see if the Public Host Key exists. If it exists, the host is authenticated. If it does not exist:

5). The user is given a chance to add the Host Key to its known_hosts file.  A fingerprint (or hash) of the host’s key is displayed and the user is given the opportunity to manually authenticate the host.  For example, in the above the following fingerprint was displayed:


RSA key fingerprint is 6b:0f:f9:ae:e1:ba:54:c2:b5:87:77:30:cf:3a:11:5b


If you go back to where this RSA key was created, you will see that this is the fingerprint that was displayed.  Users should actually look at this fingerprint and authenticate it before answering “yes”. How could they authenticate it?


1). They could call the system administrator and verify that the fingerprint is correct.

2). The system administrator could push the fingerprint out to users via secure e-mail or in a hard copy format.


The user should be trained to always verify the fingerprint before acceptance.  This prevents DNS spoofing or man-in-the middle attacks. Once this key is added to the user’s known_hosts file, they will not be required to manually authenticate this key again unless the system administrator changes the SSH server’s Host Key. 


If the user gets a message that the key no longer matches, they should not simply accept the new key.  They should be trained to manually validate the new fingerprint before accepting.


On HP-SSH the default for the client is to add the Public Host Key to the user's known_hosts file automatically when the user replies "yes" to the prompt (if no other key for the host exists). After the ssh session is completed the user has a new directory called .ssh and in that directory is the known_hosts file.


client: ll .ssh                                                        

total 4

-rw-r--r--   1 jrice      users          230  Aug 22 16:03 known_hosts

-rw-------   1 jrice      users         1024 Aug 22 16:03 prng_seed


client: more .ssh/known_hosts

ctg701, ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAt2FJStwxsE/COE9vvE6COgS



The server that we made a connection to is listed in this file, automatically.  And finally, the user is required to enter their UNIX login password.


What happens when we use "ssh" next time? 


client: ssh ctg701                                                           

jrice@ctg701's password:

Last login: Thu Aug 22 16:03:52 2002 from client



This time we are only asked to enter the UNIX login password.  The host was authenticated because the Host's Public Key was found in the user's known_hosts file. So, what has this accomplished?  For starters, this session is encrypted.  It was encrypted before the user entered their UNIX login password.   Simply by following these steps, you have greatly increased your security by stopping passwords from being sent over the network in clear text. Further, we are using strong asymmetric cryptographic techniques to authenticate we are truely communicating with the correct host (as opposed to trusting a DNS lookup as authentication).


A look at the processes on the server shows that the ssh daemon spawns a separate process for the connection (3576). This process spawned the shell used by the user (3578).


root  2455     1  0 12:23:58 ?         0:00 /opt/ssh/sbin/sshd

root  3576  2455   0 16:22:32 ?         0:01 sshd: jrice@0

jrice 3578  3576  0 16:22:38 pts/0     0:00 -sh


If you want to make the migration to SSH seamless to users using the default configuration, you must have access to their clients.  If all the users are on another UNIX host, this is easy, if the client is their individual PC, then this isn't as easy.  If the client is another UNIX host, place the Host Public Key (of the remote/server system) in the /opt/etc/ssh/ssh_known_hosts file on the "client" computer.  Next, replace telnet with a link to SSH.


mv /usr/bin/telnet /usr/bin/telnet.orig

ln -s /opt/ssh/bin/ssh /usr/bin/telnet


As this user (who has never used SSH) they are able to login without getting the prompt regarding host authentication because we have put the Public Host Key in the client's system ssh_known_hosts file:


client: telnet ctg701  (remember this is really ssh)

vking@ctg701's password:

Last login: Thu Aug 22 17:24:53 2002 from client



What happens if the ssh_known_hosts file does not exist and a client does not answer "yes" to the prompt?


client: ssh ctg701

The authenticity of host 'ctg701 (' can't be established.

RSA key fingerprint is 6b:0f:f9:ae:e1:ba:54:c2:b5:87:77:30:cf:3a:11:5b.

Are you sure you want to continue connecting (yes/no)? no

Host key verification failed.


The host verification will fail and the user will not be able to login.


Finally, for this article, let's take a look at a connection made in verbose mode. For this connection, the user, vking, does have a local known_hosts file.


client1: ssh -v ctg701                                                        

HP-UX port of OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f

debug1: Reading configuration data /opt/ssh/etc/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.


.rhosts, .shosts, hosts.equiv, and shosts.equiv files are supported with SSH.  The default configuration file disables these features because when used, all the systems that are trusted to each other are only as secure as the weakest system in the group.  The use of these will be discussed in a future article.


debug1: restore_uid

debug1: ssh_connect: getuid 4002 geteuid 0 anon 1

debug1: Connecting to ctg701 [] port 22.

debug1: temporarily_use_uid: 4002/20 (e=0)

debug1: restore_uid

debug1: temporarily_use_uid: 4002/20 (e=0)

debug1: restore_uid

debug1: Connection established.

debug1: read PEM private key done: type DSA

debug1: read PEM private key done: type RSA

debug1: identity file /home/vking/.ssh/id_rsa type -1

debug1: identity file /home/vking/.ssh/id_dsa type -1


Next, the identity file is searched. In this example we do not have. This is covered in Part 2 of this series.


debug1: Remote protocol version 2.0, remote software version OpenSSH_3.1p1

debug1: match: OpenSSH_3.1p1 pat OpenSSH*

Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.1p1


The client and server agree to use SSH-2


debug1: Miscellaneous failure

debug1: No credentials cache file found

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none


The client and server agree to which algorithms to use.



debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: dh_gen_key: priv key bits set: 138/256

debug1: bits set: 1592/3191

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'ctg701' is known and matches the RSA host key.

debug1: Found key in /home/vking/.ssh/known_hosts:1

debug1: bits set: 1619/3191

debug1: ssh_rsa_verify: signature correct


The Public Host Key was found in the user's known_hosts file and the host is authenticated.


debug1: kex_derive_keys

debug1: newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: waiting for SSH2_MSG_NEWKEYS

debug1: newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: done: ssh_kex2.


The session key has been created and the session is encrypted. Finally, it will go through the various authentication methods.



debug1: service_accept: ssh-userauth


debug1: authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive

debug1: next auth method to try is external-keyx

debug1: authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive

debug1: next auth method to try is gssapi

debug1: authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive

debug1: next auth method to try is publickey

debug1: try privkey: /home/vking/.ssh/id_rsa

debug1: try privkey: /home/vking/.ssh/id_dsa

debug1: next auth method to try is keyboard-interactive

debug1: authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive

debug1: next auth method to try is password

vking@ctg701's password:


Since we didn't have any of the other user authentication methods set up, it asked us to type our UNIX login password.


debug1: packet_send2: adding 64 (len 56 padlen 8 extra_pad 64)

debug1: ssh-userauth2 successful: method password

debug1: channel 0: new [client-session]

debug1: send channel open 0

debug1: Entering interactive session.

debug1: ssh_session2_setup: id 0

debug1: channel request 0: pty-req

debug1: channel request 0: shell

debug1: fd 4 setting TCP_NODELAY

debug1: channel 0: open confirm rwindow 0 rmax 32768

Last login: Thu Aug 22 17:51:29 2002 from client



And we have success!                                              


The following is the output of a network trace of the user vking (password = mypass4) logging on and issuing the bdf command using telnet:


   0: 76 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  v...............

   0: 6b -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  k...............

   0: 69 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  i...............

   0: 6e -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  n...............

   0: 67 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  g...............

   0: 0d 0a -- -- -- -- -- -- -- -- -- -- -- -- -- --  ................

   0: 6d -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  m...............

   0: 79 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  y...............

   0: 70 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  p...............

   0: 61 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  a...............

   0: 73 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  s...............

   0: 73 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  s...............

   0: 34 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  4...............

   0: 0d 0a -- -- -- -- -- -- -- -- -- -- -- -- -- --  ................

   0: 62 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  b...............

   0: 64 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  d...............

   0: 66 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  f........


The following is the output of a network trace of the user vking (password = mypass4) logging on and issuing the bdf command using ssh:



   0: 17 47 c1 2f 70 5e bf 1e 8a bf c8 5d ce 22 d9 33  .G./p^.....].".3

   0: 8a ae af f8 e5 19 63 37 db 27 9f 33 71 77 72 01  ......c7.'.3qwr.

   0: c4 0a 46 cb c9 fc d8 87 fe 8b 23 43 ee 9e d4 41  ..F.......#C...A

   0: a1 2e f4 25 82 56 ec bb b9 3a 13 4c d0 ed 21 99  ...%.V...:.L..!.

   0: d7 10 de 3b 52 fd 62 26 2e 8d 34 b0 ef 74 eb 61  ...;R.b&..4..t.a

   0: e1 50 25 3a 78 8e 22 76 09 48 e8 59 83 83 45 f6  .P%:x."v.H.Y..E.

   0: bd 2d aa eb 34 1e a7 23 de de ad a3 7e 9c f8 8d  .-..4..#....~...

   0: 05 f6 c6 e9 59 f2 2f b0 ab 2d 41 dd d0 11 3a 1f  ....Y./..-A...:.

   0: 13 84 af fc 8c e5 19 fd 22 f3 0c 05 a6 51 07 6f  ........"....Q.o

   0: f9 84 71 c1 77 97 e7 69 28 d0 8d 0e 4e 5e a9 1c


So, which one do you think is more secure?


Chris Wong is a technical consultant and trainer based in Bellevue, WA. She is the author of the HP Press book HP-UX 11i Security.  http://newfdawg.com


All Rights Reserved, Copyright 2000 - 2002, TechTarget



SearchHP.com is a search service provided by TechTarget and is completely
independent of and not affiliated with Hewlett-Packard Company.