SCP problem - stalled error

General questions
1

Hi,

I use scp command (ssh + rsa key) to copy config.boot to another serwer ( debian distro).

When upgrade vyos to 1.1.1 (helium), scp command stop working. I’ve got messages “stalled”.

Other vyos with difrent version (example 1.0.2) is work ok.

I tried copy another file, change permission to 777. Delete firewall in vyos. Upgrade client in debian.

logs from connection

Executing: program /usr/bin/ssh host 192.168.10.1, user vyos, command scp -v -f /config/config.boot
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.10.1 [192.168.10.1] 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: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze5
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze5 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
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: Server host key: RSA 99:99:99:99 ([i]in this point i've got ok format key[/i]) 
debug1: Host '192.168.10.1' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:373
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
Welcome to VyOS
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.10.1 ([192.168.10.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = pl_PL.UTF-8
debug1: Sending command: scp -v -f /config/config.boot
Sending file modes: C0775 51851 config.boot
Sink: C0775 51851 config.boot
config.boot                                                                                                                                    0%    0     0.0KB/s - stalled -

P.s Debian client connect to vyos via ipsec tunnel -> Debian -> vyos (difrent vyos) -> vyos (Helium with problem)

P.s.2 It’s weird, If try use scp command from antoher serwer in lan where is Debian server, i’ve got this same error. If use scp to difrent serwer in lan where is Vyos Helium is ok. So i think problem located in connection not scp.

My connection looks like:

Lan 192.168.0.50 (debian serwer) -> vyos (192.168.0.1) -> ipsec vti (172.16.0.2) -> vyos (192.168.1.1) -> ipsec vti (172.16.0.10 ) -> vyos Helium (192.168.10.1) (vti 172.16.0.11)
So i connect via two tunnel beforce connect to Helium vyos

[/quote]

2

That looks like an MTU error.

set interfaces vti TXT mtu U32<68-9000>

Try dropping the mtu on the vti tunnels down to 1400.

3

This doesn’t help in your issue, but why not use the built in scheduler?
And scripting methods?

http://vyos.net/wiki/Command_scripting

Here is a script I wrote for a couple of EdgeRouter Lites I have in operation. I use the same script on a couple of VyOS boxes too, but instead of the domain variable, I can actually use the hostname -f command to get the full name

[code]#!/bin/vbash
source /opt/vyatta/etc/functions/script-template

#set variables
domain=‘DOMAINNAME’
routerName=$(hostname).$domain
commandFile=$routerName-$(date +%F)-commands.txt
configFile=$routerName-$(date +%F)-config.boot
tftpServer=‘192.168.254.91’

#output configuration commands to tmp
run show configuration commands > /tmp/$commandFile

#send configuration commands to tftp server
tftp -l /tmp/$commandFile -r $routerName/$commandFile -p $tftpServer

#remove the tmp file
rm /tmp/$commandFile

#enter config mode
configure

#export config.boot to tftp server
save tftp://$tftpServer/$routerName/$configFile

#bye bye
exit
[/code]

The lines used to schedule my task are:

set system task-scheduler task BACKUP executable path /config/scripts/backupconfig.sh set system task-scheduler task BACKUP interval 1d

you can substitute the tftp with scp or ftp

4

I recently added a VyOS device to my rancid install. Rancid is highly recommended for periodically backing up device configs, storing in a revision control system (rcs,svn,git) and send emails with diffs.

I followed this resource for VyOS support:
https://bitbucket.org/aquerubin/rancid-vyatta