|
scp problem after a debian upgrade (squeeze)
I used for a long time a little script to backup my firewall (not linux) configuration files using public key via scp command.
After a distribution upgrade of the client (from debian stable lenny to squeeze) the script stopped to run with a "501-Permission Denied" message. I have done some investingation and it seems that all keys are properly installed... Somewhere, I read that could be some problems whith version >5.2 of openssh client and in effect I upgraded openssh from 5.1p1-5 to 5.5p1-6 I have not a great knowledge about openssh.... Please, any support? Below the output of the scp -v command. Thank you a lot. ---------------------------- debian-stable:~# scp -v root@10.150.1.10:file_test /tmp/test.out Executing: program /usr/bin/ssh host 10.150.1.10, user root, command scp -v -f -- file_test OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 10.150.1.10 [10.150.1.10] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version -EnS7 debug1: no match: -EnS7 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr 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 '10.150.1.10' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:8 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server 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: Offering public key: /root/.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: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug1: Sending command: scp -v -f -- file_test debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 Sink: 501-Permission Denied 501-Permission Denied debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 2408, received 2088 bytes, in 0.0 seconds Bytes per second: sent 863694.8, received 748918.1 debug1: Exit status 0 debian-stable:~# |
Hi!
I've found that in the url http://www.gossamer-threads.com/list...sh/users/37790 there are some tips on how to get more debugging info on your problem. Could you paste here the output from the master's syslog and running sshd with the -ddd option? Also, I saw mentioned in another url that the problem may be in the openssh 5.2 _client_. Perhaps you could try the scp using an older openssh client so that we can rule out a problem with the sshd? HTH, Renato. |
Quote:
I tried to downgrade (inside the stable distribution) the openssh-client to the previous revision (5.1p1): nothing changed (maybe some unchanged configuration settings or/and common library?) Significative, I think, is that if I use the "ssh root@10.150.1.10" I can connect to the device as espected. This should demostrate that the key pairs setting are correct.... It seems that is only the "scp" command used normally to transfer the firewall configuration file has the problem. Below the output of the SCP with the "-vvv" command. I tried also to play with some the ssh_config file settings: no luck. The remote device is a proprietary firewall so I don't know how to activate the equivalent sshd debugger. I can't understand what is happening. I'm very frustrated. Thank you a lot for your support... ___________________ debian-stable:~# scp -vvv root@10.150.1.10:sys_config /tmp/test.out Executing: program /usr/bin/ssh host 10.150.1.10, user root, command scp -v -f -- sys_config OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 10.150.1.10 [10.150.1.10] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug3: Not a RSA1 key file /root/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /root/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version -EnS7 debug1: no match: -EnS7 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v00@openssh.com,ssh-dss...00@openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 147/256 debug2: bits set: 489/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: host 10.150.1.10 filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: host 10.150.1.10 filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 8 debug1: Host '10.150.1.10' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:8 debug2: bits set: 524/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/id_rsa (0xa93bd629) debug2: key: /root/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /root/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 277 debug2: input_userauth_pk_ok: fp 81:4d:8a:e1:dd:4c:81:e2:0e:a1:1f:77:ac:e1:27:81 debug3: sign_and_send_pubkey debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). debug2: fd 4 setting O_NONBLOCK debug2: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug1: Sending environment. debug3: Ignored env TERM debug3: Ignored env SHELL debug3: Ignored env USER debug3: Ignored env LS_COLORS debug3: Ignored env SUDO_USER debug3: Ignored env SUDO_UID debug3: Ignored env TMOUT debug3: Ignored env USERNAME debug3: Ignored env PATH debug3: Ignored env MAIL debug3: Ignored env _ debug3: Ignored env PWD debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env HOME debug3: Ignored env SUDO_COMMAND debug3: Ignored env SHLVL debug3: Ignored env LOGNAME debug3: Ignored env SUDO_GID debug1: Sending command: scp -v -f -- sys_config debug2: channel 0: request exec confirm 1 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 Sink: 501-Permission Denied 501-Permission Denied debug2: channel 0: read<=0 rfd 4 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) debug3: channel 0: close_fds r -1 w -1 e 6 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 2408, received 2088 bytes, in 0.0 seconds Bytes per second: sent 727246.8, received 630602.7 debug1: Exit status 0 debian-stable:~# |
I have found a page that tries to understand scp. Maybe not for the faint of heart: http://blogs.sun.com/janp/entry/how_...protocol_works
In this page, it is written that the scp operates by using ssh in "source" mode on the source of the file, and in "sink" mode on the destination. If I am interpreting your output right, it would seem that scp complains that it cannot write to /tmp/test.out, but root should definitely have the rights to write there. As a wild guess, I thought that maybe you already had the /tmp/test.out file, and that it had its write permission bit off, and that scp was respecting that and preventing you from writing over the file. I have tested this scenario and I can reproduce your problem, but with a slight different error message (my ouput does not have a "Sink: 501-Permission Denied" line). Can you confirm that this isn't (or is) the problem? (If you need, do not hesitate to ask for step-by-step instructions). HTH, Renato. |
Quote:
Furthermore, I'm using /tmp directory only for testing purposes. The real script (untouched) was working for a long time, writing in other directory... --- I was just reading/testing another possible idea that I found on http://www.openssh.com/faq.html#2.9 Seems my case... I checked my users profiles for possible problems but, again no way to run the scp program.... I'll try to understand better your very interesting documentation. |
I thought that perhaps the problem is with scp and not with ssh. So you could use rsync instead of scp. Google'ing for this I found the below page, which shows the command to use a hostkey ssh tunnel to rsync over. I guess you already have your hostkey properly set, so you could simply test the rsync command with the -e switch.
http://www.1stbyte.com/2006/10/25/re...-no-passwords/ |
Quote:
debian-stable:~# scp root@10.150.1.10:sys_config /tmp/test.out 501-Permission Denied debian-stable:~# debian-stable:~# rsync -ave ssh root@10.150.1.10:sys_config /tmp/test.out protocol version mismatch -- is your shell clean? (see the rsync man page for an explanation) rsync error: protocol incompatibility (code 2) at compat.c(173) [Receiver=3.0.7] debian-stable:~# Reading this article (http://www.linuxquestions.org/questi...bility-345101/) I have done another test (similar what I found in the previous openssh documentation) debian-stable:~# ssh root@10.150.1.10 echo 2>/dev/null FIREWALL # Unknown action 0 FIREWALL # debian-stable:~# Where the "echo" command is not recognized as internal firewall command (Unknown action 0).... Last week I was searching for a problem inside linux client bashrc/profile inizialization shell, but now I'm really thinking that the problem could be in the in the Firewall prompt "FIREWALL #", that is confusing the scp/rsync commands... Assuming that this is the real problem, in this moment I don't know what I can do and, especially, why in the past (before the upgrade) there was no problems (the firewall is untouched) ..... |
These days I tried to figure out alternate ways for you to copy your file automatically.
Is it possible to go the other way around? Like "ssh root@10.150.1.10 'scp /root/sys_config otherMachineIp:path'"? (This would involve setting a hostkey from the firewall to your other machine, which is less secure than what you are doing. Another, very "labor-intensive" solution would be to have your script pop-up a virtual machine running a version of the OS and openssh that you know work, and making the copy there, make a local copy from VM to host, and then closing the VM. Both solutions are really ugly, but if they get the job done... About the test you made "ssh root@10.150.1.10 echo 2>/dev/null", there is usually a problem when a sshd host has a "banner", that it prints when someone logs in. You can simply check if your host is doing this by logging in. To suppress the banner you'd change the /etc/ssh/sshd_config file on linuxes, but you may have to do something else since you have a proprietary firewall machine. I've never heard of a prompt string being troublesome on ssh, but you could try setting it to an empty string on the host. |
Quote:
In truth, I have some problems to do what you have proposed. Is not about the "labor-intensive" reason, but because the device involved inside my environment have some security policy restriction that bind much my freedom of action. I'm also looking for an'alternative proprietary command, but all command that I analyzed until now (like "show config" redirected into a file), don't do exactly a backup or have some restrictions/problems. The "scp" metod was a certified metod from the vendor to do this type of automatic backups, but now I cannot use :(( |
I have noticed something in the output:
Quote:
So please post the output from the below command (or an equivalent one): # LANG="" scp -vvv root@10.150.1.10:file_test /tmp/test.out |
Quote:
I'm sorry, but in this moment I have only one little problem to do the new test: I'm away from home for a week.... Surely I not fail to verify the command that you're suggesting as soon as I return! I'll let you know asap! Thanks again, Renato. |
I'm back (sorry...)
I have just done the suggest test (# LANG="" scp -vvv root@10.150.1.10:sys_config /tmp/test.out), and this is the output: debian-stable:~# LANG="" scp -vvv root@10.150.1.10:sys_config /tmp/test.out Executing: program /usr/bin/ssh host 10.150.1.10, user root, command scp -v -f -- sys_config OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 10.150.1.10 [10.150.1.10] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug3: Not a RSA1 key file /root/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /root/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version -EnS7 debug1: no match: -EnS7 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman- group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v00@openssh.com,ssh-dss...00@openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish- cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish- cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac- sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac- sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael- cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael- cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 130/256 debug2: bits set: 478/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: host 10.150.1.10 filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: host 10.150.1.10 filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 8 debug1: Host '10.150.1.10' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:8 debug2: bits set: 505/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/id_rsa (0xa93bd629) debug2: key: /root/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /root/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 277 debug2: input_userauth_pk_ok: fp 81:4d:8a:e1:dd:4c:81:e2:0e:a1:1f:77:ac:e1:27:81 debug3: sign_and_send_pubkey debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). debug2: fd 4 setting O_NONBLOCK debug2: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug1: Sending environment. debug1: Sending env LANG = debug2: channel 0: request env confirm 0 debug3: Ignored env SHELL debug3: Ignored env TERM debug3: Ignored env OLDPWD debug3: Ignored env USER debug3: Ignored env SUDO_USER debug3: Ignored env SUDO_UID debug3: Ignored env TMOUT debug3: Ignored env USERNAME debug3: Ignored env MAIL debug3: Ignored env PATH debug3: Ignored env PWD debug3: Ignored env SHLVL debug3: Ignored env SUDO_COMMAND debug3: Ignored env HOME debug3: Ignored env LOGNAME debug3: Ignored env SUDO_GID debug3: Ignored env _ debug1: Sending command: scp -v -f -- sys_config debug2: channel 0: request exec confirm 1 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 Sink: 501-Permission Denied 501-Permission Denied root@debian-stable:~# debug2: channel 0: read<=0 rfd 4 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) debug3: channel 0: close_fds r -1 w -1 e 6 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 2408, received 2088 bytes, in 0.0 seconds Bytes per second: sent 381195.2, received 330538.0 debug1: Exit status 0 |
One thing you have not documented here (but maybe you've tried): copying _another_ file with the -vvv option, please do this, specially if you find a file that you do can copy, publish the output so we can compare it with the non-working one.
|
Quote:
And, unfortunately, I have not an old command verbose output to compare. Previously I had no reason to have one: it was working well. And even in the laboratory that I done before the upgrade, with similar devices (but sadly, for tecnical problems, not identical) I did not notice problems: I didn't not suspect this type of anomaly, which seems specific of this two devices involved. Strange for me, is that when I rollback to a previous (working) openssh version, however, no longer worked: perhaps the anomaly is in some library, that I have not yet identified. As I said, unfortunately, in my environment, I have many restrictions and is not so obvious to do a complete version rollback or some particular tests.... I have not other words.... Again, Thank you a lot for your support. |
| All times are GMT -5. The time now is 12:31 PM. |