scp not working while ssh works

bakunin · May 11, 2010, 8:37am

I try to transfer a file from a Linux host to an AIX-host via scp, which fails. Logging into the AIX-system from the same Linux-system via ssh works well and i am a bit at a loss where to look.

The original setup was with a user account provided via LDAP, but because of the error message (see transcript below, "unknown user" near the end) i created a local user, which didn't change anything, though. In the following "172.20.9.101" is the address of the AIX-system (there is no DNS).

[bakunin@linux-system ~]$ scp -v config.tar bakunin@172.20.9.101:~/config.tar
Executing: program /usr/bin/ssh host 172.20.9.101, user bakunin, command scp -v -t ~/config.tar
OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 172.20.9.101 [172.20.9.101] port 22.
debug1: Connection established.
debug1: identity file /home/bakunin/.ssh/identity type -1
debug1: identity file /home/bakunin/.ssh/id_rsa type 1
debug1: identity file /home/bakunin/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
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(1024<1024<8192) 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 '172.20.9.101' is known and matches the RSA host key.
debug1: Found key in /home/bakunin/.ssh/known_hosts:20
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: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/bakunin/.ssh/identity
debug1: Offering public key: /home/bakunin/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = C
debug1: Sending command: scp -v -t ~/config.tar
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
unknown user 207
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 2256, received 2328 bytes, in 0.0 seconds
Bytes per second: sent 83580.5, received 86247.9
debug1: Exit status 255
lost connection

Further information about the systems (please ask if you need additional info):

AIX-Version: 6.1-ML4

bakunin@aix $lslpp -l | grep -i ss[hl]
  gsksa.rte                 7.0.4.11  COMMITTED  AIX Certificate and SSL Base
  gskta.rte                 7.0.4.11  COMMITTED  AIX Certificate and SSL Base
  openssh.base.client     5.2.0.5300  COMMITTED  Open Secure Shell Commands
  openssh.base.server     5.2.0.5300  COMMITTED  Open Secure Shell Server
  openssh.license         5.2.0.5300  COMMITTED  Open Secure Shell License
  openssh.man.en_US       5.2.0.5300  COMMITTED  Open Secure Shell
  openssh.msg.EN_US       5.2.0.5300  COMMITTED  Open Secure Shell Messages -
  openssh.msg.en_US       5.2.0.5300  COMMITTED  Open Secure Shell Messages -
  openssl.base            0.9.8.1102  COMMITTED  Open Secure Socket Layer
  openssl.license         0.9.8.1102  COMMITTED  Open Secure Socket License
  openssl.man.en_US       0.9.8.1102  COMMITTED  Open Secure Socket Layer
  openssh.base.client     5.2.0.5300  COMMITTED  Open Secure Shell Commands
  openssh.base.server     5.2.0.5300  COMMITTED  Open Secure Shell Server
  openssl.base            0.9.8.1102  COMMITTED  Open Secure Socket Layer

Linux-System:

[bakunin@linux]$ uname -a
Linux linux 2.6.27.25-78.2.56.fc9.i686 #1 SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686 i386 GNU/Linux
[bakunin@linux]$ cat /etc/redhat-release 
Fedora release 9 (Sulphur)

Thanks for your help.

bakunin

pludi · May 11, 2010, 8:44am

On the AIX side, is there anything in the sshd_config about chroot-ing the users if they use sftp or scp?

fpmurphy · May 11, 2010, 9:30am

I have found that scp sometimes fails if you have any shell initialization in your .profile, etc. which produces output for non-interactive sessions. If "ssh AIXHOST /bin/true" produces any output, then try modifying your shell initialization.

bakunin · May 11, 2010, 11:16am

no, there isn't. Here is the complete config (comments stripped):

Protocol 2
SyslogFacility AUTH
LogLevel INFO
PermitRootLogin no
PermitEmptyPasswords no
UsePAM yes
AllowTcpForwarding yes
X11Forwarding yes
PrintMotd yes
UseDNS no
Subsystem       sftp    /usr/sbin/sftp-server

I have tried it and it produced nothing.

In the meanwhile i have found out a bit more, alas nothing of any remedial value:

I tried to create another user completely unknown to LDAP to make certain the authentication between LDAP and system don't get confused: no change of the symptoms described above.

I tried to initiate the scp from the other direction and learned that there is a firewall between these two hosts, which seemingly forbids scp-communication in the other direction. There is simply no response at all when trying like this, not even an error message. The command will just time out eventually:

bakunin@aix $ scp bakunin@linux:~/file .

We tried to scp from a third system (also AIX, but IMHO this makes any difference) with a different user-ID, which works. It is at least established therefore, that the scp-system on the AIX-host in question is not broken in itself.

bakunin

ross.mather · May 13, 2010, 2:19am

as soons as there is a firewall in the loop then the finger pints often at that. Try getting a Network Tech to look at the firewall when you try to establish the connection.

Causes I've seen with firewalls include:

File size limits on a copy.
The routing causes the Firewall to only see part of the TCP/IP traffic (LPAR with multiple interfaces)
Firewall blocks protocol.

Best debugging is as you've done, copy between two servers on the local subnet (or even via 127.0.0.1 loopback address) and likewise on the source system.

After that call the Network Tech o check the firewall.