ssh issues with sftp and qvt/net

[Gary Norton]

Hello everyone,

I recently installed secure shell (latest version) on an hp-up 11i version1 server. I'm trying to make an sftp connection to a secure ftp server and i get the following:

server:/# sftp -v username@ftp.somehost.com
Connecting to ftp.somehost.com...
OpenSSH_3.8, OpenSSL 0.9.7d 17 Mar 2004
HP-UX_Secure_Shell-A.03.81.002, HP_UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to ftp.somehost.com[XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version 1.29 sshlib: MOVEit DMZ SSH 3.0.5.0
debug1: no match: 1.29 sshlib: MOVEit DMZ SSH 3.0.5.0
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'ftp.somehost.com' is known and matches the DSA host key.
debug1: Found key in /.ssh/known_hosts:2
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/id_rsa
debug1: Trying private key: /.ssh/id_dsa
debug1: Next authentication method: password
username@ftp.somehost.com's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
username@ftp.somehost.com's password:
Permission denied, please try again.

And so on...

The username and password are valid, i'm sure of it.

And here's a bonus questions for all you guru's out there!

I'm trying to get a QVT/Net terminal using ssh2 to connect to my hp server running ssh. I end up connecting but getting a blank screen...the terminal says its connected, but nothing appears on screen. Strange...

Thanks to all of you that read the whole post ;)

[Hazem Mahmoud_3]

Gary,
I ran sftp in verbose mode on my system and here is my output. It looks like the main difference has to do with the "Authentications that can continue" line. Compare the version you're running with the version I have and see maybe that you are running an older version:

# sftp -v root@
Connecting to ...
OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2
debug1:


debug1: Mechanism encoded as ==
debug1:


debug1: Mechanism encoded as ==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interact
ive
debug1: Next authentication method: external-keyx
debug1: Authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interact
ive
debug1: Next authentication method: gssapi
debug1:


debug1:


debug1:


debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/id_rsa
debug1: Trying private key: /.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interact
ive
debug1: Next authentication method: password
root@'s password:
debug1: Authentication succeeded (password).
debug1: fd 5 setting O_NONBLOCK
debug1: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending subsystem: sftp
debug1: channel 0: request subsystem
debug1: channel 0: open confirm rwindow 0 rmax 32768
sftp>

[Steven E. Protter]

Seems that there might be a problem with the terminal. Perhaps the TERM variable is wrong and although you type the password correct its not being transmitted properly.

When a user becomes locked on one of my HP-9000 servers thats how it acts. Bad authentication attempts. Turns out in the case of my lab machine at home, someone was trying every night to log on as root.

A look at /var/adm/syslog/syslog.log is called for on the target machine. You may need to look back a bit.

SEP

[Nicolas_17]

Hazem,

I can't seem to get as many "authentication that can continue" options no matter how I play with the ssh_config. Can you post a copy of your ssh_config so that I can compare it with mine?

Thanks.

Steven,

Here is the the line in the syslog pertaining to the terminal problem:

Sep 22 16:58:05 server sshd[2096]: Accepted publickey for user from port 2312 ssh2

So I'm logging on...now you were saying something about the term variable. Thing is, it hasn't changed and I'm able to use telnet (instead of ssh2) with the same terminal program to the same server! and putty work fine by the way...it's just that I have a bunch of users on QVT/Net.

Thanks.

[Hazem Mahmoud_3]

Here it is:

# more ssh_config
# $OpenBSD$

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for various options

# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsAuthentication no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# 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
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~
#

[Michael Selvesteen_2]

Some possible reasons :

1.It seems the problem is on server side.It may due to some compatiblity problems on password handling between HP secure Shell server and MOVEit DMZ SSH.

2.You may try setting up the public key authentication.

3.Make sure your remote server supports password authentication.

Try

www.snailbook.com/faq/general-debugging.auto.html

for debugging.

All the best

[Steven E. Protter]

Public key accepted and still being prompted for a login!

Check the permissions on the $HOME/.ssh directory and all files within on the target server.

Consdier generating and distributing new public keys.

I've had this exact issue and tracked it down to bad permissions. In this case the user decided to change them. lol.

SEP

[Nicolas_17]

Hazem,

Thank you for the ssh_config. Apparently, you only have "protocol 2" uncommented. Therefore i'm assuming you have some other config settings elsewhere. Do you?

Micheal,

Thanks for the link, i'll take a look at it. About setting a public key, i can't work that out alone, since the remote server is actually at another company. I've sent the techs over there an email with the problem details so i'm waiting on their reply. You guys are much quicker!

Steven,

I tried changed the permisions on the source server with the following:
$ chmod go-w $HOME $HOME/.ssh
$ chmod 600 $HOME/.ssh/authorized_keys
but i can't change them on the target server for the reason mentionned above in reply to Michael's suggestion.

Thanks to all of you, i'll keep at it!

[Nicolas_17]

Concerning that terminal problem, i get this in the syslog:

Sep 23 13:03:07 server sshd[12577]: error: Could not get shadow information for user

Any idea?

[Michael Selvesteen_2]

Nicolas,

SSH checks for password expiration status of an user before it starts the authentication.

The above error messages shows that, server is employing shadow passwords. Probably the user's password may be expired and SSH is unable to retrive the shadow information of the user.

Make sure that, your user id exists in server with proper password. if it expired try to issue a new password. Then try SSH.

Hope this helps.

[Nicolas_17]

Michael,

you what's strange? there is no shadowing on this server. Just the /etc/passwd. This account i'm using for the testing is actually mine, so i know for sure it's not expired...

I set up a public key and now i'm not getting the shadow error any more. There's just nothing on my terminal screen.

Thanks for the suggestion.