Apparently there are numerous attempts to log into my NAS (with invalid passwords) from the WAN side. Synology offers a feature to block IP addresses after a couple of invalid attempts and also log that blocking, and I am making use of that feature. After quite some months I got worried by the overwhelming number of such attempts. Today I disabled password authentication all together. I (and “everybody”) can still log in through the web GUI DSM interface.
$ ssh -v -Y REMOTE_HOST
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Requesting authentication agent forwarding.
X11 forwarding request failed on channel 0
I looked around and I found this article:
The article advises to edit /etc/ssh/sshd_config on the remote system:
$ sudo vi /etc/ssh/sshd_config
and to add these lines:
The remote sshd needs reloading, and because the remote system uses systemd, this is how:
$ systemctl restart sshd
Now after a new “ssh -Y” I can start xeyes and it gets displayed on my PC’s Cygwin/X server.
…/opt/cygwin64/bin/cp.exe: error while loading shared libraries: cygattr-1.dll: cannot open shared object file: No such file or directory
I wasn’t able to find a viable fix on the web.
I found a copy of that file in in old installation, and I copied that into the cygwin bin directory – the cygwin64 and the non-64 one – at least for cygwin64 it fails w/o moaning properly, just that it yields exit code 127.
I like the “-B” (“–no-admin”) command line approach best.
- http://www.dmoz.org – closed as of 2017-03-14
- https://dmoztools.net – just a static mirror – currently “site:www.dmoztools.net …” is possible on DuckDuckGo and Google
- https://www.curlie.org – just a static mirror so far, but apparently going to be searchable in the future – currently no “site:www.curlie.org …” search on DuckDuckGo and Google
I chose the approach “set language at runtime“:
Works like a charm.
On the Win7 PC at work I have no admin rights, therefore I cannot change the config file mentioned in the thread.
Every now and then I come across this error message:
Cannot find local copy program: pscp
This only occurs for “bigger” files (e.g. a 40k file), not for small files, because small files are being dealt with by plink.
tramp-do-copy-or-rename-file-out-of-band (in lisp/net/tramp-sh.el) tries to find the copy-program on exec-path instead of PATH, so we have to add putty-directory to exec-path as well. I amended this page to deal with the situation: