ssh install on solaris question

tony4704

Senior member
Jul 29, 2003
336
0
0
Anyone know what i need to do, I had an older version of ssh installed on my solaris 9 machine, I then downloaded:
openssh-3.7.1p2-sol8-sparc-local.gz
openssl-0.9.7b-sol8-sparc-local.gz

then did the following:
# gunzip openssh-4.7p1-sol9-sparc-local.gz

# gunzip openssl-0.9.8f-sol9-sparc-local.gz

# pkgadd -d openssh-4.7p1-sol9-sparc-local

# pkgadd -d openssl-0.9.8f-sol9-sparc-local

everything was installed successful, but when I do a ssh -V it is still showing the old version is running. What do I need to do in order for the new installed one to be running? Thanks.
 

kamper

Diamond Member
Mar 18, 2003
5,513
0
0
I'm guessing there's multiple ssh binaries on your system now. Find where the new ones are installed and make sure their location is ahead of the location of the old ones in your $PATH. Or just make an alias from ssh to a full path to the new one.
 

Sunner

Elite Member
Oct 9, 1999
11,641
0
76
Solaris 9 ships with Sun's version of OpenSSH(branded as SunSSH).
If you keep up to date with patches, there's no need to install an external version of OpenSSH, unless you want some new functionality available only in the later versions.

The SunSSH packages are all named "SUNWssh" and a suffix, "pkinfo|grep SUNWssh" will list them all if you want to remove them anyway.
 

tony4704

Senior member
Jul 29, 2003
336
0
0
ok thanks guys, which patches do I download or how do I know im up to date with the latest. Im not so used to Solaris, have been running Gentoo linux and they have a nice little command that syncs your system up to latest patches of everything.
 

tony4704

Senior member
Jul 29, 2003
336
0
0
ok so I removed all of the ssh packages on that server now...where can i get Sun_SSH_1.1 now? thanks!

I am only able to find openssh-4.7p1 on some sun freeware site, but thats the version that I installed before and it still wasnt working with the other servers running the Sun_SSH_1.1.
 

Sunner

Elite Member
Oct 9, 1999
11,641
0
76
The included SSH should work with any server running SSH v1.5 or 2.0, if it doesn't, your problem isn't with the Sun packages.
What error are you getting?
 

tony4704

Senior member
Jul 29, 2003
336
0
0
im not getting any errors, I just keep getting prompted for the user password and its also not auto launching my script upon successful login. I have command="myscripthere" prepended to the public key file. Like I said before its almost as if its not even using the public/private key.
 

Sunner

Elite Member
Oct 9, 1999
11,641
0
76
Originally posted by: tony4704
im not getting any errors, I just keep getting prompted for the user password and its also not auto launching my script upon successful login. I have command="myscripthere" prepended to the public key file. Like I said before its almost as if its not even using the public/private key.

Have you tried simply turning off interactive auth, to make sure it really is?
 

Sunner

Elite Member
Oct 9, 1999
11,641
0
76
Using the default SunSSH config, you edit /etc/ssh/sshd_config
Make sure you have:
"PubkeyAuthentication yes" - should be on by default anyway
"PasswordAuthentication no" - It's on by default, make sure you have a way to access the box other than SSH in case your key auth doesn't work, so you don't lock yourself out ;)
 

tony4704

Senior member
Jul 29, 2003
336
0
0
hmm, the only files located here are:
-rw------- 1 root root 668 Apr 21 2006 ssh_host_dsa_key
-rw-r--r-- 1 oracle dba 607 Apr 21 2006 ssh_host_dsa_key.pub
-rw------- 1 root root 883 Apr 21 2006 ssh_host_rsa_key
-rw-r--r-- 1 oracle dba 227 Apr 21 2006 ssh_host_rsa_key.pub

Its installed in /usr/local/bin but that location does not contain the conf file either.

I played around a bit and tried using some of the files from this directory and now im getting this when trying to connect to one of the other machines that I have a priv/pub key combo for:

Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).

Is that the interactive thing you were talking about? It keeps promppting me for a passwd and it should not be since I dont have one set for it.
 

Sunner

Elite Member
Oct 9, 1999
11,641
0
76
Hmm, so if the config files aren't in /etc/ssh, I guess you removed the SunSSH packages or something?
Could you check what SSH packages you have installed? To make sure you aren't running a whole bunch of them.

Oh and by the way, the directive for denying password auth and allowing key auth goes on the server, not the client, in case that wasn't clear.
 

tony4704

Senior member
Jul 29, 2003
336
0
0
[sun6490em99]MWINMser:/export/home/emsuser/.ssh> ssh -2 -vvv -l emsuser -i id_dsa99 172.23.108.10>
Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to 172.23.108.103 [172.23.108.103] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file id_dsa99.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file id_dsa99 type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.0.1
debug1: match: Sun_SSH_1.0.1 pat Sun_SSH_1.0.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or t
he credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,blowfish-cbc,3des-cbc
debug2: kex_parse_kexinit: aes128-cbc,blowfish-cbc,3des-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: C,geo,lcttab,iso_8859_1
debug2: kex_parse_kexinit: C,geo,lcttab,iso_8859_1
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: Peer sent proposed langtags, ctos: C,geo,lcttab,iso_8859_1
debug1: Peer sent proposed langtags, stoc: C,geo,lcttab,iso_8859_1
debug1: We proposed langtags, ctos:
debug1: We proposed langtags, stoc:
debug1: dh_gen_key: priv key bits set: 128/256
debug1: bits set: 491/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug3: check_host_in_hostfile: filename /export/home/emsuser/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 4
debug1: Host '172.23.108.103' is known and matches the RSA host key.
debug1: Found key in /export/home/emsuser/.ssh/known_hosts:4
debug1: bits set: 499/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug2: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: id_dsa99
debug1: read PEM private key done: type DSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
emsuser@172.23.108.103's password:
debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password)
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 0
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 8
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 0
debug3: tty_make_modes: 7 0
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 11 25
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 16 0
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 1
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 1
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 0
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 1
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 52 0
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 1
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 0
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug2: channel 0: rcvd adjust 32768
Last login: Tue Mar 18 07:46:11 2008 from 172.23.108.99
Sun Microsystems Inc. SunOS 5.9 Generic May 2002
[sun6490em103]TEST:/export/home/emsuser>

Yes I do no have the sunSSH on there because i couldnt find where to download it, I have the OpenSSH version installed.
 

Sunner

Elite Member
Oct 9, 1999
11,641
0
76
Well, as you can see from the version string in the output, you are using SunSSH, but if your /etc/ssh directory only contains the files you listed, the config is hosed(or well, non existent).
I'd start from scratch with the SSH part if I were you, seems like you have at least one set of binaries too much, one set of config files too little, or something in between :)
If you have a set of Solaris CD's around, you can grab the packages off that.
Just do a find on the CD, the packages are all named SUNWssh*
These should all be installed:
system SUNWsshcu SSH Common, (Usr)
system SUNWsshdr SSH Server, (Root)
system SUNWsshdu SSH Server, (Usr)
system SUNWsshr SSH Client and utilities, (Root)
system SUNWsshu SSH Client and utilities, (Usr)
Remove all the OpenSSH packages you have installed currently first though.
 

tony4704

Senior member
Jul 29, 2003
336
0
0
right but that SunSSH is from the client to the server, I ran this command from the client trying to connect to the server. Did you guys want to see it coming out from the server?

thanks Sunner I will try that a bit later when I get some time! :)
 

Sunner

Elite Member
Oct 9, 1999
11,641
0
76
Originally posted by: tony4704
right but that SunSSH is from the client to the server, I ran this command from the client trying to connect to the server. Did you guys want to see it coming out from the server?

thanks Sunner I will try that a bit later when I get some time! :)

Ah, had me a bit confused there...
Ah well, start out fresh with the SunSSH packages on both the server and client to begin with :)
 

tony4704

Senior member
Jul 29, 2003
336
0
0
hmm, I installed the ssh packages from the solaris 10 discs on this solaris 9 box, and then also installed the openssl packages... I am still getting this error now though:

> ssh
ld.so.1: ssh: fatal: libc.so.1: version `SUNW_1.22' not found (required by file ssh)
Killed

I swear, if its not one thing its another.
 

Sunner

Elite Member
Oct 9, 1999
11,641
0
76
Originally posted by: tony4704
hmm, I installed the ssh packages from the solaris 10 discs on this solaris 9 box, and then also installed the openssl packages... I am still getting this error now though:

> ssh
ld.so.1: ssh: fatal: libc.so.1: version `SUNW_1.22' not found (required by file ssh)
Killed

I swear, if its not one thing its another.

Well, the 10 packages more than likely link to newer libraries that are missing on the 9 system, so that's not surprising really, you'll need 9 packages for the 9 box, and so on.
 

tony4704

Senior member
Jul 29, 2003
336
0
0
Right, but then wouldnt i be in the same place i was at the start with a older version of the ssh?
 

Sunner

Elite Member
Oct 9, 1999
11,641
0
76
Originally posted by: tony4704
Right, but then wouldnt i be in the same place i was at the start with a older version of the ssh?

Well, the first posts were a tad short on information, but as far as I could read, at the start of all of this, you had a bit of both installed, as well as lacked files in /etc/ssh ?
 

kamper

Diamond Member
Mar 18, 2003
5,513
0
0
What did you use to generate your private keys (and I mean the one on the client)? It looks like the client couldn't handle it and never tried to use it.
 

QuixoticOne

Golden Member
Nov 4, 2005
1,855
0
0
Whoa... I strongly suggest that you probably DO NOT want to recompile,
reinstall, or otherwise majorly alter the configuration of the SSH client program or the ssh server or the openssl program on EITHER the SERVER or the CLIENTs.

You should ONLY have to make sure the DEFAULT SSH client package is installed on the client machines, and that any available official SUN updates/patches are applied to the system as a whole.

You should ONLY have to make sure the DEFAULT SSHD server package is installed on the server machine, and that any available official SUN updates/patches are applied to the system as a whole. Typically public key authentication should be enabled by default on the sshd server, but if needed you can of course make changes like enabling that authentication mode, or restricting users/hosts etc. by changing the sshd_config file in slight ways. Typically you don't need/want to change anything about it, though, unless you know you should/must.

As for the problem you listed in the trial you conducted, here's my take on that,
and suggestions for how to get this working / tested in incremental steps.

Well the client side (where you were SSHing FROM) vvverbose log looked a little strange but basically OK in the end, I think these are very relevant parts:

debug2: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: id_dsa99
debug1: read PEM private key done: type DSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password

so apparently the ssh client found your private key in id_dsa99 and sent the key to the ssh server, but something didn't succeed in that authentication and it fell back to password authentication which would be expected if the public key didn't authenticate to the server properly.

on the SSH server used in that example there should be a login account called
emsuser
that user should have a home directory, and within that home directory a
.ssh
directory, and within that .ssh directory should be at least these files
authorized_keys
id_dsa99.public

where I really don't know what you named the PUBLIC key file (which I'm calling id_dsa99.public for example) that matches the client side DSA private key file "id_dsa99" which you apparently successfully referred to on the client. So just ensure that you are using the matching public key file and also that the name is changed wherever appropriate to what you call it where I say id_dsa99.public.

id_dsa99.public should be the unmodified public key file of the pair ssh-keygen generated. Actually you could have modified it, or you could not have it as a distinct file on the server, it is not really used directly, but you need the contents of the public key file when you mke your authorized_keys file. After that you don't need anything from the public key file.

In the authorized_keys file there are at least two lines of text. The second (last) line is just blank and is the last line in the file, though of course you can add other things at a future time. The first and only other relevant line of text in authorized_keys is exactly the very long line which is exactly the same as the unmodified id_dsa99.public file you generated with ssh-keygen. Don't even modify it at all, don't add any
command="myscripthere"
to it for a simplest test. Just one long line the same as from the id_dsa99.public file.
In fact if you just copied / renamed the id_dsa99.public file as authorized_keys it would work fine as a simple test. It would run no special script when you authenticated with that key pair in such a case, but it should authenticate automatically and give you a shell prompt on the server.

* The directory home of emsuser on the server MUST be owned by emsuser user and whatever group is their primary group. It should have permissions 700.

* The .ssh directory inside directory home of emsuser on the server MUST be owned by emsuser user and whatever group is their primary group. It should have permissions 700.

* The authorized_keys file inside the .ssh directory inside directory home of emsuser on the server MUST be owned by emsuser user and whatever group is their primary group. It should have permissions 600.


Now ON the SSH server machine, login as emsuser. I assume sshd is running on the server you are logged on to and it is also listening on the localhost address of 127.0.0.1
run:
ssh -2 -vvv -l emsuser 127.0.0.1
..and you should get a password prompt and be able to successfully login with emsuser's password.

ssh -2 -vvv -i id_dsa99 -l emsuser 127.0.0.1
..and you should NOT get a password prompt and yet be successfully logged in to another shell as the user emsuser via SSH. You must of course have made a copy of the PRIVATE key file id_dsa99 and have that be of a readable permission for emsuser in the current directory when you issue the ssh command for this test.

If it is working so far, the server is correctly setup to authenticate with the public/private keypair you generated into the account for emsuser. As long as your firewall and sshd configuration on the server permits, it should be similarly possible to ssh in via the expected / configured set of other machines on the network in just the same way.
Now is a good time test it from other machines too just to ensure you can authenticate and get a shell as emsuser.

Now to modify the file authorized_keys file, you just go to the server, to the home directory of emsuser, to the .ssh directory under there, and use a text editor to open authorized_keys. It should be *identical* to the unmodified to id_dsa99.public at this time.

Put the cursor on before the first character of the first line of the file and just type
command="/home/emsuser/.ssh/myscripthere"
followed by a single spacebar space. Do not hit enter/return. There should still only be two lines in the file, the one you've prepended to, and the blank line after it.
The start of the line now looks like:
command="/home/emsuser/.ssh/myscripthere" ssh-dss
followed by a space and followed by a long character string of your key and so on from the unmodified contents of the id_dsa99.public file.

Now you must ensure that /home/emsuser/.ssh/myscripthere is actually a script in the expected location.
/home/emsuser/.ssh/myscripthere must have permission mode number 755.
/home/emsuser/.ssh/myscripthere should have ownership of user emsuser, and a group of whatever emsuser's primary group is. Of course you can change the script path and name to another program location but it must be at least executable by emsuser.
If you do not have confidence your script will work and be executable while logged in as emsuser over SSH either test and verify that it is good, or do a test like this instead:
command="/bin/date"
could be substituted in your authorized_keys file as a test, then when you successfully authenticate with that key pair it will just show you the date and disconnect if everything works well. Of course verify that /bin/date is the right location for your date command on your server, maybe it is /usr/bin/date or something else, run "which date" from the command prompt as emsuser to verify the full pathname.

Of course everything else about authorized_keys -- the two lines, the command prepending, the space, the rest of the public key file, the REQUIRED file location / ownership / permissions of authorized_keys remains the same as before.

Now from the server, login as emsuser to a shell,
ssh -2 -vvv -i id_dsa99 -l emsuser 127.0.0.1
..and you should NOT get a password prompt, but your selected "command" should run and produce whatever output it can produce (e.g. the current date if you've used that as a test command), and then disconnect the ssh session when it has finished running. Of course as before you must have the id_dsa99 private key file accessable in the current/specified location while you run this test

If that works then you know your server is running the desired command over SSH, so now all you should have to do is ensure it can be done when ssh clients are run from your selected remote hosts. The same ssh command line is used just with some other host name or host address (that of the server) instead of 127.0.0.1 as the ssh destination on the ssh command line. Of course you'll need a correctly specified local copy of the id_dsa99 private key file which must be readable by the user running ssh on the remote system when you run the ssh command.

 

Sunner

Elite Member
Oct 9, 1999
11,641
0
76
Originally posted by: QuixoticOne
You should ONLY have to make sure the DEFAULT SSH client package is installed on the client machines, and that any available official SUN updates/patches are applied to the system as a whole.

This is the only thing I would do to begin with.
Trying to fiddle with things, trying to fix them or whatever, when you have a potentially broken environment, is just a waste of time in my mind.