6836
Comment:
|
9354
|
Deletions are marked like this. | Additions are marked like this. |
Line 19: | Line 19: |
= Jumphost = In some situations (e.g. security reasons) it's necessary to log in on a SSH jumhost first and from there to the final SSH destination. * Painful {{{ [personal computer] ssh <user>@jumphost.example.com [jumphost] ssh <user>@sfinalhost.example.com }}} * Better, but a lot to type {{{ [personal computer] ssh -J <user>@jumphost.example.com <user>@sfinalhost.example.com }}} * Lazy user solution: {{{ # File `~/.ssh/config` (on personal computer): Host jumphost Hostname jumphost.example.com Host finalhost User <user> Hostname finalhost.example.com ProxyJump jumphost # Just type [personal computer] ssh finalhost }}} Tip: if a host shows anoying banner on logging, suppress it by: {{{ $ ssh -o LogLevel=error <user>@<host> # the option can also specified in ~/.ssh/config in general LogLevel error # the option can also specified in ~/.ssh/config per host Host finalhost LogLevel error }}} |
|
Line 120: | Line 166: |
The passphrase is used to encrypt and decrypt your private key. If somehow some gets possession of your private key, he won't be able to use it unless he also knows the passphrase. | The passphrase is used to encrypt and decrypt your private key. If somehow someone else gets possession of your private key, they will not be able to use it unless they also know the passphrase. |
Line 126: | Line 172: |
== ssh-agent == To use a passphrase, stored and offered via keyring: * Keyring should be opened: this happens typically shortly after login if the first application tries to access the keyring. * Typically a `gnome-keyring-daemon` and a `ssh-agent` is running per user: {{{ $ ps -ef | grep keyring crose 632315 1 0 Feb09 ? 00:00:00 /usr/bin/gnome-keyring-daemon --start --components=pkcs11 crose 642701 632315 0 Feb09 ? 00:00:00 /usr/bin/ssh-agent -D -a /run/user/10688/keyring/.ssh }}} * The bourne shell should have the SSH_AUTH_SOCK variable set, to inherit expecially to all child shells. {{{ declare -x SSH_AUTH_SOCK="/run/user/10688/keyring/ssh" }}} * Normally a Gnome/Cinnamon session starts during login the `gnome-keyring` process. * Manually set for current terminal https://www.commithub.com/add-your-ssh-key-to-the-ssh-agent/ {{{ $ eval "$(ssh-agent -s)" $ ssh-add ~/.ssh/<private_key_file> }}} == keychain: remote connection using ssh-agent == `a) [alice@home] > b) bob@ssh.math.uzh.ch > c) charly@compute.math.uzh.ch` In case a remote login via ssh is done (a) and on the target host (b) the local keys should be used, an ssh-agent has to be started on the target host (b) and has to be supplied with the private key. {{{ [alice@home] $ ssh bob@ssh.math.uzh.ch [bob@ssh.math.uzh.ch] $ eval `keychain --eval` $ ssh-add ~/.ssh/id_rsa ... $ ssh charly@compute.math.uzh.ch }}} |
|
Line 136: | Line 225: |
If you think your IP address have been blocked (indication: no password prompt appears), you can free your IP address: | If you think your IP address has been blocked (indication: no password prompt appears), you can free your IP address: |
Line 139: | Line 228: |
= Proxy by SSH (browser) = * [[ProxyBySsh]] |
SSH
Server: ssh.math.uzh.ch
Username / Password: <IMATH username> / <IMATH Password>
- Usage
copy files: SFTP
start applications (text based and gui): SSH
Contents
Filetransfer - SFTP
OS |
Application |
Download |
Linux |
Nautilus |
built in: sftp://[user]@ssh.math.uzh.ch |
Windows |
FileZilla |
|
MacOS X |
FileZilla |
- Server: ssh.math.uzh.ch
- User: I-MATH account name
- Password: I-MATH password
Jumphost
In some situations (e.g. security reasons) it's necessary to log in on a SSH jumhost first and from there to the final SSH destination.
- Painful
[personal computer] ssh <user>@jumphost.example.com [jumphost] ssh <user>@sfinalhost.example.com
- Better, but a lot to type
[personal computer] ssh -J <user>@jumphost.example.com <user>@sfinalhost.example.com
- Lazy user solution:
# File `~/.ssh/config` (on personal computer): Host jumphost Hostname jumphost.example.com Host finalhost User <user> Hostname finalhost.example.com ProxyJump jumphost # Just type [personal computer] ssh finalhost
Tip: if a host shows anoying banner on logging, suppress it by:
$ ssh -o LogLevel=error <user>@<host> # the option can also specified in ~/.ssh/config in general LogLevel error # the option can also specified in ~/.ssh/config per host Host finalhost LogLevel error
Shell
OS |
Application |
Download |
Linux |
ssh |
built in |
Windows |
Putty |
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html |
MacOS X |
ssh |
built in |
Examples for console on Unix(-oid) systems (Linux, OSX, ...):
- Copy the desktop from your math account to the local computer:
scp -r login@ssh.math.uzh.ch:Desktop .
(replace login with your user name)
Copy files from baxter (compute) to your local computer outside the institute. This cannot be done directly, but using an SSH tunnel:
PORT=1234 BAXTER=192.168.133.16 LOGIN=login ssh -f $LOGIN@ssh.math.uzh.ch -L $PORT:$BAXTER:22 -N rsync --partial --progress --exclude=.svn -auvz -e "ssh -p $PORT" $LOGIN@localhost:/export/user/login/data . CMD="ps -eo pid,args | grep 'ssh -f $LOGIN@ssh.math.uzh.ch -L $PORT:$BAXTER:22' | grep -v 'grep' | cut -c1-6" PID=`eval $CMD` kill -9 $PID echo `eval $CMD`
Here, PORT specifies the port number on your system used for the SSH tunnel (any random number larger than 1024 and less than 65535 should do, if not used by another program), BAXTER is the IP address of baxter, LOGIN your math account name, /export/user/login/data is the source directory, . the destination directory. The last four lines kill the SSH tunnel. The option --partial to rsync ensures that if the transfer breaks, you can continue it later.
Working with SSH Keys
SSH Keys are used for authentication to a remote system. Having SSH keys will relieve you from typing in your password every time you log in to a remote system if properly set up.
Quick Start
- Log in to a Terminal at the Institute.
- Type in
ssh-keygen -t rsa -b 2048
ssh-keygen will ask some questions. Just press ENTER. This will create a Private/Public key pair without passphrase.
- Still in the terminal, type in
cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keys
andchmod 600 $HOME/.ssh/authorized_keys
Now, you are able to log in to host you are granted ssh access without providing a password. For more information, read the sections below.
Private/Public Key Creation
On Unix systems, the command ssh-keygen is used to create the Private/Public key pair, as shown in the example below
$ ssh-keygen -t rsa -b 2048 Generating public/private rsa key pair. Enter file in which to save the key (/home/<USER>/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/<USER>/.ssh/id_rsa. Your public key has been saved in /home/<USER>/.ssh/id_rsa.pub. The key fingerprint is: ae:73:55:6a:22:68:2e:1e:10:df:e6:a3:5d:57:07:2a <USER>@<HOST> $
The output may differ, depending on the system you invoke the command. The example will create a RSA private/public key (-t rsa) with 2048 bits (-b 2048).
When asked for the file in which to save the key, it is usually safe to go with the default, i.e. just pressing the ENTER key.
When asked for the passphrase, you have two choices:
- just pressing the ENTER key, hence not setting any passphrase, which in turn will leave your private key unprotected
- entering a pass phrase and thus encrypting the private key (see below for a discussion of the pros and cons of setting a pass phrase)
After You need to create the private/public key pair only once.
Using the Private/Public Key Pair for Authentication
After creating the key pair, you have to set up your account to make use of them. This is straight forward by adding your public key you created previously to the .ssh/authorized_keys file, e.g.
$ cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keys
You have to make sure this file has the proper permissions, else ssh refuses to authenticate using the private/public key mechanism. Therefore, do
$ chmod 600 $HOME/.ssh/authorized_keys
Now, you are able to login to any system you are granted access without having to type in your password when using SSH. This is especially true if you did not set a pass phrase.
If you have set a passphrase, a dialog will pop up asking you for the pass phrase. You have to enter it only once, and it will be remembered for the duration of your session, thus any further ssh connections will work without the need to enter a pass phrase.
Using Private/Public Key Authentication from Outside IMATH
The above is all good and fine if you are using one of the Terminals at IMATH. If you want to access the IT infrastructure of IMATH from the outside using SSH, follow those steps
- Create a SSH private/public key pair as described above for your private account (not your IMATH account).
Copy the public key to your IMATH account for example by using scp.
- Log in to the IMATH IT infrastructure and type on in a terminal
cat <publickey> >> $HOME/.ssh/authorized_keys
Where <publickey> is the file name of the public key you copied in step 2.
Why using a Passphrase?
The passphrase is used to encrypt and decrypt your private key. If somehow someone else gets possession of your private key, they will not be able to use it unless they also know the passphrase.
In case the private key is not protected by a passphrase, and the private key gets 'stolen', the thief is able to use the private key in order to log in on any computer you can, with your credentials.
So, the bottom line is to use a strong passphrase (>15 characters) to protect the private key. The security benefit outweighs the discomfort caused by the need to provide the passphrase the first time only the key is used.
ssh-agent
To use a passphrase, stored and offered via keyring:
- Keyring should be opened: this happens typically shortly after login if the first application tries to access the keyring.
Typically a gnome-keyring-daemon and a ssh-agent is running per user:
$ ps -ef | grep keyring crose 632315 1 0 Feb09 ? 00:00:00 /usr/bin/gnome-keyring-daemon --start --components=pkcs11 crose 642701 632315 0 Feb09 ? 00:00:00 /usr/bin/ssh-agent -D -a /run/user/10688/keyring/.ssh
- The bourne shell should have the SSH_AUTH_SOCK variable set, to inherit expecially to all child shells.
declare -x SSH_AUTH_SOCK="/run/user/10688/keyring/ssh"
Normally a Gnome/Cinnamon session starts during login the gnome-keyring process.
Manually set for current terminal https://www.commithub.com/add-your-ssh-key-to-the-ssh-agent/
$ eval "$(ssh-agent -s)" $ ssh-add ~/.ssh/<private_key_file>
keychain: remote connection using ssh-agent
a) [alice@home] > b) bob@ssh.math.uzh.ch > c) charly@compute.math.uzh.ch
In case a remote login via ssh is done (a) and on the target host (b) the local keys should be used, an ssh-agent has to be started on the target host (b) and has to be supplied with the private key.
[alice@home] $ ssh bob@ssh.math.uzh.ch [bob@ssh.math.uzh.ch] $ eval `keychain --eval` $ ssh-add ~/.ssh/id_rsa ... $ ssh charly@compute.math.uzh.ch
Problems
no connection/ timeout
The SSH Server is protected with an IP blacklist.
An IP address will show up on the blacklist, if more than 3 logins (with an unknown user id) or 5 logins (with a known user id and a bad password) will occur during 5 days.
A successful login will reset the counter.
If you think your IP address has been blocked (indication: no password prompt appears), you can free your IP address:
http://www.math.uzh.ch/my > SSH > Open