monlife: SSH
LightBlog

Hot

Post Top Ad

Showing posts with label SSH. Show all posts
Showing posts with label SSH. Show all posts

Tuesday, 24 October 2017

SSH DOWNLOAD

October 24, 2017 0

This page lists multiple options for downloading an SSH client or server to your system.
SSH is a multi-purpose protocol for secure system administration and file transfers. It is included in every Linux and Unix system.

Contents

WINDOWS SSH CLIENT ALTERNATIVES

The following clients are widely used:

MAC SSH CLIENT ALTERNATIVES

FREE SSH SERVERS

Most Linux systems come with open source OpenSSH preinstalled.

ENTERPRISE CLIENT - TECTIA SSH CLIENT

Tectia SSH client is used by many enterprises for system administration and for running legacy text-based applications. It is the leading commercially supported SSH Windows Client on the market.
We provide our Tectia SSH customers technical support services on three different service levels. For more information of available support services, see our support pages.

ENTERPRISE SERVER - TECTIA SSH SERVER (WINDOWS, LINUX, UNIX, ZOS)

For business-critical applications, we recommend Tectia SSH. It is available for Windows, Unix, Linux, and IBM mainframes. It supports standards-compliant X.509 PKI, and smartcard authentication, including PIV and CAC cards and DoD PKI.
Tectia SSH shares no code base with the open source version, and it supports key managementon all platforms. For premium customers we offer 24x7 support.
Read More
vào lúc No comments:
Nhãn:

AUTHORIZED_KEYS FILE IN SSH

October 24, 2017 0

The authorized_keys file in SSH specifies the SSH keys that can be used for logging into the user account for which the file is configured. It is a highly important configuration file, as it configures permanent access using SSH keys and needs proper management.
The default configuration in most SSH implementations allows users to deploy new authorized keys for themselves and anyone they like. Such access is permanent, and may bypass privileged access management systems.
Self-provisioning is anathema to identity and access management and having a controlled access provisioning and termination process, as required by most cybersecurity laws and regulations.
When organizations deploy a formal process for managing access using SSH keys, one of the first steps is usually lock-down, basically moving the authorized_keys files to root-owned locations, which prevents self-provisioning for normal users.


Contents

CONFIGURING AUTHORIZED_KEYS

How to configure authorized keys depends on the SSH implementation.
Tectia SSH comes with support service that frequently helps customers in SSH key management. OpenSSH offers no support services.

AUTOMATING MANAGEMENT OF AUTHORIZED KEYS

Managing authorized_keys files manually is costly and error-prone. We had a customer with a 15-person dedicated team for manually installing SSH keys. Another customer estimated having 200 system administrators who spend 10% of their time setting up SSH keys. Automating the process can save a lot of money and eliminate outages due to human errors.
Furthermore, SSH keys grant access and having that access under control is required by laws and regulations such as HIPAA for the health care industry, Sarbanes-Oxley for all US public companies, PCI DSS for credit card processing, and FISMA/NIST SP 800-53 for US federal government agencies. It is also included in the US Cybersecurity Framework for critical infrastructure companies.

General information on managing SSH keys can be found on the SSH key management page.

TECTIA SSH AUTHORIZATIONS FILE

authorized_keys / authorizations file in Tectia SSH

TECTIA SSH AUTHORIZED_KEYS FILE

authorized_keys file in OpenSSH
Read More
vào lúc No comments:
Nhãn:

SSH-COPY-ID

October 24, 2017 0

ssh-copy-id installs an SSH key on a server as an authorized key. Its purpose is to provision access without requiring a password for each login. This facilitates automated, passwordless logins and single sign-on using the SSH protocol.
The ssh-copy-id tool is part of OpenSSH.

Contents

SETTING UP PUBLIC KEY AUTHENTICATION

Key based authentication in SSH is called public key authentication. The purpose of ssh-copy-id is to make setting up public key authentication easier. The process is as follows.

GENERATE AN SSH KEY

With OpenSSH, an SSH key is created using ssh-keygen. In the simplest form, just run ssh-keygen and answer the questions. The following example illustates this.
# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ylo/.ssh/id_rsa): mykey
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in mykey.
Your public key has been saved in mykey.pub.
The key fingerprint is:
SHA256:GKW7yzA1J1qkr1Cr9MhUwAbHbF2NrIPEgZXeOUOz3Us ylo@klar
The key's randomart image is:
+---[RSA 2048]----+
|.*++ o.o.        |
|.+B + oo.        |
| +++ *+.         |
| .o.Oo.+E        |
|    ++B.S.       |
|   o * =.        |
|  + = o          |
| + = = .         |
|  + o o          |
+----[SHA256]-----+
#
Creating a key pair (public key and private key) only takes a minute. The key files are usually stored in the ~/.ssh directory.

COPY THE KEY TO A SERVER

Once an SSH key has been created, the ssh-copy-id command can be used to install it as an authorized key on the server. Once the key has been authorized for SSH, it grants access to the server without a password.
Use a command like the following to copy SSH key:
ssh-copy-id -i ~/.ssh/mykey user@host
This logs into the server host, and copies keys to the server, and configures them to grant access by adding them to the authorized_keys file. The copying may ask for a password or other authentication for the server.
Only the public key is copied to the server. The private key should never be copied to another machine.

TEST THE NEW KEY

Once the key has been copied, it is best to test it:
ssh -i ~/.ssh/mykey user@host
The login should now complete without asking for a password. Note, however, that the command might ask for the passphrase you specified for the key.

TROUBLESHOOTING

There are a number of reasons why the test might fail:
  • The server might not be configured to accept public key authentication. Make sure /etc/ssh/sshd_config on the server contains PubkeyAuthentication yes. Remember to restart the sshd process on the server.
  • If trying to login as root, the server might not be configured to allow root logins. Make sure /etc/sshd_config includes PermitRootLogin yes, PermitRootLogin prohibit-password, or without-password. If it is set to forced-commands-only, the key must be manually configured to use a forced command (see command= option in ~/.ssh/authorized_keys.
  • Make sure the client allows public key authentication. Check that /etc/ssh/config includes PubkeyAuthentication yes.
  • Try adding -v option to the ssh command used for the test. Read the output to see what it says about whether the key is tried and what authentication methods the server is willing to accept.
  • OpenSSH only allows a maximum of five keys to be tried authomatically. If you have more keys, you must specify which key to use using the -i option to ssh.

HOW SSH-COPY-ID WORKS

ssh-copy-id uses the SSH protocol to connect to the target host and upload the SSH user key. The command edits the authorized_keys file on the server. It creates the .ssh directory if it doesn't exist. It creates the authorized keys file if it doesn't exist. Effectively, ssh key copied to server.
It also checks if the key already exists on the server. Unless the -f option is given, each key is only added to the authorized keys file once.
It further ensures that the key files have appropriate permissions. Generally, the user's home directory or any file or directory containing keys files should not be writable by anyone else. Otherwise someone else could add new authorized keys for the user and gain access. Private key files should not be readable by anyone else.

SOME BEST PRACTICES FOR SSH KEYS

SSH keys are very useful, but can lead to problems if they are not properly managed. They are access credentials just like user names and passwords. If they are not properly removed when people leave or systems are decommissioned, no-one may any longer know who really has access to which systems and data. Many large organizations have ended up having millions of SSH keys.

USE A PASSPHRASE WHEN POSSIBLE

It is recommended that keys used for single sign-on have a passphrase to prevent use of the key if it is stolen or inadvertatly leaked. The ssh-agent and ssh-add programs can be used to avoid having to enter the passphrase every time the key is used.
Generally all keys used for interactive access should have a passphrase. Keys without a passphrase are useful for fully automated processes. They allow shell scripts, programs, and management tools to log into servers unattended. This is often used for backups and data transfers between information systems.

ADD A COMMAND RESTRICTION WHEN POSSIBLE

The copy-id tool does not automatically add command restrictions to keys. Using command restrictions is highly recommended when the key is used for automating operations, such as running a report for fetching some files. A command restriction is basically a command="<permitted command>" option added to the beginning of the line in the server's authorized_keysfile.

MANAGING SSH KEYS

Anyone having more than a few dozen servers is strongly recommended to manage SSH keys. Not managing the keys exposes the organization to substantial risks, including loss of confidentiality, insertion of fraudulent transactions, and outright destruction of systems.
The copy-id tool can be dangerous. It can easily accidentally install multiple keys or unintended keys as authorized. The logic for choosing which key to install is convoluted. Extra authorized keys grant permanent access. They can later be used to spread attacks host-to-host, and the more keys there are, the higher the risk. It also violates all regulatory compliance requirements.
The Universal SSH Key Manager is a widely used product for managing SSH keys.

COMMAND-LINE OPTIONS

The sample below presents ssh-copy-id command line syntax:
ssh-copy-id [-f] [-n] [-i identity file] [-p port] [-o ssh_option] [user@]hostname
The options have the following meaning:
-f Don't check if the key is already configured as an authorized key on the server. Just add it. This can result in multiple copies of the key in authorized_keys files.
-i Specifies the identity file that is to be copied (default is ~/.ssh/id_rsa). If this option is not provided, this adds all keys listed by ssh-add -L. Note: it can be multiple keys and adding extra authorized keys can easily happen accidentally! If ssh-add -L returns no keys, then the most recently modified key matching ~/.ssh/id*.pub, excluding those matching ~/.ssh/*-cert.pub, will be used.
-n Just print the key(s) that would be installed, without actually installing them.
-o ssh_option Pass -o ssh_option to the SSH client when making the connection. This can be used for overriding configuration settings for the client. See ssh command line options and the possible configuration options in ssh_config.
-p port Connect to the specifed SSH port on the server, instead of the default port 22.
-h or -? Print usage summary.

SSH-COPY-ID ON MAC

While MacOS includes SSH, it does not include ssh-copy-id out of the port. However, according to some sources MacOS 10.12.4 includes it, and presumably newever versions include it as well.
You can test whether your Mac has it by opening a terminal window (Finder / Go / Utilities / Terminal) and typing ssh-copy-id.
If your system does not have it, there are many ways to install ssh-copy-id Mac version.

INSTALLATION USING HOMEBREW

To install it using Homebrew, use the following command. You need to have the brew command installed.
brew install ssh-copy-id

INSTALLATION FROM MACPORTS

The following command will install it using MacPorts. You need to have the port command installed.
sudo port install openssh +ssh-copy-id

INSTALLATION USING CURL

The following command can be used to install a Mac version directly. Note that as a general rule we do not recommend piping any commands from the network to the shell, like this does. Only use this method if you fully trust the source. The advantage of this method is that it does not need any special software - curl comes preinstalled.
curl -L https://raw.githubusercontent.com/beautifulcode/ssh-copy-id-for-OSX/master/install.sh | sh
Read More
vào lúc No comments:
Nhãn:

SSH-KEYGEN - GENERATE A NEW SSH KEY

October 24, 2017 0
This page is about the OpenSSH version of `ssh-keygen`. For Tectia SSH, see here. If you wish to generate keys for PuTTY, see PuTTYgen on Windows or PuTTYgen on Linux.


Contents

WHAT IS SSH-KEYGEN?


Ssh-keygen is a tool for creating new authentication key pairs for SSH. Such key pairs are used for automating logins, single sign-on, and for authenticating hosts.

SSH KEYS AND PUBLIC KEY AUTHENTICATION

The SSH protocol uses public key cryptography for authenticating hosts and users. The authentication keys, called SSH keys, are created using the keygenprogram.
SSH introduced public key authentication as a more secure alternative to the older .rhostsauthentication. It improved security by avoiding the need to have password stored in files, and eliminated the possibility of a compromised server stealing the user's password.
However, SSH keys are authentication credentials just like passwords. Thus, they must be managed somewhat analogously to user names and passwords. They should have a proper termination process so that keys are removed when no longer needed.

CREATING AN SSH KEY PAIR FOR USER AUTHENTICATION

The simplest way to generate a key pair is to run ssh-keygen without arguments. In this case, it will prompt for the file in which to store keys. Here's an example:
klar (11:39) ~>ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ylo/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/ylo/.ssh/id_rsa.
Your public key has been saved in /home/ylo/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Up6KjbnEV4Hgfo75YM393QdQsK3Z0aTNBz0DoirrW+c ylo@klar
The key's randomart image is:
+---[RSA 2048]----+
|    .      ..oo..|
|   . . .  . .o.X.|
|    . . o.  ..+ B|
|   .   o.o  .+ ..|
|    ..o.S   o..  |
|   . %o=      .  |
|    @.B...     . |
|   o.=. o. . .  .|
|    .oo  E. . .. |
+----[SHA256]-----+
klar (11:40) ~>
First, the tool asked where to save the file. SSH keys for user authentication are usually stored in the user's .ssh directory under the home directory. However, in enterprise environments, the location is often different. The default key file name depends on the algorithm, in this case id_rsawhen using the default RSA algorithm. It could also be, for example, id_dsa or id_ecdsa.
Then it asks to enter a passphrase. The passphrase is used for encrypting the key, so that it cannot be used even if someone obtains the private key file. The passphrase should be cryptographically strong. Our online random password generator is one possible tool for generating strong passphrases.

CHOOSING AN ALGORITHM AND KEY SIZE

SSH supports several public key algorithms for authentication keys. These include:
  • rsa - an old algorithm based on the difficulty of factoring large numbers. A key size of at least 2048 bits is recommended for RSA; 4096 bits is better. RSA is getting old and significant advances are being made in factoring. Choosing a different algorithm may be advisable. It is quite possible the RSA algorithm will become practically breakable in the foreseeable future. All SSH clients support this algorithm.
  • dsa - an old US government Digital Signature Algorithm. It is based on the difficulty of computing discrete logarithms. A key size of 1024 would normally be used with it. DSA in its original form is no longer recommended.
  • ecdsa - a new Digital Signature Algorithm standarized by the US government, using elliptic curves. This is probably a good algorithm for current applications. Only three key sizes are supported: 256, 384, and 521 (sic!) bits. We would recommend always using it with 521 bits, since the keys are still small and probably more secure than the smaller keys (even though they should be safe as well). Most SSH clients now support this algorithm.
  • ed25519 - this is a new algorithm added in OpenSSH. Support for it in clients is not yet universal. Thus its use in general purpose applications may not yet be advisable.
The algorithm is selected using the -t option and key size using the -b option. The following commands illustrate:
ssh-keygen -t rsa -b 4096
ssh-keygen -t dsa
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519

SPECIFYING THE FILE NAME

Normally, the tool prompts for the file in which to store the key. However, it can also be specified on the command line using the -f <filename> option.
ssh-keygen -f ~/tatu-key-ecdsa -t ecdsa -b 521

COPYING THE PUBLIC KEY TO THE SERVER

To use public key authentication, the public key must be copied to a server and installed in an authorized_keys file. This can be conveniently done using the ssh-copy-id tool. Like this:
ssh-copy-id -i ~/.ssh/tatu-key-ecdsa user@host
Once the public key has been configured on the server, the server will allow any connecting user that has the private key to log in. During the login process, the client proves possession of the private key by digitally signing the key exchange.

ADDING THE KEY TO SSH AGENT

ssh-agent is a program that can hold a user's private key, so that the private key passphrase only needs to be supplied once. A connection to the agent can also be forwarded when logging into a server, allowing SSH commands on the server to use the agent running on the user's desktop.
For more information on using and configuring the SSH agent, see the ssh-agent page.

CREATING HOST KEYS

The tool is also used for creating host authentication keys. Host keys are stored in the /etc/ssh/directory.
Host keys are just ordinary SSH key pairs. Each host can have one host key for each algorithm. The host keys are almost always stored in the following files:
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
The host keys are usually automatically generated when an SSH server is installed. They can be regenerated at any time. However, if host keys are changed, clients may warn about changed keys. Changed keys are also reported when someone tries to perform a man-in-the-middle attack. Thus it is not advisable to train your users to blindly accept them. Changing the keys is thus either best done using an SSH key management tool that also changes them on clients, or using certificates.

USING X.509 CERTIFICATES FOR HOST AUTHENTICATION

OpenSSH does not support X.509 certificates. Tectia SSH does support them. X.509 certificates are widely used in larger organizations for making it easy to change host keys on a period basis while avoiding unnecessary warnings from clients. They also allow using strict host key checking, which means that the clients will outright refuse a connection if the host key has changed.

USING OPENSSH'S PROPRIETARY CERTIFICATES

OpenSSH has its own proprietary certificate format, which can be used for signing host certificates or user certificates. For user authentication, the lack of highly secure certificate authorities combined with the inability to audit who can access a server by inspecting the server makes us recommend against using OpenSSH certificates for user authentication.

However, OpenSSH certificates can be very useful for server authentication and can achieve similar benefits as the standard X.509 certificates. However, they need their own infrastructure for certificate issuance. See more information on certificate authentication.

KEY MANAGEMENT REQUIRES ATTENTION

It is easy to create and configure new SSH keys. In the default configuration, OpenSSH allows any user to configure new keys. The keys are permanent access credentials that remain valid even after the user's account has been deleted.
In organizations with more than a few dozen users, SSH keys easily accumulate on servers and service accounts over the years. We have seen enterprises with several million keys granting access to their production servers. It only takes one leaked, stolen, or misconfigured key to gain access.
In any larger organization, use of SSH key management solutions is almost necessary. SSH keys should also be moved to root-owned locations with proper provisioning and termination processes. For more information, see how to manage SSH keys. A widely used SSH key management tool for OpenSSH is Universal SSH Key Manager.
Practically all cybersecurity regulatory frameworks require managing who can access what. SSH keys grant access, and fall under this requirement. This, organizations under compliance mandates are required to implement proper management processes for the keys. NIST IR 7966 is a good starting point.

MAKE SURE THERE IS ENOUGH RANDOMNESS

It is important to ensure there is enough unpredictable entropy in the system when SSH keys are generated. There have been incidents when thousands of devices on the Internet have shared the same host key when they were improperly configured to generate the key without proper randomness.

GENERAL PURPOSE SYSTEMS

On general purpose computers, randomness for SSH key generation is usually not a problem. It may be something of an issue when initially installing the SSH server and generating host keys, and only people building new Linux distributions or SSH installation packages generally need to worry about it.
Our recommendation is to collect randomness during the whole installation of the operating system, save that randomness in a random seed file. Then boot the system, collect some more randomness during the boot, mix in the saved randomness from the seed file, and only then generate the host keys. This maximizes the use of the available randomness. And make sure the random seed file is periodically updated, in particular make sure that it is updated after generating the SSH host keys.
Many modern general-purpose CPUs also have hardware random number generators. This helps a lot with this problem. The best practice is to collect some entropy in other ways, still keep it in a random seed file, and mix in some entropy from the hardware random number generator. This way, even if one of them is compromised somehow, the other source of randomness should keep the keys secure.

EMBEDDED DEVICES AND INTERNET OF THINGS

Available entropy can be a real problem on small IoT devices that don't have much other activity on the system. They may just not have the mechanical randomness from disk drive mechanical movement timings, user-caused interrupts, or network traffic. Furthermore, embedded devices often run on low-end processors that may now have a hardware random number generator.
The availability of entropy is also critically important when such devices generate keys for HTTPS.
Our recommendation is that such devices should have a hardware random number generator. If the CPU does not have one, it should be built onto the motherboard. The cost is rather small.

COMMAND AND OPTION SUMMARY

Here's a summary of commonly used options to the keygen tool:
-b “Bits”
This option specifies the number of bits in the key. The regulations that govern the use case for SSH may require a specific key length to be used. In general, 2048 bits is considered to be sufficient for RSA keys.
-e “Export”
This option allows reformatting of existing keys between the OpenSSH key file format and the format documented in RFC 4716, “SSH Public Key File Format”.
-p “Change the passphrase” This option allows changing the passphrase of a private key file with [-P old_passphrase] and [-N new_passphrase], [-f keyfile].
-t “Type” This option specifies the type of key to be created. Commonly used values are: - rsa for RSA keys - dsa for DSA keys - ecdsa for elliptic curve DSA keys
-i Input When ssh-keygen is required to access an existing key, this option designates the file.
-f File Specifies name of the file in which to store the created key.
-N New Provides a new passphrase for the key.
-P Passphrase Provides the (old) passphrase when reading a key.
-c Comment Changes the comment for a keyfile.
-p Change the passphrase of a private key file.
-q Silence ssh-keygen.
-v Verbose mode.
-l Fingerprint Print the fingerprint of the specified public key.
-B Bubble babble Shows a bubble babble (Tectia format) fingerprint of a keyfile.
-F Search for a specified hostname in a known_hosts file.
-R Remove all keys belonging to a hostname from a known_hosts file.
-y Read a private OpenSSH format file and print an OpenSSH public key to stdout.
This only listed the most commonly used options. For full usage, including the more exotic and special-purpose options, use the man ssh-keygen command.
Generating an SSH key with ssh-keygen
Read More
vào lúc No comments:
Nhãn:

Post Top Ad

Author Details