Bureaucrats, confirmed, Administrators
4,558
edits
Changes
Created page with "HOWTO can be found at http://www.debuntu.org/ssh-key-based-authentication == Configuration == Setup a local user configuration for your SSH sessions to make things much easie..."
HOWTO can be found at http://www.debuntu.org/ssh-key-based-authentication
== Configuration ==
Setup a local user configuration for your SSH sessions to make things much easier.
Using the configuration below, I can simply "<code>ssh server4</code>" rather than ssh grundlett@server4.example.com
or,
"<code>ssh server2</code>" rather than "ssh -v -L 55432:localhost:5432 grundlett@server2.example.com"
<source lang="bash">
cat .ssh/config
# keep ssh connections open
ServerAliveInterval 60
# set some aliases
host server2
HostName server2.example.com
# send local Postgres traffic on 55432 to remote side standard port 5432
# this allows me to open a desktop client locally on the extended port
# and talk to the server (like it was local) through an encrypted SSH tunnel
LocalForward 55432 localhost:5432
host server3
HostName server3.example.com
host server4
HostName server4.example.com
host server5
HostName server5.example.com
host it
HostName it00.example.net
ForwardX11 yes
# set some options for a pattern of hosts
host *.example.com server*
User grundlett
# HOW TO FORWARD X screen, and use agent forwarding
host example.com
User greg
ForwardAgent yes
ForwardX11 yes
host github.com
User <PUT YOUR USER HERE>
Hostname github.com
IdentityFile /home/greg/.ssh/<id_rsa.MYKEY>
host *.amazonaws.com
User root
IdentityFile /home/grundlett/.ssh/ec2-keypair.pem
host amazon
HostName ec2-72-44-63-125.compute-1.amazonaws.com
</source>
== Client ==
[[File:Seahorse.png|right|447px| An encryption tool ]]
Installing a program like [http://projects.gnome.org/seahorse/ Seahorse] makes it trivially easy to manage your GnuPG encryption keys. Seahorse just makes it easier for you to do what you otherwise would accomplish with several commands. You can generate a private key; and add the public key to remote servers enabling you to login to those remote servers without using a password.
== Fingerprints ==
The SSH key fingerprint tells you the authenticity of a host. Normally this info is stored in /etc/ssh/ for a Debian-based distro. You can also use the same command here to look at the fingerprint for your public key.
<source lang="bash">
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
2048 dd:54:23:d4:20:bc:f3:4c:88:a5:af:21:dd:a5:36:5d /etc/ssh/ssh_host_rsa_key.pub (RSA)
</source>
== Reverse Tunnel ==
Maybe you've got a production database server that wasn't setup properly for security, and only allows "local" database connections. You need to access your production data from places other than your datacenter. You could fix it - but that would take a lot of effort that the boss doesn't care about. SSH to the rescue!
To setup the reverse tunnel from '''DESTINATION''' to '''SOURCE''', you first get on the destination box and ssh to the source while telling that ssh session to "listen" on a high-number port
;on DESTINATION (where you want to use the data):
ssh -R 19999:localhost:22 grundlett@source.ip
Then you get on the source machine, and ssh to localhost, but specify the high-range port number you reserved earlier.
;on SOURCE machine:
ssh localhost -p 19999
If you do these in [[screen]] sessions, they should survive any network connectivity issues and you can log out completely. See above config section to set this up by default for certain situations.
[[Category:System Adminstration]]
== Configuration ==
Setup a local user configuration for your SSH sessions to make things much easier.
Using the configuration below, I can simply "<code>ssh server4</code>" rather than ssh grundlett@server4.example.com
or,
"<code>ssh server2</code>" rather than "ssh -v -L 55432:localhost:5432 grundlett@server2.example.com"
<source lang="bash">
cat .ssh/config
# keep ssh connections open
ServerAliveInterval 60
# set some aliases
host server2
HostName server2.example.com
# send local Postgres traffic on 55432 to remote side standard port 5432
# this allows me to open a desktop client locally on the extended port
# and talk to the server (like it was local) through an encrypted SSH tunnel
LocalForward 55432 localhost:5432
host server3
HostName server3.example.com
host server4
HostName server4.example.com
host server5
HostName server5.example.com
host it
HostName it00.example.net
ForwardX11 yes
# set some options for a pattern of hosts
host *.example.com server*
User grundlett
# HOW TO FORWARD X screen, and use agent forwarding
host example.com
User greg
ForwardAgent yes
ForwardX11 yes
host github.com
User <PUT YOUR USER HERE>
Hostname github.com
IdentityFile /home/greg/.ssh/<id_rsa.MYKEY>
host *.amazonaws.com
User root
IdentityFile /home/grundlett/.ssh/ec2-keypair.pem
host amazon
HostName ec2-72-44-63-125.compute-1.amazonaws.com
</source>
== Client ==
[[File:Seahorse.png|right|447px| An encryption tool ]]
Installing a program like [http://projects.gnome.org/seahorse/ Seahorse] makes it trivially easy to manage your GnuPG encryption keys. Seahorse just makes it easier for you to do what you otherwise would accomplish with several commands. You can generate a private key; and add the public key to remote servers enabling you to login to those remote servers without using a password.
== Fingerprints ==
The SSH key fingerprint tells you the authenticity of a host. Normally this info is stored in /etc/ssh/ for a Debian-based distro. You can also use the same command here to look at the fingerprint for your public key.
<source lang="bash">
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
2048 dd:54:23:d4:20:bc:f3:4c:88:a5:af:21:dd:a5:36:5d /etc/ssh/ssh_host_rsa_key.pub (RSA)
</source>
== Reverse Tunnel ==
Maybe you've got a production database server that wasn't setup properly for security, and only allows "local" database connections. You need to access your production data from places other than your datacenter. You could fix it - but that would take a lot of effort that the boss doesn't care about. SSH to the rescue!
To setup the reverse tunnel from '''DESTINATION''' to '''SOURCE''', you first get on the destination box and ssh to the source while telling that ssh session to "listen" on a high-number port
;on DESTINATION (where you want to use the data):
ssh -R 19999:localhost:22 grundlett@source.ip
Then you get on the source machine, and ssh to localhost, but specify the high-range port number you reserved earlier.
;on SOURCE machine:
ssh localhost -p 19999
If you do these in [[screen]] sessions, they should survive any network connectivity issues and you can log out completely. See above config section to set this up by default for certain situations.
[[Category:System Adminstration]]