Ssh: Difference between revisions

From Bitpost wiki
No edit summary
 
(12 intermediate revisions by the same user not shown)
Line 6: Line 6:
  mkdir -p .ssh
  mkdir -p .ssh
  cd .ssh
  cd .ssh
  scp $GOODHOST:.ssh/id_rsa* .
  scp $GOODHOST:.ssh/id_ed25519* .
  cat id_rsa.pub >> authorized_keys
  cat id_ed25519.pub >> authorized_keys
  # -- COPY AND PASTE END --
  # -- COPY AND PASTE END --
* Control-D to disconnect and ssh back in to make sure it's working
* Control-D to disconnect and ssh back in to make sure it's working
* (Optional) You can also use any other keys, by specifying an [IdentityFile] in .ssh/config.
 
=== Upgrading a system with an old key ===
When I start using a new key, and deprecating the old, older systems will stop being "connectable".  To fix:
* From the proxmox console, edit sshd to allow passwords again:
sudo emacs -nw /etc/ssh/sshd_config # and comment out the PasswordAuthentication block
  # MDM It's 2018, time to turn off password auth.
  #PasswordAuthentication no
  #ChallengeResponseAuthentication no
  #UsePAM no
sudo service ssh restart
* Connect to it from a host with the new key
* Using two terminals, copy/paste the newer key into place, and remove the old
* Undo sshd changes and verify you can connect
* Fix ~/.ssh/config to point to the new key.  This gets tricky bc you must change the file that has also been changed upstream.
emacs ~/.ssh/config # change key
cd development/config
git commit -a -m "Fix (host) config"
git pull # and fix merge up
git push
 
=== Clean room hardened config ===
If you're dealing with a machine that has some unknown ssh config, [https://cryptsus.com/blog/how-to-secure-your-ssh-server-with-public-key-elliptic-curve-ed25519-crypto.html reset it to hardened key auth] as follows.  This is a good way to start in general, for completeness.
==== Client ====
ssh-keygen -o -a 256 -t ed25519 -C "$(hostname)-$(date +'%d-%m-%Y')"
#Make the .ssh directory unreadable for other users and groups
chmod 700 ~/.ssh
chmod 700 /home/$USER/.ssh
#Make the private SSH key read only
chmod 400 /home/$USER/.ssh/id_ed25519
chmod 400 ~/.ssh/id_ed25519    
#Make the local $USER own the SSH key pair files
chown $USER:$USER ~/.ssh/id_ed25519*
chown $USER:$USER /home/$USER/.ssh/id_ed25519*
==== Server ====
sudo rm /etc/ssh/ssh_host_*                  #Delete old SSH keys
rm ~/.ssh/id_*                              #Delete old SSH keys
sudo dpkg-reconfigure openssh-server        #Reset SSH config to defaults and generate new key files
rm /home/$USER/.ssh/id_*                    #Delete old SSH keys
vi /home/$USER/.ssh/authorized_keys          #paste public key here
cd /home/$USER/ && chmod g-w,o-w .ssh/      #The directory containing your .ssh directory must not be writeable by group or others
chmod 600 /home/$USER/.ssh/authorized_keys  #change permissions to r+w only for user
sudo service sshd restart                    #restart and reload keys into the SSH deamon
 
=== Generate fresh keys ===
* If you need a new identity, use this to generate the keys:
cd ~/.ssh
# use ed25519, the newest cipher, it's smaller, performs better AND more secure
ssh-keygen -t ed25519 -C moodboom@gmail.com
chmod 400 id_rsa
cat id_rsa.pub >> authorized_keys
 
=== Shortcut and Key organization ===
* Always set up shortcuts to get to hosts fast in .ssh/config; see common for example, it's used everywhere.
* You can use any file for key by specifying an [IdentityFile] in .ssh/config.
   
   
=== Enable X11 forwarding ===
=== Enable X11 forwarding ===
Line 17: Line 70:
* server: enable in /etc/ssh/sshd_config
* server: enable in /etc/ssh/sshd_config
* server: make sure you have an X environment installed (install of any X app will pull it in)
* server: make sure you have an X environment installed (install of any X app will pull it in)
* client: set default-on in /etc/ssh/ssh_config (in place of ssh -Y)
* client: set [ForwardX11Trusted yes] in /etc/ssh/ssh_config (no doesn't work)
* client: make sure you have an X server environment - on windows, use [[x2go]]
* client: make sure you have an X server environment - on windows, use [[x2go]]
* if you need to become root after you have ssh'ed (for example to run wireshark), do this magic to patch in x authorization, oh yeah!
* if you need to become root after you have ssh'ed (for example to run wireshark), do this magic to patch in x authorization, oh yeah!
Line 24: Line 77:
  [root ~]# xauth add $(xauth -f ~ec2-user/.Xauthority list|tail -1)
  [root ~]# xauth add $(xauth -f ~ec2-user/.Xauthority list|tail -1)
  [root ~]# xclock& # good to go!
  [root ~]# xclock& # good to go!
NOTE: This step gets it going automatically, but that has messed with the ability to ssh/git through non-X servers like bitpost.  Just use [ssh -Y] as needed.
* client: set [ForwardX11 yes] in /etc/ssh/ssh_config (in place of ssh -Y)


=== ProxyJump ===
=== ProxyJump ===

Latest revision as of 14:57, 21 March 2023

Quickstart

  • For any new host, you need to copy private key to .ssh and cat public key into .ssh/authorized_keys.
ssh newhost
export GOODHOST=bitpost.com
# -- YOU CAN COPY AND PASTE THIS --
mkdir -p .ssh
cd .ssh
scp $GOODHOST:.ssh/id_ed25519* .
cat id_ed25519.pub >> authorized_keys
# -- COPY AND PASTE END --
  • Control-D to disconnect and ssh back in to make sure it's working

Upgrading a system with an old key

When I start using a new key, and deprecating the old, older systems will stop being "connectable". To fix:

  • From the proxmox console, edit sshd to allow passwords again:
sudo emacs -nw /etc/ssh/sshd_config # and comment out the PasswordAuthentication block
 # MDM It's 2018, time to turn off password auth.
 #PasswordAuthentication no
 #ChallengeResponseAuthentication no
 #UsePAM no
sudo service ssh restart
  • Connect to it from a host with the new key
  • Using two terminals, copy/paste the newer key into place, and remove the old
  • Undo sshd changes and verify you can connect
  • Fix ~/.ssh/config to point to the new key. This gets tricky bc you must change the file that has also been changed upstream.
emacs ~/.ssh/config # change key
cd development/config
git commit -a -m "Fix (host) config"
git pull # and fix merge up
git push

Clean room hardened config

If you're dealing with a machine that has some unknown ssh config, reset it to hardened key auth as follows. This is a good way to start in general, for completeness.

Client

ssh-keygen -o -a 256 -t ed25519 -C "$(hostname)-$(date +'%d-%m-%Y')"
#Make the .ssh directory unreadable for other users and groups
chmod 700 ~/.ssh			
chmod 700 /home/$USER/.ssh	 		
#Make the private SSH key read only
chmod 400 /home/$USER/.ssh/id_ed25519 
chmod 400 ~/.ssh/id_ed25519 				 	    	
#Make the local $USER own the SSH key pair files
chown $USER:$USER ~/.ssh/id_ed25519*		 
chown $USER:$USER /home/$USER/.ssh/id_ed25519*

Server

sudo rm /etc/ssh/ssh_host_*                  #Delete old SSH keys
rm ~/.ssh/id_*                               #Delete old SSH keys
sudo dpkg-reconfigure openssh-server         #Reset SSH config to defaults and generate new key files
rm /home/$USER/.ssh/id_*                     #Delete old SSH keys
vi /home/$USER/.ssh/authorized_keys          #paste public key here
cd /home/$USER/ && chmod g-w,o-w .ssh/       #The directory containing your .ssh directory must not be writeable by group or others
chmod 600 /home/$USER/.ssh/authorized_keys   #change permissions to r+w only for user
sudo service sshd restart                    #restart and reload keys into the SSH deamon

Generate fresh keys

  • If you need a new identity, use this to generate the keys:
cd ~/.ssh 
# use ed25519, the newest cipher, it's smaller, performs better AND more secure
ssh-keygen -t ed25519 -C moodboom@gmail.com
chmod 400 id_rsa
cat id_rsa.pub >> authorized_keys

Shortcut and Key organization

  • Always set up shortcuts to get to hosts fast in .ssh/config; see common for example, it's used everywhere.
  • You can use any file for key by specifying an [IdentityFile] in .ssh/config.

Enable X11 forwarding

  • server: install xauth
  • server: enable in /etc/ssh/sshd_config
  • server: make sure you have an X environment installed (install of any X app will pull it in)
  • client: set [ForwardX11Trusted yes] in /etc/ssh/ssh_config (no doesn't work)
  • client: make sure you have an X server environment - on windows, use x2go
  • if you need to become root after you have ssh'ed (for example to run wireshark), do this magic to patch in x authorization, oh yeah!
sudo su -
[root ~]# touch .Xauthority
[root ~]# xauth add $(xauth -f ~ec2-user/.Xauthority list|tail -1)
[root ~]# xclock& # good to go!

NOTE: This step gets it going automatically, but that has messed with the ability to ssh/git through non-X servers like bitpost. Just use [ssh -Y] as needed.

  • client: set [ForwardX11 yes] in /etc/ssh/ssh_config (in place of ssh -Y)

ProxyJump

You can set up a hostname configuration to jump directly through another machine if needed:

  • make sure you are running ssh>=7.3 everywhere
    • if you have to jump through Windows, Cygwin has a nice sshd that works out of the box for the most part, with ProxyJump capability.
    • Ubuntu must be 17.04 or newer.
  • configure a host shortcut AwsInstance from dmz to internet
  • configure a host shortcut DmzHostfrom lab to dmx
  • configure a host shortcut AwsInstanceJumpfrom lab to internet, with ProxyJump DmzHost