SSH

From CSLabsWiki
Jump to: navigation, search

The Secure Shell protocol is a widely implemented protocol for securely connecting to remote systems. The advice here is largely based on [1].

Using the ssh client

ssh is usually pretty easy to use, but for use in COSI you'll need to go through the extra step of generating a keypair. This is used for authenticating with remote servers without having to hand over a password all the time. You'll need to use ssh-keygen -t ed25519 -o -a 100 for your key to be accepted by COSI infrastructure. Here's an example:

[cmr@cosi-03]~% ssh-keygen -t ed25519 -o -a 100
Generating public/private ed25519 key pair.
Enter file in which to save the key (/mnt/home/cmr/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /mnt/home/cmr/.ssh/id_ed25519.
Your public key has been saved in /mnt/home/cmr/.ssh/id_ed25519.pub.
The key fingerprint is:
10:9c:20:9d:70:c1:f1:a7:19:ef:20:99:c8:12:9a:46 cmr@cosi-03.cslabs.clarkson.edu
The key's randomart image is:
+--[ED25519  256--+
|  o+=*..         |
|   o+.o.         |
|.E    + .        |
|o+ . o B         |
|+.o + + S        |
|..   . o         |
|        .        |
|                 |
|                 |
+-----------------+

You'll want to keep your private key (id_ed25519) very well protected, as it can be used to impersonate you. The entire world can know your public key (id_ed25519.pub). It's recommended that you use a passphrase with your key. To avoid having to type your key's passphrase frequently, you can use ssh-agent.

From there, you can ssh to any server you have an account on with a simple ssh servername.cslabs.clarkson.edu, once you have appended the contents of id_ed25519.pub to ~/.ssh/authorized_keys.

Configuring an ssh server

For COSI's needs, the following sshd_config should be used:

Port 13699

# Crypto. DO NOT CHANGE THESE WITHOUT CONSULTING RUST OR A
# PROFESSIONAL CRYPTOGRAPHER.

Protocol 2
# Use only a SafeCurve(TM) endorsed by djb and other leading cryptographers.
KexAlgorithms curve25519-sha256@libssh.org
# Use a secure, simple timing-attack free cipher with AEAD (chacha20-poly1305) by default.
# We allow aes256-gcm (also AEAD) for compatability.
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
# Strongest MAC as of 2015-06-11.
MACs hmac-sha2-512-etm@openssh.com
HostKey /etc/ssh/ssh_host_ed25519_key


# "sandbox", beyond just "yes", will try to sandbox the pre-authenticated
# child beyond just changing privileges. The current implementation
# on Linux is rather weak, but it's better than nothing and will
# presumably continue improving.
UsePrivilegeSeparation sandbox

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

# Possibly enable this for Kerberos
# ChallengeResponseAuthentication yes

# Allow only pubkey authentication.
PasswordAuthentication no

PrintLastLog yes
TCPKeepAlive yes

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# Enable sftp.
Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

# Only allow users we expect to ssh in, to ssh in.
AllowGroups ssh-user