Create ssh private and public key, no passphrase, pem format:
$ssh-keygen -P "" -m PEM -f key_name
Other ssh private/public key generation:
$ssh-keygen -t rsa -b 4096 -P "" -C "email@example.com" -m PEM -f file_name
# start the ssh-agent in the background and add new created private key to the ssh-agent
$eval "$(ssh-agent -s)" && ssh-add ~/.ssh/path/to/private_key_file_name
#upload public key to GitHub or BitBucket and test connection:
$ssh -vT git@github.com
$ssh -Tvvv git@bitbucket.org
#store your credentials so that vscode does not always ask for them
$git config --global credential.helper manager
#disable certificate verification if you get a "fatal: unable to access" error
$git config --global http.sslVerify false
#if the Security Warning bothers you then enable the certificate verification
$git config --global http.sslVerify false
$git config --global http.sslCAInfo "C:/path/to/your/corporate-root-ca.crt"
Copy local created key to remote server:
$ssh-copy-id username@remoteIPaddress
Configure ssh configuration file
- not allow root login (make sure you created a new user and added to sudo group first)
- Disable PasswordAuthentication
$sudo nano /etc/ssh/sshd_config
Create a file onto local machine .ssh/ folder named 'config' and set an 'alias' for your ssh long command so that next time when you ssh into your server you don't have to type the whole command but just the alias. The new created config file template looks like this:
Host aliasSomethingServerName
User ctuser
Port 22
IdentityFile ~/.ssh/id_rsa
HostName IPaddressOfTheRemoteServer
If you don't want to see the initial information when you first ssh to your remote server then on the remote machine terminal type:
$touch .hushlogin
Server authentication
One of the first things that happens when the SSH connection is being established is that the server sends its public key to the client, and proves (thanks to public-key cryptography) to the client that it knows the associated private key. This authenticates the server: if this part of the protocol is successful, the client knows that the server is who it claims it is.
The client may check that the server is a known one, and not some rogue server trying to pass off as the right one. SSH provides only a simple mechanism to verify the server's legitimacy: it remembers servers you've already connected to, in the ~/.ssh/known_hosts file on the client machine (there's also a system-wide file /etc/ssh/known_hosts). The first time you connect to a server, you need to check by some other means that the public key presented by the server is really the public key of the server you wanted to connect to. If you have the public key of the server you're about to connect to, you can add it to ~/.ssh/known_hosts on the client manually.
By the way, known_hosts can contain any type of public key supported by the SSH implementation, not just DSA (also RSA and ECDSA).
Authenticating the server has to be done before you send any confidential data to it. In particular, if the user authentication involves a password, the password must not be sent to an unauthenticated server.
User authentication
The server only lets a remote user log in if that user can prove that they have the right to access that account. Depending on the server's configuration and the user's choice, the user may present one of several forms of credentials (the list below is not exhaustive).
• The user may present the password for the account that he is trying to log into; the server then verifies that the password is correct.
• The user may present a public key and prove that he possesses the private key associated with that public key. This is exactly the same method that is used to authenticate the server, but now the user is trying to prove its identity and the server is verifying it. The login attempt is accepted if the user proves that he knows the private key and the public key is in the account's authorization list (~/.ssh/authorized_keys on the server).
• Another type of method involves delegating part of the work of authenticating the user to the client machine. This happens in controlled environments such as enterprises, when many machines share the same accounts. The server authenticates the client machine by the same mechanism that is used the other way round, then relies on the client to authenticate the user.
Retrieve public key from private key
Method 1:
For a new created user:
You'll have to generate a private key on AWS console Key Pairs then generate public key out of private key:
ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub
https://askubuntu.com/questions/53553/how-do-i-retrieve-the-public-key-from-a-ssh-private-key
Method 2:
$ssh-keygen -y -f /path_to_key_pair/my-key-pair.pem
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#retrieving-the-public-key
Retrieve public key from sftp server and append it to known_hosts file
$ssh-keyscan vault.dcbank.ca >> ~/.ssh/known_hosts