SSH can't connect

[Sergio Crespo]

Hi

I have openssh A.03.91.009 working in 11.23 HPUX, and I'm having problems connecting trought ssh to some of the machines. The strange part is that I can connect to some of them I've configure, but others not, and all of the HP-UX have exactly the same ssh configuration.

Syslog msg after a ssh -v -v -v hostname:
Disconnecting: bind: Permission denied

It accepts the RSA key before.

The Output of my sshd_config
Port 22
Protocol 1,2
ListenAddress 0.0.0.0
PermitRootLogin no
RSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11UseLocalhost no
TCPKeepAlive yes
UseDNS no
# HostKey for protocol version 1
HostKey /opt/ssh/etc/ssh_host_key
# HostKeys for protocol version 2
HostKey /opt/ssh/etc/ssh_host_rsa_key
HostKey /opt/ssh/etc/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11DisplayOffset 10
#PrintMotd yes
#PrintLastLog yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

Any clues on this one?

[Denver Osborn]

could you post the output of "ssh -vvv" from the failed session? It might help troubleshoot...

[Sergio Crespo]

Hi... Thankx for the Reply... here it goes...

ssh -vvv

xxx@connector(~/.ssh)$ ssh -vvv thor
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc]
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to thor [192.168.1.56] port 22.
debug1: Connection established.
debug1: identity file /home/src/.ssh/identity type 0
debug1: identity file /home/xxx/.ssh/id_rsa type -1
debug1: identity file /home/xxx/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9
debug1: match: OpenSSH_3.9 pat OpenSSH*
debug1: Local version string SSH-1.5-OpenSSH_3.5p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug3: check_host_in_hostfile: filename /home/xxx/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'thor' is known and matches the RSA1 host key.
debug1: Found key in /home/src/.ssh/known_hosts:1
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Trying RSA authentication via agent with 'xxxx.x.xxxx@xxxxx.pt'
debug1: Received RSA challenge from server.
debug1: Sending response to RSA challenge.
debug1: Remote: RSA authentication accepted.
debug1: RSA authentication accepted by server.
debug1: Requesting pty.
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
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 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 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: 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 0
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: fd 3 setting TCP_NODELAY
debug1: Requesting authentication agent forwarding.
Received disconnect from 192.168.1.56: bind: Permission denied
debug1: Calling cleanup 0x36e1c(0x0)

[Denver Osborn · Accepted solution]

ok, so it lets you in but drops the connection after it tries "authentication agent forwarding" w/ ssh-agent

Are all of the failing clients running the same rev (OpenSSH_3.5p1) as the working clients? Could be a problem with older ssh-agent on clients -vs- a newer ssh on working clients. Maybe you can pick apart those diffs since nothing stands out re: the sshd_config on the server side.

If we think it might have something to do w/ ssh-agent "authentication agent forwarding"... try using the "-a" option from one of the problem clients. The "-a" disables authentication agent forwarding. If you still get "disconnect" then we're not looking at the right thing.

Have you also checked the syslog.log for any hints?

Hope this helps,
-denver