New answers tagged

0

The special handling of \\TSCLIENT\<sharename>, as well as RDPCLIP which forwards newly captured clipboard content in both directions, are closest to the tunneling you are describing. The RDP protocol does seem provide the bits and pieces that would let you write a tunneller, but long ago I threw a few days at the problem and got nowhere. late update: ...


1

I figured out that it has not really anything to do with ssh, but with IP tables on the server (where sshd runs): # iptables -S | grep 22 -A ufw-user-input -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 6 --name DEFAULT --mask 255.255.255.255 --rsource -j ufw-user-limit


0

One silly mistake I made (and spent a while to realize) was that instead of editing sshd_config I was editing ssh_config and that was the reason why the changes did not have the intended effect.


0

For me this was a permissions issue on the .ssh/authorized_keys file for the user connecting. Saw this when I changed the logging to: SyslogFacility LOCAL0 LogLevel DEBUG3 To correct the permissions on the .ssh/authorized_keys file; right click properties -> Advanced button (bottom right) -> Change owner (at top) to the users account. Restart the ...


Top 50 recent answers are included