The Linux Terminal Server Project team have released version 5.2 after two years and almost one thousand commits. It has become one pretty powerful product! I like the ability to “run the whole session remotely or run select applications locally to use specific hardware or advance 3D capabilities.”
I use rsync to move most of my data around the place (who doesn’t!?), but sometimes I have to copy files to a server where SSH is running on a port other than 22. How do I tell rsync to use a different port for SSH? Like this:
rsync -e "ssh -p [remote-ssh-port]" ~/local-files/ user@remote-server:remote-files/
Handy indeed. Thanks rsync!
I also like to pass “
-P” to the command so that I get a nicer progress than verbose mode, so:
rsync -Pae "ssh -p [remote-ssh-port]" ~/local-files/ user@remote-server:remote-files/
I’m sure that most users will already know this, but it’s handy to put on my blog as a reference for my ageing brain!
Came across a decent collection of tips for SSH by Vivek Gite. If you’re using SSH (and even if you’re not!) it’s worth a look.
A design flaw in OpenSSH has been found. With a one in 262,144 chance of success, a man-in-the-middle attack could render data in plaintext. The issue is not caused by a coding error, but rather the RFC standard.
By re-transmitting the blocks to the server, an attacker can work out the first four bytes of corresponding plaintext. The attacker can do this by counting how many bytes the attacker sends until the server generates an error message and tears down the connection, then working backwards to deduce what was in the OpenSSH encryption field before encryption.
A work around is included in version 5.2, which is not yet in Debian stable. Other distros would also be affected.