3

I have a setting where only scp connections are allowed to a remote server, with ssh login being disabled (i.e. you can't get a shell into that server), and I am seeking a clean way to test the connectivity without transferring an actual file.

The reason for this is that the server is configured to trigger some events upon the reception of new files on users' home directories. Thus, I would like to avoid triggering such events when running connectivity tests.

I will post my workaround as an answer (in case it's helpful for anyone else) but I am looking for cleaner solutions that I haven't thought of.


PS. This question has been previously asked in Unix and Linux forum but hasn't been answered.

2
  • 1
    "I don't want to trigger such events" – Does pulling a file trigger such events? E.g. you can download /etc/fstab or /etc/issue. Commented Apr 28, 2023 at 18:25
  • @KamilMaciorowski it doesn't and that's an interesting solution! Commented Apr 29, 2023 at 16:50

4 Answers 4

3

AFAIK the legacy scp cannot work without access to a shell on the remote side*. Please read "History, SCP and SFTP" in this answer of mine.

Since "you can't get a shell into that server" and still your scp works, it probably uses the SFTP protocol. On the server side it's possible to enable SFTP without giving access to a shell. I guess this is the case. scp using SFTP instead of SCP is the modern way.

If your scp indeed uses SFTP while connecting to the server in question, you can as well use sftp to connect. With sftp it's easy to transfer nothing:

echo bye | sftp -b - user@server

Exit status 0 means sftp successfully visited the server only to say bye.


* Except when there is no remote side. If asked to copy from local to local then scp will use cp.

1
  • 1
    Possibly scp-client works because it's (recent and) using sftp, but also possibly the server is configured per-user (or globally!) with ForceCommand, or per-userkey with command=, or even per-usercert in the cert, to something that allows scp but nothing else. Commented Apr 29, 2023 at 1:41
2

Consider rsync in --dry-run mode:

rsync -av --dry-run test.txt [email protected]:

--dry-run, -n perform a trial run with no changes made

2
  • I like this answer. Is there any equivalent for scp? Commented Apr 28, 2023 at 15:48
  • No, AFAIK there's no way with scp to do the same. Commented Apr 28, 2023 at 16:02
2

TL;DR. Copy to /dev/null

Since in this specific use case, we are trying to avoid writing to the user's home directory, one solution would be to use /dev/null as the destination file (since it is writable by all users) and check if the file has been successfully transferred. This way, connectivity is tested while directories are kept clean.

scp test.txt [email protected]:/dev/null

and the output should look like

test.txt   100%   13   3.6KB/s   00:00
1

OP said:

The reason for that, is the that server is configured to trigger some events upon reception of new files on the user's home directory and I don't want to trigger such events when testing.

Then the options are:

  1. You can copy it somewhere else, just outside of your home directory, like /tmp (which usually has 777 mode), or like what the OP himself is doing, copy to /dev/null.
  2. You can copy a file from the server. There are files that (almost) always exist on Unix/Linux systems, like /etc/hostname.
  3. You can copy a non existent file from the server, too. Obviously your SSH client needs to connect successfully to figure out that the file does not exist. The error message produced by the client would be different ("No such file or directory").
  4. Now having said this above. Even if your SSH disables login for you, you should still be able to use ssh or ssh -v, etc. and expect different error messages when you attempt to connect, and tell if the connection is up by parsing the error messages.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.