Основы SSH-ключа и пароля без пароля для разработчиков

Ключи SSH полезны для входа через  ssh (безопасная оболочка)  без ввода пароля. Они также используются Github и другими системами контроля версий для аутентификации без пароля. Вот некоторая основная информация с точки зрения разработчика программного обеспечения, как использовать ключи SSH для максимального комфорта и безопасности.

Эти инструкции применимы для OSX и Linux (протестировано в Ubuntu).

Ключи SSH используются не только сеансами оболочки, но и аутентификацией системы контроля версий с удаленным копированием файлов ( rsync , scp) (Git, Subversion).

1. Создание вашего первого ключа

Ключи SSH создаются с помощью команды ssh-keygen .

Вы должны (действительно должны!) Добавить пароль на ваш ключ, когда вас попросят. Вам не нужно вводить это, но это не позволяет кому-либо использовать ваши ключи из холодного хранилища, такого как украденный жесткий диск. Ниже приведена дополнительная информация о том, как ключи SSH интегрированы в вашу учетную запись настольного компьютера, чтобы избежать ввода парольной фразы.

2. Хранение паролей сервера (UNIX)

При первом входе в систему на новом сервере измените пароль UNIX / SSH на случайный, используя   команду passwd . Вам понадобится этот пароль для sudoing, но не для входа в систему. Вы можете использовать программное обеспечение, такое как  KeePassX (OSX, Linux, Windows, Android и др.),  Чтобы создавать и управлять паролями для вас в зашифрованном файле, а затем синхронизировать файл с Dropbox для резервного копирования.

3. Файл закрытого и открытого ключа

SSH keys consist of two parts. You have SSH private keys only on your personal computer. You place the public key file on a remote server, in a home directory in plain-text file ~/.ssh/authorized_keys. In this file, one line represents one allowed public key for this user to login.

You can add the keys to this file by hand editing the file or using ssh-copy-id command (Ubuntu has it by default, download for OSX).

Example of login on the server with password for a test, placing a key (github-pkunk is the private key file name) on the server (you need to create it first using ssh-keygen) and then doing a passwordless login:

4. Managing and using keys with passphrases

You can have multiple keys. For example I have one for Github and one for corporate servers.

After each local computer boot you add the private keys to your running SSH agent (a local daemon application) using command ssh-add .ssh/my-private-key-name This will ask you to type the passphrase of the key.

After this you can login to any server where you have placed the corresponding public key without a password.

You can add / change passphrases to they private keys like this:

  [moo@Kohr-Ah][23:23]
[~/.ssh]% ssh-keygen -p -f github-pkunk
Key has comment 'github-pkunk'
Enter new passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved with the new passphrase.

(More info)

5. Desktop and login integration

On OSX, adding keys to the SSH agent can done automatically by OSX Keychain on login. OSX Keychain stores the passphrase of the key on an encrypted storage unlocked by your login on the computer. The default key ~/.ssh/id_rsa is added automatically by OS, but you can add more keys to Keychain like this:

[~/.ssh]% ssh-add -K github-pkunk
Enter passphrase for github-pkunk: 
Passphrase stored in keychain: github-pkunk
Identity added: github-pkunk (github-pkunk)

The latest Ubuntu / Gnome keyring seems to be able to do this also, but I am not sure about the details whether the process is the same.

(More info)

6. SSH agenting and passwordless git and svn

Never copy your private key anywhere else besides 1) your own computer 2) back-up. You should never place your private key on a server controlled by a third party. If you need to access SSH keys on a remote server, for example when you need to do a git pull from Github, use SSH agent forwarding option.

SSH agent forwarding allows the remote server shell session to use keys from your local computer. It is enabled with ssh -A command line switch or in an option in the configuration file (see below). When enabled, all keys registered with ssh-add will be available on the remote server.

Subversion supports SSH. This means that, when enabled, you can do svn up on a remote server without need to give or store your SVN password on the server. Thesvn+ssh protocol support for Subversion must be enabled and it may not provide per-user repository access control, as oppose to https protocol with Apache.

7. Online compression of the SSH traffic

Enable compression when working with servers far-away with low bandwidth. See below how to enable this in the ~/.ssh/config file.

This will somewhat increase the speed of long command output like ls.

8. Configuration files

Store the servers you access often in .ssh/config file. You can store per-server options like enable agent forwarding, server alias (shorter to type) and  default username. Here is an example snippet from my config:

Host xapsi 
Hostname lakka.xapsi.fi
User miohtama # This is my username on the server
LocalForward 8889 localhost:8889 # Build tunner for Quassel IRC core
Compression yes # Enable compression
CompressionLevel 9
IdentityFile=/Users/moo/.ssh/foobar # Always use this key

The configuration file also enables the tab competion on some shells (zsh examples). With the above snippet in the config I could do:

ssh kap[TAB][ENTER]

Login with 6 letters – no passwords or usernames asked!

9. Tunneling

SSH key can forward TCP/IP ports between the server and your local computer. This is useful e.g. testing firewalled servers from a local computer or give a public IP / port for your local development server.

More info about SSH tunneling.

10. Freeing yourself typing password for sudo

For the state of the art UNIX system the direct root SSH account is disabled for the security reasons. Instead you ssh in as a normal user and then elevate your privileges using sudocommand.

Normally sudo is configured to ask password for every time sans sudo grace period. However if you primarily use SSH keys as your security measure it is recommended that

• You randomize and store the real UNIX passwords in an encrypted safe as described above
• You put sudo users to a specific UNIX system group (on Ubuntu this is group admin, but also wheel is used on some systems)
• Give passwordless sudo access for this group and this group only

Example how to add an account to a specific group on Ubuntu Linux:

usermod -a -G admin moo

Then you can whitelist this group in /etc/sudoers file:

%admin ALL=(ALL) NOPASSWD: ALL

The recommended safe way to edit /etc/sudoers file is visudo command. Example:

 export EDITOR=nano && sudo visudo

Please note that you MUST use only passphrase protected private keys or otherwise anyone getting access to a private key file can get root on your server.

Please note that you should give passwordless sudo only on specific users on your server. Otherwise in the case of a compromised web server (PHP anyone?) the attacker could get root access through www-data or other UNIX system account.

Please share your own tips in the blog comments.