The macosxhints Forums - need help with an SSH problem

The macosxhints Forums (http://hintsforums.macworld.com/index.php)

- Networking (http://hintsforums.macworld.com/forumdisplay.php?f=14)

- - need help with an SSH problem (http://hintsforums.macworld.com/showthread.php?t=23917)

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

Code:

May 21 11:00:17 Mutsu xinetd[1001]: xinetd Version 2.3.11 started with libwrap options compiled in.

May 21 11:00:17 Mutsu xinetd[1001]: Started working: 1 available service

- 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:

Code:

#Port 22

#Protocol 2,1

Protocol 2

#ListenAddress 0.0.0.0

#ListenAddress ::



# HostKey for protocol version 1

#HostKey /etc/ssh_host_key

# HostKeys for protocol version 2

#HostKey /etc/ssh_host_rsa_key

#HostKey /etc/ssh_host_dsa_key



# Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 3600

#ServerKeyBits 768



# Logging

#obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH

#LogLevel INFO

LogLevel DEBUG3



# Authentication:



#LoginGraceTime 120

PermitRootLogin no 

#StrictModes yes



#RSAAuthentication yes

#PubkeyAuthentication yes

#AuthorizedKeysFile     .ssh/authorized_keys



# rhosts authentication should not be used

#RhostsAuthentication no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

# For this to work you will also need host keys in /etc/ssh_known_hosts

#RhostsRSAAuthentication no

# similar for protocol version 2

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no



# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no



# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes



# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes



#AFSTokenPassing no



# Kerberos TGT Passing only works with the AFS kaserver

#KerberosTgtPassing no



# Set this to 'yes' to enable PAM keyboard-interactive authentication

# Warning: enabling this may bypass the setting of 'PasswordAuthentication'

#PAMAuthenticationViaKbdInt no



#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

#PrintMotd yes

#PrintLastLog yes

#KeepAlive yes

#UseLogin no

#UsePrivilegeSeparation yes

#PermitUserEnvironment no

#Compression yes



#MaxStartups 10

# no default banner path

#Banner /some/path

VerifyReverseMapping yes



# override default of no subsystems

Subsystem       sftp    /usr/libexec/sftp-server

- My changes from the stock sshd_config are:
1) set "Protocol 2"
2) set "LogLevel DEBUG3"
3) set "PermitRootLogin no"

- ~/.ssh/config:

Code:

# Host *

#   ForwardAgent no

#   ForwardX11 no

#   RhostsAuthentication no

#   RhostsRSAAuthentication no

#   RSAAuthentication yes

RSAAuthentication no

#   PasswordAuthentication yes

#   HostbasedAuthentication no

#   BatchMode no

#   CheckHostIP yes

#   StrictHostKeyChecking ask

#   IdentityFile ~/.ssh/identity

#   IdentityFile ~/.ssh/id_rsa

#   IdentityFile ~/.ssh/id_dsa

#   Port 22

#   Protocol 2,1

Protocol 2

#   Cipher 3des

#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

#   EscapeChar ~



HostKeyAlgorithms ssh-dss

LogLevel DEBUG3

User JDR

- 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:

Code:

May 21 11:13:51 Mutsu xinetd[1001]: START: ssh pid=1156 from=192.168.0.8

May 21 11:13:51 Mutsu sshd[1156]: Connection from 192.168.0.8 port 49310

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

Code:

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug3: check_host_in_hostfile: filename /Users/dgs/.ssh/known_hosts

debug3: key_read: type mismatch

debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts

debug3: check_host_in_hostfile: filename /Users/dgs/.ssh/known_hosts

debug3: key_read: type mismatch

debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts

debug3: check_host_in_hostfile: filename /Users/dgs/.ssh/known_hosts

debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts

debug2: no key of type 0 for host stetner.org

debug3: check_host_in_hostfile: filename /Users/dgs/.ssh/known_hosts2

debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts2

debug3: check_host_in_hostfile: filename /Users/dgs/.ssh/known_hosts

WARNING: RSA key found for host stetner.org

in /Users/dgs/.ssh/known_hosts:24

RSA key fingerprint 8e:a8:ec:f8:1d:8a:20:39:f6:d1:36:70:e1:0f:90:02.

The authenticity of host 'stetner.org (xxx.xxx.xxx.xx)' can't be established,

but keys of different type are already known for this host.

DSA key fingerprint is 75:f6:71:8b:bd:f0:c4:a5:97:e7:db:b1:f4:e1:bb:2d.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'xxxxxxx.org,xxx.xxx.xxx.xx' (DSA) to the list of known hosts.

debug2: bits set: 1580/3191

debug1: ssh_dss_verify: signature correct

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!

Code:

XXXX% ssh -vvv root@linux

OpenSSH_3.6.1p1+CAN-2003-0693, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

debug1: Reading configuration data /etc/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug2: ssh_connect: needpriv 0

debug1: Connecting to linux [192.168.1.130] port 22.

debug1: Connection established.

debug1: identity file /Users/XXXX/.ssh/identity type -1

debug1: identity file /Users/XXXX/.ssh/id_rsa type -1

debug1: identity file /Users/XXXX/.ssh/id_dsa type -1

debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2

debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.6.1p1+CAN-2003-0693

debug3: Trying to reverse map address 192.168.1.130.

debug1: Miscellaneous failure

No credentials cache found



debug1: Miscellaneous failure

No credentials cache found



debug1: SSH2_MSG_KEXINIT sent

Connection closed by 192.168.1.130

debug1: Calling cleanup 0x1c440(0x0)

[g4:~/.ssh] XXXX% ssh -vvv root@192.168.1.130

OpenSSH_3.6.1p1+CAN-2003-0693, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

debug1: Reading configuration data /etc/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug2: ssh_connect: needpriv 0

debug1: Connecting to 192.168.1.130 [192.168.1.130] port 22.

debug1: Connection established.

debug1: identity file /Users/XXXX/.ssh/identity type -1

debug1: identity file /Users/XXXX/.ssh/id_rsa type -1

debug1: identity file /Users/XXXX/.ssh/id_dsa type -1

debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2

debug1: match: OpenSSH_3.7.1p2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.6.1p1+CAN-2003-0693

debug3: Trying to reverse map address 192.168.1.130.

debug1: Miscellaneous failure

No credentials cache found



debug1: Miscellaneous failure

No credentials cache found



debug1: SSH2_MSG_KEXINIT sent

Connection closed by 192.168.1.130

debug1: Calling cleanup 0x1c440(0x0)

Quote:

Originally Posted by bluehz

Code:

...

debug1: SSH2_MSG_KEXINIT sent

Connection closed by 192.168.1.130

debug1: Calling cleanup 0x1c440(0x0)

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.

Quote:

Originally Posted by stetner

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.

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?

Code:

debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2

Maybe it is an incompatibility between versions...

From bluehz

Code:

...

debug1: SSH2_MSG_KEXINIT sent

Connection closed by 192.168.1.130

debug1: Calling cleanup 0x1c440(0x0)

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')

Quote:

Step 7: Set up privilege separation: A new security feature in response to OpenSSH challenge-response buffer overflow vulnerabilities is privilege separation. Previously any corruption in the sshd could lead to an immediate remote root compromise if it happened before authentication, and to local root compromise if it happend after authentication. Privilege Separation makes such compromise very difficult if not impossible. To set up sshd to use privilege separation execute the following commands: (source:README.privsep file)

# mkdir /var/empty
# chown root:sys /var/empty
# chmod 755 /var/empty
# groupadd sshd
# useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd

/var/empty should not contain any files.

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!