need help with an SSH problem
 

Hi:

I'm trying to set up an SSH connection on my local network. I've generated DSA key pairs for all machines concerned, and distributed the public keys, but I can't seem to get a connection going correctly.

When I try to connect ssh me@blah.blah.blah I get this message:

The authenticity of host 'blah' can't be established.
RSA1 key fingerprint is blah.

and I get this line in the console:

service ssh, IPV6_ADDRFORM setsockopt() failed: Protocol not available (errno = 42)

Now I've seen some discussions about this message, but not quite in this same context. Anybody know why it is I can't get this thing going?

What version of OpenSSH are you running on the client and what version on the server? Or are you running something other than OpenSSH? If so, exactly what?

Trevor

both machines are running the 3.6.1 version on 10.3.3, and I'm not running anything additional that might interfere with SSH other than possibly Brickhouse.

Can you give us the line from /etc/ssh_config on the client machine and /etc/sshd_config on the server machine that refers to Protocol? For example, it may be something like:

Client: ssh_config
# Protocol 2,1

Server: sshd_config
Protocol 2

The above would indicate that your client is using default settings (it has the # preceding the line, which anyhow allows both ssh protocols 1 and 2) while the server only allows ssh protocol 2.

If you have something like:
Client: ssh_config
Protocol 1

Server: sshd_config
Protocol 2

...then we've found the problem.

Trevor

Another thing I'm wondering about is the part of the error message you mentioned:
Are you using IPV6 IP addresses? What unusual setup do you have in regards to IPV6?

Trevor

In answer to your first question, the only change to the default setup for SSH I have made is to disallow root login in sshd_config:

PermitRootLogin no

I haven't made any changes to ssh_config so the protocol specification is still commented out as:

# Protocol 2,1

Regarding IPV6, I haven't done anything with this. It's all still on auto pilot.

Thanks for your help.

Just for the heck of it; go into the Network prefpane and disable IPv6 for the interface you're using (probably builtin ethernet). See if that helps.

No dice. Tried IPv6 off on both client and server, but the server still reports service ssh, IPV6_ADDRFORM setsockopt() failed: Protocol not available (errno = 42)

and ssh still reports The authenticity of host 'blah' can't be established. RSA1 key fingerprint is blah.


Why do you suppose it is trying to do RSA verification when I have explicity requested DSA verification?

ssh -2 me@blah.blah.blah

Here is the beginning of the debug output from SSH:

debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /Users/JDR/.ssh/id_rsa.
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


So it seems that SSH is not happy with the private key. Why, I can't begin to guess. In the second place, why does it keep trying to use RSA authentication when I have explicity told it to always DSA and never use RSA?

To get rid of the IPv6 stuff edit your file:

/etc/xinetd.d/ssh

and change:

flags = REUSE IPv6

To:

flags = REUSE IPv4

I will also help to get rid of the
lines if you are getting them.

Nothing is worse than reading someone's posted log only to find when it gets to the interesting par

t it gets cut off! :)

post all the output.

Here is a successful connection:

I think many people are (properly) concerned about flooding the boards with their log files. Of course on this forum, using the code tags like you did in your next post makes a nice text window with scroll bars...

Eh, don't mind me, I'm just rambling.

I suppose I did not really say what I wanted to point out...

Even with a good connection, there are parts of the debug output that look like failures. Therefore you cannot really tell what is going on without seeing all the data (including the command that is used to produce the output).

Maybe '-vvv' is a bit of over kill, I suppose he could start with '-v' or '-vv' and see if we need more....

Here's the whole log, after making changes to SSH:

Ok, it looks like your remote host is not being found in the .ssh/known_hosts file on your originating machine.

If, on the originating machine, you do a does it find a key? I don't think it will.

You might want to google for 'set up ssh keys' which will provide many hits for setting up your keys correctly.

I have set up each machine so that it has all the public keys of the others. My understanding of known_hosts is that addresses are written to it by SSH, and after keys have been resolved and the connection made. Is this incorrect?

Darn, I was sure I submitted a reply to this a few minutes ago, but I guess I screwed up the post.... Anyway, it went something like:

D'oh, right you are.

What does:
show on your client and server?

As well, on the client,
PS. splitting headache today, so take what I say with that in mind.... :(

Don't worry, it's probably not a tumor... :D

Server:


Client:

Have you tried putting the public keys in the file

authorized_keys2

rather than the file

authorized_keys

?

No joy.

Ok, here is a detailed description of the conditions. I have tried to set things up to emliminate any extraneous influences.

CONDITIONS:
- server and client are now directly connected by CAT5 and have manually specified addresses.
- no firewall on either end
- remote login is started
- can ping both sides, client can see that server port 22 is open and listening


CONFIGURATION FILES (these are the same on both client and server):
- /etc/sshd_config:
- My changes from the stock sshd_config are:
1) set "Protocol 2"
2) set "LogLevel DEBUG3"
3) set "PermitRootLogin no"

- ~/.ssh/config:
- There is some redundancy here, but my changes from the stock sshd_config are:
1) set "RSAAuthentication no"
2) set "Protocol 2"
3) set "HostKeyAlgorithms ssh-dss"
4) set "LogLevel DEBUG3"
5) set "User JDR"

SETUP AND EXECUTION:
1) Generate keys on server and client "ssh-keygen -t dsa"
2) Exchange public keys where each public key becomes "~/.ssh/authorized_keys" and also (for good measure) "~/.ssh/authorized_keys2"
3) Idiot check that there are not line feeds in these files
4) try the connection "ssh 192.168.0.9" or "ssh -l JDR 192.168.0.9" OR "ssh JDR@192.168.09"
5) piss and moan

I won't inlcude again the client reponse, but here is what is logged on the server:

Well, I just replaced my ssh_config and my sshd_config with yours on both my Uni and home machine, and I can still connect with no problems.... I do get this and my ~/.ssh/known_hosts is updated with a DSA key. So it is using DSA and still working. This is using 'ssh myuser@myhost.org' As the User entry in the ssh_config file trys to log in as JDR. Note the User keyword does not seem to be valid in sshd_config, at least I could not find it in the man page.

So, it does not seem to be your '_config' files. A long shot, and one I don't expect it to be, but you username is all uppercase. have you tried with a user with lowercase name? In fact, what you may want to do is to create a generic user on both machines, set all config files back to standard, set up keys and try to get it to work then. If it works, then slowly add one change at a time until it breaks. If it doesn't, then we will see where that leads us.

I am still having serious issues logging into my Linux box after upgrading to 10.3.4. I have been admin this headless Linux box for over 2 years from the OS X box via SSH with no problems whatsoever. After updating to 10.3.4 - I can no longer login to the Linux box. Nothing has changed on the Linux box either.

I can verify that port 22 is still available on the Linux box, and I have tried deleting keys from the the OS X box as well as the whole .ssh dirs - stil no luck. Here is a typical session - hope someone can offer some advice... I'm stuck!

Are you sure the sshd on the remote host is not dying? I would start it up in debug mode and see what it is doing when the SSH2_MSG_KEXINIT is received.

Yes I am sure the sshd isn't dying on the remote server. This is on a very stable production server that has been rock solid with ssh for the last 2 years. Only after the latest Security Update/10.3.4 update have I been unable to access it.

i am seeing the problem too. two weeks ago, i was able to access an ssh server. now (after the recent security update), i am not. running ssh with -v option, i see what look to be a lot of the same error messages "an invalid name was supplied", "configuration file does not specify a default realm", etc.

anyway, i just wanted to confirm that it appears that something broke due to the security update. i can still access some hosts normally. just one host is broken. i'm not sure how to fix it.

davidduff,

Is your remote server at this version as well? Maybe it is an incompatibility between versions...

From bluehz This sure looks like the remote server is shutting down the connection... Maybe a verbose dump of what the sshd is doing may shed some light...

I finally solved my problem after a lot of log watching, debugging on the server. Seems the server was looking for a dir named /var/empty and this dir did not exist. Why the server all of the sudden required this dir is beyond me. I have not modified the server or deleted anything in over 3-4 weeks, and the problem just started last week.

Anyway - as soon as I created a /var/empty - I was able to login again from 10.3.4.

From here (first google hit on '/var/empty ssh') Does the 'privilege separation' bit ring any bells?? I think something must have changed on the server. You also might want to make sure /var/empty is set up correctly as mentioned above.

I suppose it is possible that this 'privilege separation' thing only happens on the server for new versions of the client, but that seems pretty weird if it is so....

PS. told you the server was dying! :D (couldn't resist)

Very interesting! Thx!