Go Back   The macosxhints Forums > OS X Help Requests > UNIX - General



Reply
 
Thread Tools Rating: Thread Rating: 14 votes, 5.00 average. Display Modes
Old 09-20-2007, 02:30 PM   #1
father2a-f
Prospect
 
Join Date: Jan 2004
Location: Los Angeles, CA
Posts: 17
Question SSH Key Failure on One Account

For a few of my users, I use rsync to backup their home directories from our file server (OS X Server 10.4.8). I have a script that runs twice a day to do this for a list of users. That part works. I use public key authentication to get this done and I upload the keys to the users .ssh directory (on their computer's local home directory) and verify access from the server end as part of the set-up process.

This is where it gets strange for one user's account, in particular. And as the gods would deem it, it has to be my boss's PowerMac G5 (running 10.4.10), of course :-\. Anyway, I performed the usual to get this going:
  • created his .ssh directory in his home directory and set permissions
  • uploaded the SSH keys to the authorized_keys file
However, when I attempted to verify passwordless, SSH access from the server (after I added it the known_hosts file), it still continues to ask for a password!?! I checked his authorized_keys file and everything is in order. Next, as a test, I performed the exact same procedure on another local account on his same machine. But, that one works as expected!?! On that account, the SSH sessions goes straight through without a password.

I'm mystified that this fails on that one account. Anyone have any suggestions on why this is so? Thanks in advance.
__________________
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again." ~ F. P. Jones
father2a-f is offline   Reply With Quote
Old 09-21-2007, 12:47 AM   #2
bryanc
Prospect
 
Join Date: Aug 2006
Posts: 47
Hmm... well nothing comes to my mind, but you might try running "ssh -v" (verbose) with both the account that works and the one that is failing, and then compare the output. It may shed some light on what specifically is different.
bryanc is offline   Reply With Quote
Old 09-21-2007, 03:20 AM   #3
Lutin
Major Leaguer
 
Join Date: May 2006
Location: Paris, France
Posts: 311
Have you looked at his ~/.ssh/config file?
It's where the options to use with ssh are stored. You can override them by the command line for one shot.


Have a look at the man of ssh_config (man ssh_config in the terminal).

Look specifically this section: PreferredAuthentications and PubkeyAuthentication.

As Bryan stated, the verbose mode can help understanding what's wrong. Multiple -v options increase the verbosity. The maximum is 3.

Hope that help.
Lutin is offline   Reply With Quote
Old 09-21-2007, 12:32 PM   #4
father2a-f
Prospect
 
Join Date: Jan 2004
Location: Los Angeles, CA
Posts: 17
Thanks bryanc and Lutin for your suggestions. I put the it in max verbose mode to see what's happening between these two accounts. For the one that works, here is what seems the important passage:

Code:
debug1: Trying to start again
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /private/var/root/.ssh/identity
debug3: no such identity: /private/var/root/.ssh/identity
debug1: Offering public key: /private/var/root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Offering public key: /private/var/root/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 818
debug2: input_userauth_pk_ok: fp fe:60:fc:54:2e:aa:de:30:15:1a:82:c4:f1:44:c0:6b
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty_make_modes: ospeed 9600
debug3: tty_make_modes: ispeed 9600
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 127
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 255
debug3: tty_make_modes: 7 255
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: 17 20
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 1
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: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 0
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 1
debug3: tty_make_modes: 70 1
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
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
Last login: Thu Sep 20 15:38:24 2007 from cshsmedaff3.csm
Welcome to Darwin!
[romanoff:~] admin%
Here the same in the one that doesn't work on the same machine:

Code:
debug1: Trying to start again
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /private/var/root/.ssh/identity
debug3: no such identity: /private/var/root/.ssh/identity
debug1: Offering public key: /private/var/root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Offering public key: /private/var/root/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
Now this is my first time reading such ssh exchanges, but the problematic account seems to try all authentication methods. What are your thoughts? And, if I create a ~/.ssh/config file and set the preferred to publickey only, will that resolve this? Thanks, again.
__________________
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again." ~ F. P. Jones
father2a-f is offline   Reply With Quote
Old 09-21-2007, 10:50 PM   #5
bryanc
Prospect
 
Join Date: Aug 2006
Posts: 47
The ~/.ssh/config (and also /etc/ssh_config) are the ssh client configuration files. Unless I misread you, changing them on the target machine (i.e. your bosses), isn't going to change anything, since you are initiating the connection from your server to the ssh daemon on your bosses computer. Your server is the ssh client in this scenario, and the G5 is the ssh server.

The file /etc/sshd_config controls incoming ssh connections. Look specifically for the string "Match User" in that file (I'm pretty sure that's the only way the server can be configured to respond differently based on which user it is dealing with).
bryanc is offline   Reply With Quote
Old 09-24-2007, 12:15 PM   #6
father2a-f
Prospect
 
Join Date: Jan 2004
Location: Los Angeles, CA
Posts: 17
Thanks for the clarification. I'm going to try this.
__________________
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again." ~ F. P. Jones
father2a-f is offline   Reply With Quote
Old 10-05-2007, 02:46 AM   #7
Lutin
Major Leaguer
 
Join Date: May 2006
Location: Paris, France
Posts: 311
How did it go? Is your problem fixed?
Lutin is offline   Reply With Quote
Old 10-08-2007, 03:23 PM   #8
father2a-f
Prospect
 
Join Date: Jan 2004
Location: Los Angeles, CA
Posts: 17
Got pulled away to server with new hardware that's keeps going deaf to AD. But, I plan on coming back to try the recent suggestion. Thanks.
__________________
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again." ~ F. P. Jones
father2a-f is offline   Reply With Quote
Old 11-08-2007, 09:20 PM   #9
forbin
Triple-A Player
 
Join Date: Jan 2005
Location: Rochester, NY
Posts: 123
I'll continue as I have the same issue .. I've been banging my head against the wall. I have 4 Macs .. ssh public key authentication is working on all except for 1. I added my 'home' public key to my daughters Mac ~/.ssh/authorized_keys2 .. I validated that permissions on .ssh and the files within are valid on her Mac. I always fail public key authentication and fall through to Password authentication. I thought This would have worked once I upgraded my daughters Mac to Leopard .. but still have the same problem. I ran a trace .. Hoping someone can spot the issue .. (I have 2 keys - 'home' and 'work'. These are also listed within the 'IdentityFile' records in my ~/.ssh/config and I should be authenticating on the 'home' key :

[22:13:31][richard@RLRMBP]~/.ssh$ ssh -vvv stephanie@192.168.168.101
OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /Users/richard/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.168.101 [192.168.168.101] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /Users/richard/.ssh/work.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/richard/.ssh/work type 1
debug3: Not a RSA1 key file /Users/richard/.ssh/home.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/richard/.ssh/home type 1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5
debug1: match: OpenSSH_4.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 137/256
debug2: bits set: 494/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /Users/richard/.ssh/known_hosts
debug2: key_type_from_name: unknown key type '1024'
debug3: key_read: missing keytype
debug3: check_host_in_hostfile: match line 58
debug1: Host '192.168.168.101' is known and matches the RSA host key.
debug1: Found key in /Users/richard/.ssh/known_hosts:58
debug2: bits set: 502/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/richard/.ssh/work (0x103570)
debug2: key: /Users/richard/.ssh/home (0x1081b0)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred 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: Offering public key: /Users/richard/.ssh/work
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Offering public key: /Users/richard/.ssh/home

debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:


Thanks for any pointers
forbin is offline   Reply With Quote
Old 03-04-2008, 04:51 PM   #10
LizardtheFish
Prospect
 
Join Date: Feb 2004
Location: a padded cell with nothing but my laptop and the voices in my head
Posts: 19
Solution?

Did anyone have any luck pinpointing the issue of the problems in this thread? I'm having the exact issue.

Thanks for any posting back of the solution.

Scott
__________________
..................
........O........
.....~//~......
.....~\\~......
......../.........
........\.........
..................
LizardtheFish is offline   Reply With Quote
Old 03-06-2008, 01:50 PM   #11
ashevin
Triple-A Player
 
Join Date: Jan 2002
Posts: 158
One thing that has not been mentioned is whether the logins to these accounts actually works when the correct password is entered. In my work with ssh, I have come across two issues that can cause ssh to fail with what seem to be authentication issues.

1) Expired passwords. Even when using pubkey, if the password is expired, ssh may still fail. This is most common on systems using PAM.

2) Permissions. Some of the posts (inc. the OP) mention checking permissions on .ssh and the contained files. It should be noted that ssh also cares about the permissions on the home directory of the user. If these are too permissive (and/or too restrictive), ssh will fail.

If someone in this thread could post the results of
Code:
ls -ld ~problemuser
we might be able to figure this one out.
ashevin is offline   Reply With Quote
Old 04-21-2008, 03:52 PM   #12
father2a-f
Prospect
 
Join Date: Jan 2004
Location: Los Angeles, CA
Posts: 17
Thumbs up Solved

Finally surfaced again and reviewed all of the replies here. And, it came down to permissions, as expected by others in this thread. After a failed attempt, I tail'd the secure log (/var/log/secure.log). I noted this there:

Code:
Authentication refused: bad ownership or modes for directory ...
Google then sent me here, where I scrolled down to my solution:

Quote:
Permissions
If any of the files (or directories leading up to the files) have permissions set too loose, the connection will fail. Permission errors may be logged on the server side by the sshd(8) daemon.

Code:
Authentication refused: bad ownership or modes for directory …
In most cases, potential permission problems can be solved by restricting down access to the SSH configuration files. Permission changes to the home directory might be needed, though restricted rights may break other things, such as a webserver’s access to ~/public_html, for example.
Code:
server$ chmod go-w ~/
server$ chmod 700 ~/.ssh
server$ chmod 600 ~/.ssh/authorized_keys

Performing these commands on the user's account did the trick. Thank you, heartily, for those who replied and helped me (and hopefully, others), find this solution.
__________________
"Experience is that marvelous thing that enables you to recognize a mistake when you make it again." ~ F. P. Jones
father2a-f is offline   Reply With Quote
Old 06-18-2011, 07:13 PM   #13
jstjohn
Guest
 
Posts: n/a
Thank you!!!!

Quote:
Originally Posted by ashevin
One thing that has not been mentioned is whether the logins to these accounts actually works when the correct password is entered. In my work with ssh, I have come across two issues that can cause ssh to fail with what seem to be authentication issues.

1) Expired passwords. Even when using pubkey, if the password is expired, ssh may still fail. This is most common on systems using PAM.

2) Permissions. Some of the posts (inc. the OP) mention checking permissions on .ssh and the contained files. It should be noted that ssh also cares about the permissions on the home directory of the user. If these are too permissive (and/or too restrictive), ssh will fail.

If someone in this thread could post the results of
Code:
ls -ld ~problemuser
we might be able to figure this one out.


WOW, I have tried and re-tried so many tutorials on this until I stumbled on this little nugget about even the permissions on the home directory mattering. I ran `chmod g-w .` from my home directory and now everything works!!!! THANKS!!!
  Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



All times are GMT -5. The time now is 01:26 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Site design © IDG Consumer & SMB; individuals retain copyright of their postings
but consent to the possible use of their material in other areas of IDG Consumer & SMB.