scp between two Ubuntu VirtualBox VMs: network and SSH checks

By huanggs

For two Ubuntu VirtualBox virtual machines, scp works only if the client can reach the server VM’s SSH service and authenticate as a real user. The example address and username in commands below are teaching placeholders. Replace them with the server VM’s actual IP address and account name.

1. Put both VMs on a reachable VirtualBox network

Both VMs must be attached to a VirtualBox mode that allows VM-to-VM traffic. The VirtualBox networking manual describes internal networking and host-only networking as separate virtual network types. Either can work in a lab if both VMs use the same named network and have valid IP addresses on the same subnet.

Do not assume that “Internal Network” automatically gives addresses. A pure internal network has no DHCP server unless you configure one or assign static IPs. Check each VM with ip addr. If one VM is 172.16.0.1, the other needs a compatible address, such as another 172.16.0.x address with the right subnet mask, not an unrelated NAT-only address.

2. Test the SSH port, not only ping

ping is only an auxiliary test because ICMP can be blocked or deprioritized. A failed ping does not prove SSH cannot work. Test the TCP port and SSH handshake directly from the client VM:

If nc is not installed, use ssh -v output as the main diagnostic.

The original environment mentions Ubuntu Server 12.04. Treat that as a legacy lab system, not a current supported Ubuntu configuration. The safer path is to isolate that VM, avoid exposing it outside the experiment network, and migrate the test to a supported Ubuntu release when possible. The modern service commands below apply to current supported Ubuntu systems using systemd; they are not meant to imply that Ubuntu 12.04 uses the same service management.

3. Start or install the SSH server on the target VM

scp connects to the SSH server on the machine receiving the connection. Ubuntu’s OpenSSH server guide installs it with sudo apt install openssh-server. On a current supported Ubuntu server, check and start it:

  • systemctl status ssh
  • sudo systemctl start ssh
  • ss -tlnp | grep ':22'

If a lab firewall is enabled, allow only the experimental network or client address rather than turning the firewall off globally. For example, adapt this pattern to your lab subnet: sudo ufw allow from 172.16.0.0/24 to any port 22 proto tcp.

4. Interpret common SSH/scp failures

  • Connection refused: the IP is reachable but nothing is listening on that port, or the service is bound differently. Start/install SSH or check the port.
  • Connection timed out: routing, subnet, VirtualBox network mode, firewall, or wrong IP is blocking the TCP connection.
  • Permission denied: the network works, but username, password, SSH key, account permissions, or server authentication settings are wrong.
  • Host key changed or unknown: verify the server fingerprint before accepting or replacing known-host entries.

5. Use the right scp syntax

Modern scp(1) uses SFTP over SSH and the same authentication as an SSH login. A basic copy from the client VM to the server VM is:

scp ./test.txt [email protected]:/home/user/

If SSH uses a non-default port, use uppercase -P: scp -P 2222 ./test.txt [email protected]:/tmp/. Lowercase -p has a different meaning.

6. Verify host fingerprints safely

On the server console, show the host key fingerprint with sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub.

Compare it with what the client displays. ssh-keyscan(1) says gathered host keys should be verified out of band or used directly only on a trusted network, and ssh_config(5) documents host-key checking. In a lab, verify first; do not bypass host-key protection just to make the warning disappear.