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
Installation:
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
The
root user will now have a .ssh directory:
drwx------ 2 root sys 96 Aug 8
and
the following file will be under it:
-rw------- 1 root sys 1024 Aug 8
The
following entry is added to the syslog.log file:
Aug 8
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.
Terms:
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
-rw-r--r-- 1 root sys 330 Aug
8
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
-rw-r--r-- 1 root sys
601 Aug 8
-rw------- 1 root sys
883 Aug 8
-rw-r--r-- 1 root sys
221 Aug 8
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
-rw-r--r-- 1 root sys
221 Aug 22
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
-----BEGIN RSA PRIVATE KEY-----
MIICWQIBAAKBgQDgAsGmyfF3XqXFVfhLCkw/ml6yF7JnpX5M9NzxEsAeX/aiA+HE
n/gd32SXNVe58lepgVECOdwd8HeMGr14feNnYrmXLLkY0rqvDib3LC2+un4lksCJ
rd4lMcQ+omXGNihKLjVVdtBOyk1pt3NqQyGZ2eLhq2lz1kDg/WU5feGaSwIBIwKB
gGzOI4uGqHvO4s2QKCRyt1IXx5hUpxxmU0nzRr48Tq+q9CLOr3zCulenBPj8pvPq
vN1NcH1sj3xBmSbLKNQf43pzKSmUluBL/FGYgursLrc5pk72cBQNfYisWqch9qIs
ZWaBKBavn3nk2y8e4r0unicCiBUX52upaUKdgnzBFRBTAkEA9Fkz/IpeSjfk4FCU
kFCN7faDm6a+N6Wm/EfMKTOqHDKnpZM+XHZGIkC+/4CQlQdn0ASk6kAWeWJoAkQd
BC1qVQJBAOqxSdEWOAowBBH2Bnle5L9ASrBvR9Lqvyz+C1Fjguu7dSRenRov0XaF
pA7y27eJSyLGEVO2UoecWT5fwUaI0h8CQFPGz/7QWteeIpYM/7xzY9yPCI0jOecx
exSq5umODnARXgziBsCdlGOD6bavvIrd97UI6BXM1IFjkV/c1r+aitsCQH9njnjR
jCLJm888aeodkh6t32cX1ohwzi5eBiTeP8HMKaYHedsEA/6DD+rbm9ipndEMb85b
qSULu2sAyAG3/QkCQEZojhAG0qyQ6ssAoItHi6ml++PaBAZTY+nw/c73CbViAWNF
YapKzxIJdBRSBR4EyS2auaDSwkbJ9F5OlIdylrw
-----END RSA
PRIVATE 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.
|
Key |
Purpose |
Type |
Comments |
|
Host |
ID
of SSH Server |
Asymmetric
Persistent |
Private
not encrypted |
|
Server |
Used
to create Session Key |
Asymmetric Not
Persistent |
Only
used with SSH-1 |
|
User |
ID
of SSH Client |
Asymmetric
Persistent |
Private
is encrypted |
|
Session |
Used
to encrypt the session |
Symmetric 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 (192.168.1.125)' 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,192.168.1.125' (RSA) to the list of
known hosts.
jrice@ctg701's password: [enter your UNIX login password]
Last login: Thu Aug 22
ctg701:
"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
-rw------- 1 jrice users 1024 Aug 22
client: more .ssh/known_hosts
ctg701,192.168.1.125 ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEAt2FJStwxsE/COE9vvE6COgS
s+Ow9i71zMqb75RtsVttMrxqZYboy9J4/STdQqrd3d5uEaBcq6F2Hi54A67Kizy1H2wwSj54S8sOfU5n5jy3KzrJARNghs+A99Yku9kTdhD3J6Cld675Q7nDxhodcGvzcNmPsL2OIYW2SB3nFx3M=
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
ctg701
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
root 3576 2455
0 16:22:32 ? 0:01 sshd: jrice@0
jrice
3578 3576 0
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
ctg701:
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 (192.168.1.125)' 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 [192.168.1.125] 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: SSH2_MSG_KEX_DH_GEX_REQUEST sent
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: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
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
ctg701:
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 |
||