+- Linux Lite Forums (https://www.linuxliteos.com/forums)
+-- Forum: Hardware - Support (https://www.linuxliteos.com/forums/forumdisplay.php?fid=6)
+--- Forum: Network (https://www.linuxliteos.com/forums/forumdisplay.php?fid=24)
+--- Thread: scp fails between two Lite4.2 workstations (/showthread.php?tid=5852)
Pages:
1
2
scp fails between two Lite4.2 workstations - openmind - 12-11-2018
Just installed Lite4.2 on two workstations connected by the same IP subnet. After installing ssh, applying all updates and selecting 'Allow" in the firewall, ssh login connections succeed normally. When attempting to copy files between workstations using scp (the same host workstations with the same IP addresses as the successful ssh login) I obtain the following (actual username and IP address modified for security reasons):
scp -pr Documents/Projects 123.123.123.123
ocumentsusername@123.123.123.123's password:
Welcome to Linux Lite 4.2 username
shell returned 1
The usernames are the same on both workstations. The intent is to copy everything in sub-directory "Projects" on the sending host to the Documents directory on the receiving host. Invoking the above with level 2 debugging yields:
scp -prvv Documents/Projects 123.123.123.123
ocumentsExecuting: program /usr/bin/ssh host 123.123.123.123, user (unspecified), command scp -v -r -p -t DocumentsOpenSSH_7.6p1 Ubuntu-4ubuntu0.1, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "123.123.123.123" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 123.123.123.123 [123.123.123.123] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/username/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/username/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/username/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/username/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/username/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/username/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/username/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/username/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.1
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 123.123.123.123:22 as 'username'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:SPr7Roun6wlBLEpbczpdb3WbTreFRJ5FihYaswvSYpg
debug1: Host '123.123.123.123' is known and matches the ECDSA host key.
debug1: Found key in /home/username/.ssh/known_hosts:6
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /home/username/.ssh/id_rsa ((nil))
debug2: key: /home/username/.ssh/id_dsa ((nil))
debug2: key: /home/username/.ssh/id_ecdsa ((nil))
debug2: key: /home/username/.ssh/id_ed25519 ((nil))
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/username/.ssh/id_rsa
debug1: Trying private key: /home/username/.ssh/id_dsa
debug1: Trying private key: /home/username/.ssh/id_ecdsa
debug1: Trying private key: /home/username/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
username@123.123.123.123's password:
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to 123.123.123.123 ([123.123.123.123]:22).
debug2: fd 4 setting O_NONBLOCK
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: scp -v -r -p -t Documents
debug2: channel 0: request exec confirm 1
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
Welcome to Linux Lite 4.2 username
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: write failed
debug2: channel 0: close_write
debug2: channel 0: send eow
debug2: channel 0: output open -> closed
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
debug2: channel 0: rcvd 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
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 1940, received 2408 bytes, in 0.6 seconds
Bytes per second: sent 3040.6, received 3774.1
debug1: Exit status -1
shell returned 1
The authentication succeeds but there is apparently a "read<=0 rfd 4 len 0" that fails resulting in the death of the 'scp' session. Scp used to work in earlier Lite releases but fails in Lite4.2. Any suggestions on a work around? (The Lite4.2 scp client works with older versions of every other ssh server I've tried.) Has the Lite4.2 ssh server been built incorrectly?
Sorry, just tried 'sftp' between the same two workstations and that produces
ftp 123.123.123.123username@123.123.123.123's password: Received message too long 1466264675shell returned 255
So the Lite4.2 ssh server breaks all file transfer methods in ssh.
Re: scp fails between two Lite4.2 workstations - trinidad - 12-11-2018
1) Hard to tell from your post because you obfuscate them, and you probably are not trying to do this, but two computers on the same subnet can't have the same numerical address.
2) You may have to pass the -t option twice with SCP depending on what you are trying to do.
https://stackoverflow.com/questions/24795377/running-a-remote-command-through-ssh-but-in-the-background
https://unix.stackexchange.com/questions/278284/why-does-scp-fail-when-requesttty-force-option-is-enabled
3) Binary and TTY code are not the same.
4) What's the point of a Desktop OS on a server if you're not going to use the desktop GUI?
5) I use SFTP and SSH all the time with no problems on Linux Lite, Debian 9, and Windows 10 machines. It's definitely not broken.
TC
Re: scp fails between two Lite4.2 workstations - openmind - 12-11-2018
Reply to comments to date:1) of course not. Only the output and debug data of the sending host is shown and only the target host IP appears in that output. As indicated, IP addresses have been obscured for security reasons.
2) The '-t' option doesn't appear in the scp man page and was not supplied on the command lines shown. The use of '-t' is entirely internal to the scp file transfer protocol.
3) Again, the exact same send command works fine on other ssh server installations and used to work on earlier Lite releases. Everything shown in the debug log is reflective of the internal scp protocol and not intended or implied by my command ('scp -prvv SourceDir hostip:destdir' [the 'p' option preserves file dates and modes, the 'r' option indicates recursive copy of everything in the source directory including any sub-directory structure, the double 'v' is level 2 debug used only because it isn't working]). This is a very powerful tool I would like to continue to use but now it's broke.
4) Both workstations are laptops and the ssh protocols are being used to transfer files between them. Very common practice that I use all the time. That is why I discovered it was broken in this latest Lite release.
5) I do too as I said. Apparently only the Linux Lite4.2 ssh package is broken for both scp and sftp to the Lite4.2 ssh server. The ssh server side (sshd) is not included in the Lite4.2 install ISO. It had to be installed manually using the Synaptic Package Manager as indicated at the beginning of the post (the SPM automatically takes care of all necessary dependencies). After that, the Lite4 firewall had to be configured to allow incoming connections. The Lite4.2 server (sshd) works for ssh logins but not either scp or sftp. If it's not broken then why doesn't it work? As I said, it used to work fine and I depend on it to keep a number of workstations current.
Re: scp fails between two Lite4.2 workstations - trinidad - 12-12-2018
Stepping completely over the rabbit hole of opinion here: Linux Lite and its UI is designed for new Linux users coming from Windows. Login to a secure shell first (TTY of the host). Run the SCP command from there remembering you are then on the host not the client and using plain Unix spacing and file paths (syntax). This should eliminate the long message error. Should work fine. Otherwise run SFTP from Thunar SFTP://192.xx.xx.xx or 10.xx.xx.xx as the case me be. The SSH server and the SSH client in Linux Lite are integrated for desktop GUI usage, assuming that more seasoned Linux users don't need instructions. Depending on the shell the Unix CLI syntax of SSH can vary in minor ways from distro to distro and file manager to file manager. Also when backgrounding (not headless) you can end up short a TTY depending how the server is configured. If your problems continue (though they should not) you can remove the welcome message and link from the host side prompt and then CLI from the client side.
TC
Re: scp fails between two Lite4.2 workstations - Valtam - 12-12-2018
Trindad is right, Linux Lite is a gateway operating system, it's there for people to try their first Linux, then move onto other distros. If some of the more technically advanced features of LL don't function the way people expect, I'm not particularly bothered. Having said that there are some good, technical minds here.
Sent from my Mobile phone using Tapatalk
Re: scp fails between two Lite4.2 workstations - openmind - 12-12-2018
Thank you Jerry and Trindad for your suggestions and comments on the scp/sftp session failures now occurring in Linux Lite4.2. I understand that Linux Lite has specific goals with a specific target audience as most published projects do. Targeting Windows users transitioning to Linux on the desktop is a worthy goal which I heartily support (one of the workstations referred to in this post used to be a Windows 7 laptop). It would therefore seem important to us both that capabilities available in Linux Lite work properly without a lot of trouble. Transitioning Windows users, unfamiliar with the internals and configuration of the environment they are attempting to use, would become understandably discouraged with Linux on the desktop if capabilities they need to use (e.g., transferring files between their Windows and Linux systems) do not work as they are supposed to. A Windows user encountering such difficulties would be likely abandon their Linux transition plan.
My efforts so far to resolve this problem have resulted in the discovery that the Lite4.2 'sshd' is configured to authenticate and configure sessions with PAM (/etc/ssh/sshd_config: 'UsePAM yes') and that PAM is configured to post a dynamic motd (/run/motd.dynamic) in two places '/etc/pam.d/login' and '/etc/pam.d/sshd'. Commenting out the configuration line /etc/pam.d/sshd: 'session optional pam_motd.so motd=/run/motd.dynamic' does remove the extensive "blather" from the dynamic motd in 'ssh' logins but so far 'sftp' sessions still fail with "Received message too long 1466264675" and 'scp -p sourcefile localhost:/tmp' attempts still also fail after successful authentication. I'm still not sure what received message is still too long but will continue to work on a resolution and let you know what happens.
Re: scp fails between two Lite4.2 workstations - Valtam - 12-13-2018
Ask you average Joe or grandma on the street about configuring sessions with PAM and your most likely to get this kind of look...
![[Image: giphy.gif]](https://media.giphy.com/media/lT4sgCJwC7B4c/giphy.gif)
That's our target audience, not those that are technically proficient.
Re: scp fails between two Lite4.2 workstations - trinidad - 12-13-2018
It's a desktop OS. New users coming from Windows expect to use a GUI file manager for SFTP and/or Samba. They also expect to work with their files on the desktop in the same fashion. NOTHING is broken in Linux Lite SSH server and client, and missing capabilities that require configuration are up to the seasoned Linux user to do whatever they want with. If SFTP is not working for you now from Thunar it's certainly pebcak. Criticizing an OS by insisting something is broken that is not broken, while attempting to do something that the OS is not designed for is tantamount to criticizing a screwdriver for not being a wrench. Several other users here, including me could probably help you get SCP configured, though I am at a loss as to why given your curious setup in which I can see no particular productivity advantages, but I find myself disinclined to do so at this point given your insistence of "broken" regarding Linux Lite.
http://manpages.ubuntu.com/manpages/bionic/man1/scp.1.html
TC
Re: scp fails between two Lite4.2 workstations - openmind - 12-13-2018
Thanks, Jerry, for emphasizing my point. That is exactly why capabilities of an OS need to be verified to work before going out of beta. Trindad, that is exactly how I'm using it on two laptops. It is common practice to copy files between workstations used as desktop systems but in Lite4.2 it doesn't work anymore. Eliminating all PAM banners doesn't help get either sftp or scp to work as they used to and as the documentation describes. I'll use another distro that isn't broken. There are plenty to choose from.
Re: scp fails between two Lite4.2 workstations - Valtam - 12-13-2018
OMG [member=5916]trinidad[/member] our OS is broken, better pull it from all the mirrors asap.