Linux Notes: Configuring ssh2 for sftp, scp, rsync, etc.

  1. The information presented here is intended for educational use by qualified computer technologists.
  2. The information presented here is provided free of charge, as-is, with no warranty of any kind.
Edit: 2023-05-02 (fixed some typos)

SSH and SSH2

  • SSH (colloquially known as SSH-1) 
    • is the original Secure SHell technology developed in 1995
    • it is only based upon RSA Keys
    • has been exploited due to some known weaknesses
    • update: in 2019 you will usually find SSH disabled. You should only enable it to interface with older systems unable to upgrade to SSH2
  • SSH-2 is a subsequent technology developed in 2006.
    • it can use either DSA or RSA keys
    • update: in 2019 you will usually find DSA disabled. It is better to use RSA with a larger key
  • SSH-1.99 is the name of the IETF certified server technology to support both SSH-1 and SSH-2
    • developed after SSH-2.1


  1. In default out-of-the-box mode, these technologies encrypt your ssh-based connection to conceal everything including the connect password. Most interactive users using ssh client will not need to go beyond this mode. BTW, I doubt you will ever find telnet or ftp installed in modern Linux systems because passwords are sent unencrypted. However, Installing telnet and ftp clients is child's play. Installing their server counterparts (telnetd and ftpd) is easy but getting them to work properly requires changes to the software firewall via "firewall-cmd" and SELinux (and you are insane if you ever disable these two security modules)
  2. You can go one step further and deposit YOUR public key at a remote location so you will not need a password (the private-public key replaces the password associated with the account in the remote OS). This is a prerequisite for doing autonomous non-interactive (batch) transfers from programs like sftp. Initially the far-end administrator will provide you with a 24-hour temporary account and password which will only be used by you to setup the sftp account.
  3. If you like, you can encode a pass-phrase in your private key (this will foil an evil system admin on your client platform) but this is not allowed when setting up Secure Shell for use with autonomous non-interactive (batch) transfers.

Related Utilities

  • Programs like sftp (secure ftp), scp (secure copy) and rsync are based upon SSH/SSH2 which means that this underlying technology must first work properly
    • If you cannot create a Secure Shell connection ( by typing: ssh user@server.domain.tld ) then nothing else will work.
  • A few more details:
    • when you open an sftp connection, a specialized ftp client on your end first creates an ssh tunnel on port 22 (includes various authentication schemes)
    • once the tunnel is set up, it is used to issue commands to a specialized ftp server program at the remote end
  • Many Linux systems may have difficulty using public key files generated on older systems that look like this:
    ---- BEGIN SSH2 PUBLIC KEY ----
    Subject: custodian
    Comment: "1024-bit rsa,, Mon Apr 27 2020 1\
    ---- END SSH2 PUBLIC KEY ----
    Why? File "~/.ssh/authorized_keys" on Linux currently requires the public key to sit on one single line with no superfluous information or control characters like this:
    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCC..........PQ== optional-comment
  • public key import-export demos
    # title   :
    # author  : Neil Rieck
    # edit    : 2020-04-30
    # platform: CentOS-7.7
    # ==========================
    rm neil_test_key*
    # create rsa key pair
    #   private key defaults to PEM
    #   public key defaults to one-liner
    ssh-keygen -f neil_test_key1 -t rsa -b 1024 -N ""
    # create rsa key pair
    #   private key is forced to new format with "-o" (valid with OpenSSH 6.5) 
    #   public key defaults to one-liner
    ssh-keygen -f neil_test_key9 -o     -b 1024 -N ""
    # convert public key for export to another system
    ssh-keygen -e -f  >
    # convert public key for import from another system
    ssh-keygen -i -f >
    # compare imported result to original (only comments are different)
    diff -s
    # compare files (again)
    vim -d file1 file2
    # use command :qa to quit-all # # let's see the mess ls -la neil_test_key*
  • on very rare occasions (like moving an interface from an older system to Linux) you may want to also move a private-key file. Linux man pages claim that "ssh-keygen -i" can be used to convert the file but I have never gotten this to work (always throws a magic number error followed by a core dump). I have had luck copying the file then modifying it via vim
    Subject: custodian
    Comment: "1024-bit rsa,, Mon Apr 27 2020 1\
    ...snip... VyFpdL+brlVS/kIrCZF+SsUD+WL4K3uZN+tP8vNznKTzKQ2bOP2eHH4nQ9uhX6xmKeUw/J N5FsHA== ---- END SSH2 ENCRYPTED PRIVATE KEY ----
    VyFpdL+brlVS/kIrCZF+SsUD+WL4K3uZN+tP8vNznKTzKQ2bOP2eHH4nQ9uhX6xmKeUw/J N5FsHA== -----END RSA PRIVATE KEY-----

CentOS-7.5 (and higher)

# =============================================================================
# title  : ssh-help.txt
# author : Neil Rieck
# created: 2019-09-23
# edit   : 2019-09-23
# target : CentOS-7.5 to CentOS-7.5
# purpose:
# 1) Shell scripts containing a list of rsync, sftp and scp commands, when run
#    from cron, must never be presented with a password prompt.
# 2) This file describes steps to allow user-A on system-A to connect as
#    user-B on system-B without a password (authentication is now done by a
#    public-private key pair)
# 3) CAVEAT: you may need to modify "/etc/ssh/ssh_config" of the local client machine
#    as well as "/etc/ssh/sshd_config" of the remote server machine
# a) /etc/ssh/ssh_config
#    Uncomment these lines:
#       IdentityFile ~/.ssh/identity	# recommended for ssh2
#       IdentityFile ~/.ssh/id_rsa	# recommended for ssh2
# b) /etc/ssh/sshd_config
#    Uncomment these lines:
#       PubkeyAuthentication yes	# required
#       PermitRootLogin yes		# optional
#    Caveat: remember to restart sshd after changes here
# =============================================================================
#	STEP-01 (optional; only do once)
# 1) this next command will create two files:
#	.ssh2/id_rsa
#	.ssh2/
#	STEP-02 (recommended)
# 1) create a specific public-private key pair for use by root when 
#    connecting from kawc4n to kawc4m. Use one of these filename formats:
#	username_source_destination
#	username_on_source
# 2) In 2019 you might find DSA disabled so just use RSA where possible
# 3) when prompted, do not enter a passphrase
ssh-keygen -t rsa -b 1024 -f ~/.ssh/root_on_kawc4n
#       STEP-03 (configure client side)
cd .ssh						# drop down one level
cat id_rsa         >> identity			# copy private key into identity (a one-line payload)
cat root_on_kawc4n >> identity			# copy private key into identity
#	STEP-04 (copy public key(s) but do not use ssh-copy-id)
# 1) copy public key(s) to the remote site
ls -la
   drwx------.  2 root root  129 Sep 23 16:38 .
   dr-xr-x---. 19 root root 4096 Sep 23 16:38 ..
   -rw-------.  1 root root 1679 Sep 23 16:09 identity
   -rw-------.  1 root root 1679 Sep 23 14:00 id_rsa
   -rw-r--r--.  1 root root  393 Sep 23 14:00
   -rw-r--r--.  1 root root  195 Sep 23 12:54 known_hosts
   -rw-------.  1 root root 1679 Sep 23 16:09 root_on_kawc4n
   -rw-------.  1 root root  393 Sep 23 12:38
sftp			# connect via sftp
put				# recommended push
put					# optional push
exit						# log out (drop back to kawc4n)
cd ..						# navigate back up one level
#	STEP-05 (config the remote end)
ssh			# connect via ssh to server
ls -la *.pub					# view public key files
cat >> .ssh/authorized_keys	# copy public into here
cat         >> .ssh/authorized_keys	# copy public into here
rm *.pub                                        # delete public keys
exit						# log out (drop back to client)
#	STEP-6 (final test)
ssh			# you should not see a password prompt
#	STEP-7 (debug; if something went wrong)
ssh -v			# -v -vv -vvv for more debugging messages


Back to Home
Neil Rieck
Waterloo, Ontario, Canada.