ssh under OS X.1.2

E

ericmurphy

Registered
My new G3 iMac arrived yesterday, and it is indeed a sweet machine (although the 1042 X 768 takes some getting used to after the 1600 X 1200 on my 19" monitor attached to the G4). I noticed something weird with ssh on the machine though. I tried connecting via ssh from my G4 (which is also running OS X 10.1.2), and I got the usual message about the unknown validity of the key, etc., but the iMac wouldn't accept my password.

Okay, here are the things I checked:

ssh is enabled in the sharing preference panel.

The password and account are good. I used both to connect no problem via ftp.

The same problem occurs attempting to connect with other username/passwords.

It's not the client machine, because neither my linux box nor my PowerTower running OS 9 and Nifty Telnet could connect either.

It doesn't work with the -l option, and it doesn't work without the -l option.

Anyone else have any ideas?
 
First thing to try is using ssh in verbose mode: ssh -v -v user@hostname and see what kind of info that tells us. Definitely odd that ftp would work but ssh wouldn't.
 
Okay, here's the end of the output from ssh when I try to log in. It seems like everything is working okay until it doesn't accept my password (which I know to be correct):

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /Users/eric/.ssh/known_hosts2:4
debug1: bits set: 1012/2049
debug1: ssh_rsa_verify: signature correct
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.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /Users/eric/.ssh/identity
debug1: try privkey: /Users/eric/.ssh/id_rsa
debug1: try privkey: /Users/eric/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: next auth method to try is password
eric@64.163.84.13's password:
debug2: packet_inject_ignore: current 56
debug2: packet_inject_ignore: block 16 have 4 nb 4 mini 1 need 4
debug2: we sent a password packet, wait for reply
debug1: authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
 
That definitely looks completely normal, until the permission denied of course. On the machine to which you're attempting to ssh, have you changed anything in /etc or in /Users/username/.ssh?
 
No, the machine is basically completely stock (I started it up for the first time yesterday afternoon). The only thing I've done in /etc is create an ftpchroot file to keep ftp connections confined to the user's home directory. I haven't done anything with .ssh at all, other than back it up (I haven't restored it).

And, the same thing happens with every account (although at the moment there are only two accounts created on the machine anyway).
 
Originally posted by ericmurphy
And, the same thing happens with every account (although at the moment there are only two accounts created on the machine anyway).
Click to expand...

Does this include root? Also, is there anything logged to /var/log/system.log besides

Code: 
Jan 15 21:01:49 myhost sshd[8870]: Failed password for username from 192.168.7.8 port 33794 ssh2
 
This may be astupid question, but are you sure that you are logging is as a user that exists on you iMac?
 
Root can't log in either under sssh or ftp, because I usually keep the root user disabled unless I need it for something.

I'm definitely logging in as an account that exists on the system; the same username and password works fine for ftp; but can't get in using ssh.

Here's what shows up in the system log when I attempt to log in via ssh:

Jan 16 08:54:06 adsl-XXX.XXX.XXX.XXX sshd[111]: input_userauth_request: illegal user eric
Jan 16 08:54:06 adsl-xxx.xxx.xxx.xxx sshd[111]: Failed none for illegal user eric from xxx.xxx.xxx.xxx port 54924 ssh2
Jan 16 08:54:10 adsl-xxx.xxx.xxx.xxx sshd[111]: Failed password for illegal user eric from xxx.xxx.xxx.xxx port 54924 ssh2
Jan 16 08:54:16 adsl-xxx.xxx.xxx.xxx last message repeated 2 times
Jan 16 08:54:16 adsl-xxx.xxx.xxx.xxx sshd[111]: Failed keyboard-interactive for illegal user eric from xxx.xxx.xxx.xxx port 54924 ssh2
Jan 16 08:54:16 adsl-xxx.xxx.xxx.xxx last message repeated 2 times
Jan 16 08:54:16 adsl-xxx.xxx.xxx.xxx sshd[111]: Connection closed by xxx.xxx.xxx.xxx
 
Well, I can't say I actually figured out what the problem was, but I did finally do what I should have done to begin with, i.e., shut down sshd and start it back up again.

Once I did that, the problem went away.
 
One thing I'd like to check is whether or not you had a local user logged in at the time or not.

I'm having problems connecting through SSH when a local user is NOT logged on even though that shouldn't be the case.

I have the default install of SSH (going to try Stepwise's upgrade tonite) as well as having had set my SSH configuration through SSH Helper from Gideonsoftworks.com

Cheers.
 
I haven't noticed any problems logging in via ssh when no one is logged in on the console. Normally I am logged in locally, but there doesn't seem to be any difference with ssh whether a user is logged in locally or not.
 
I've had slow to connect, and what seemed suspiciously like what you're describing when I was trying to do stuff between machines that had conflicting name information. The reboot may have flushed cache, and everybody was on the same page then.

I haven't dug too deep into ssh, but I don know that the lack of a name lookup can be a real drag on remote login. You could try configuring netinfo to have name - ip associations for the machines involved. ... or just reboot. Whatever's easier. :)
 
I had some trouble with SSH as well. The easiest solution seems to be the commercial SSH from SSH Communications Security, which is free for non-commercial purposes, like mine. I downloaded the source code at commerce.ssh.com; it compiled very easily out of the box, and was installed in /usr/local, so my OpenSSH in /usr was unaffected.
I changed /System/Library/StartupItems/SSH/SSH appropriately: changed /usr/sbin/sshd to /usr/local/sbin/sshd, killed the sshd that was running, and now my iBook runs the new SSH daemon in //usr/local.
No more trouble (so far). Of course, the disadvantage is that you can't do this if you use ssh for commercial purposes.
 
It looks as though Fink will manage the installation and upgrade process for both OpenSSL and OpenSSH at this point, which means that you can completely override Apple's installations.

I say "it looks as though..." because I upgraded both packages following the stepwise.com porting directions, which worked well for me. But Fink has done a good job of porting other apps for me, and I have no reason to believe it would screw up either of these packages.

Bottom line: it's a good idea, especially with security/crypto, to manage the installations yourself and not wait for the OS vendor to put out an update. That way you know you're up to date, and you know where everything is.
 
Actually, for most mac users, the mac is a tool instead of a hobby, and security upgrades are something that the OS vendor is more likely to know and care about than the user. I cite NT with Nimda. If NT had a default auto-install setup that virus probably would have been about half of what it was (is still) so ... anyone who's paranoid enough to install their own ssh/ssl maybe they'll be quicker than the OS vendor. Anyone who's actually taking advice like that from these boards, probably isn't 733t enough to be managing his/her own ssh.

My point is ... I don't think there's actually anything wrong with Apple's install of the tools, I think the tools are inherently touchy, especially if you set them up in the most secure config. It frightens me to have anyone tell a casual user to install their own security package displacing the default one. It's kinda like telling people not to point a gun at their own face. You may have a point, but perhaps anyone who really benefits from this message shouldn't be weilding a gun in the first place. ... my $0.02
 
Yes, agreed. I never know exactly who the audience is here (who really does?), but it seems to be a wide variety of user levels.

Here's the caveat of the day: if you DON'T know

* where most config files are located on your system
* the significance of the PATH in your ENV
* the difference between /sbin and /usr/sbin
* what a daemon is
* why inetd handles some daemons and others run standalone
* anything about encryption

-- if you are a "casual user", from the *nix point of view, you probably shouldn't be following my advice. My new friend theed here is absolutely right when he points out that the OpenSSL and SSH packages installed by Apple are perfectly adequate, and I trust Apple enough to believe that if there were a critical security update published to either package in the outside world they would publish an OS X update.

That having been said :), the Stepwise instructions for porting are pretty clear, and Fink probably does a good job of it too!
 
I guess what I find difficult to explain is that I have two installations of OS X 10.1.2, one a G4 and one an iMac, both with identical versions of ssh. The installation works fine on the G4; it's a bit iffy on the iMac. The only problem on the iMac is this necessity of stopping and restarting ssh every once in a while when it denies permission to all users.

Strange.

I guess I COULD restart the iMac. But I've only started it once: when I turned it on after I took it out of the box. It hasn't restarted since, and I want to see how long it will stay that way. It's been up 11 days so far, and I'm not sure I've even had an application lock up on it, let alone a system failure requiring a restart.
 
This happened to me and it turned out that it was because I'd changed my default shell to /bin/bash, which wasn't listed in /etc/shells. SSH won't let you log in if your shell isn't in /etc/shells.
 
You must log in or register to reply here.
Back
Top