SSH being enabled is also known as having "shell access" enabled. It's generally considered a risk for various reasons, most notably because runaway processes can be an issue.
- 2017-11-26 - OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 on Devuan-1.0.0-jessie-i386-DVD
2017-11-26 - OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 on 3.10.0-714.10.2.lve1.4.63.el7.x86_64
- rsync can easily be done over SSH.
[http://matt.ucc.asn.au/ssh-xfer/ ssh-xfer] replaces the ssh daemon and then lets your client side run ssh-xfer to transfer files. Interesting.
Generating an SSH key (so you don't have to type a password) ∞
So that you don't have to use passwords.
ssh-keygen -t dsa -b 1024
.. this will generate
scp (SSH copy) ∞
SSH cp (copy)
scp filename.ext user@host:/path/to/dest/
Learning the version of SSH you have ∞
--version would work, but no:
Older version of ssh might do:
\ssh -v localhost
You could also check your package manager.
For example, APT has:
\apt-cache show ssh
Avoid being forced to log in with SSH ∞
The LUFS "lussh" SSH setup helper script.
Load SSH agent within subshell ∞
When you run ssh-agent, it prints out what you need to do in order to make SSH pick it up. To do this automatically, use the following alias:
alias agent='exec ssh-agent $SHELL -c "ssh-add; $SHELL"'
Now you can simply type:
and it will prompt for your keyphrases and in the new shell you can use SSH without exporting a lot of environment variables by hand. The shell will be replaced by a shell which has these settings in the environment.