1. RSA/DSA host Fingerprint
Also, note that known_hosts file sits in your home directory. Meaning that if you log into different user account, ssh will start saving remote host fingerprints from scratch.
Executing SSH command on a remote computer
# ssh root@192.168.1.67 ls it will execute ls command in remote host
keep in mind one thing. You may want to put command that you want to run on a remote computer in single quotes shell does not expand commands in single quotes.
# ssh root@192.168.1.67 'echo "Foooo" > file.txt'
In case you want to put a single quote in the actual command, this is how you can do it:
# ssh root@192.168.1.67 'echo '"'"'Foooo'"'"' > file.txt'
Secure Copying
# scp -C -r file/folder root@ctechz.blogspot.com:~/destination
2. Encryption
Once you encrypt something with one key, you can only decrypt it with its pair key. I.e. if you encrypt a message with key A, you can only decrypt it with key B. RSA and DSA thin, These are algorythms that computer use to generate keys and encrypt messages using those keys.
Public/private key
How actual encryption works
2nd step makes sure that even if villain intercepts the message, he won't be able to decrypt it because he doesn't have B's private key message was encrypted with B's public key, so to decrypt it we need B's private key.
SSH identities
In SSH, a pair of public/private keys called identity. Keys usually kept in two files. First file contains only the public key. Second file contains both public and private keys.
We send public key away so we better have it separate and ready for use. On the other hand, private key is a secret key. It is useless without public key.
To present remote application on your local X Windows server you had to run two commands with quiet complex syntax every session. X Windows server uses protocol named XDMCP. It is insecure. As a result someone who has access to your traffic could watch you browsing the internet.
To enable X forwarding automatically, you have to modify ssh configuration file /etc/ssh/ssh_config and appending ForwardX11Trusted directive. Like this:
One of the most important features of SSH protocol is security. This means obviously encrypting the data that passes between your computer and a remote computer. During its installation, OpenSSH suite creates a signature of the computer. This signature called RSA or DSA host fingerprint.
RSA and DSA are two methods of encrypting data.When you are connecting to a remote computer for the first time, its host fingerprint being saved on your machine. Actually, first ssh asks you if the signature it received from a remote computer is right. You can rely on ssh to do things right, but you can actually check and make sure that the fingerprint is right. If you have an access to a remote computer some other than via SSH, you can read its fingerprint and compare it to value ssh has given to you.
To read host fingerprint
# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
# ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub
You can use these fingerprints to make sure that you are connecting to a right computer.
What happens when host fingerprint changes
Host fingerprint can change if, for instance, someone has reinstalled the operating system on the computer. Another option is when computer's IP address has changed, but we still connect to the same IP address which is by now already taken by other computer.In any of these cases host fingerprint of the remote computer changes.
Handling host fingerprint changes
Often you do something to a remote computer that may cause its host fingerprint to change.In this case it is totally normal that ssh throws that big and scary error message on us. Yet it won't let us to connect to a remote system and we want to fix this.ssh saves host fingerprints on a local disk, in a file named /home/<username>/.ssh/known_hosts. What we want to do is to delete certain host from the file and by that cause ssh to confirm host fingerprint with us again, as if we were connecting for the first time.
To do this, we will use following command:
# ssh-keygen -R 192.168.1.1
the above command deletes localy saved remote host fingerprint from known_hosts file, but keeps a backup copy of the file (known_hosts.old) in case we need it. In case you want to restore known_hosts file, you can simply copy a backup file overwriting the original one.
# ssh-keygen -R 192.168.1.1
the above command deletes localy saved remote host fingerprint from known_hosts file, but keeps a backup copy of the file (known_hosts.old) in case we need it. In case you want to restore known_hosts file, you can simply copy a backup file overwriting the original one.
Also, note that known_hosts file sits in your home directory. Meaning that if you log into different user account, ssh will start saving remote host fingerprints from scratch.
Executing SSH command on a remote computer
# ssh root@192.168.1.67 ls it will execute ls command in remote host
keep in mind one thing. You may want to put command that you want to run on a remote computer in single quotes shell does not expand commands in single quotes.
# ssh root@192.168.1.67 'echo "Foooo" > file.txt'
In case you want to put a single quote in the actual command, this is how you can do it:
# ssh root@192.168.1.67 'echo '"'"'Foooo'"'"' > file.txt'
Secure Copying
Here is another scp command line switch that I use a lot. -C tells scp to compress the data before sending it. Depending on content of the files you are transferring, this can make scp much faster.
# scp -C -r file/folder root@ctechz.blogspot.com:~/destination
2. Encryption
Login without entering password: To make this work, we will have to create and install so called identity file. You may also heart it being referred as public/private key or certificate.
Once you encrypt something with one key, you can only decrypt it with its pair key. I.e. if you encrypt a message with key A, you can only decrypt it with key B. RSA and DSA thin, These are algorythms that computer use to generate keys and encrypt messages using those keys.
Public/private key
Remember that we need two keys to encrypt/decrypt messages. In computers, usually one of them called private key and the other called public key. This is because computer sends public key to whoever asks for it, making it publicly available. Private key, on the other hand, kept in secret.
How actual encryption works
Lets say we have two computers computer A and computer B. Each one of them has a pair of keys the public and the private key.
Secure session between them begins with key exchange. Each computer sends its public key to another computer. Then, to send private information from computer A to computer B, computer A does this:
Encrypts the message with his own private key.
Encrypts the result of step 1, with B's public key.
Secure session between them begins with key exchange. Each computer sends its public key to another computer. Then, to send private information from computer A to computer B, computer A does this:
Encrypts the message with his own private key.
Encrypts the result of step 1, with B's public key.
2nd step makes sure that even if villain intercepts the message, he won't be able to decrypt it because he doesn't have B's private key message was encrypted with B's public key, so to decrypt it we need B's private key.
SSH identities
In SSH, a pair of public/private keys called identity. Keys usually kept in two files. First file contains only the public key. Second file contains both public and private keys.
We send public key away so we better have it separate and ready for use. On the other hand, private key is a secret key. It is useless without public key.
How to generate identity files
OpenSSH suite comes with a program named ssh-keygen. It generates identity files.
# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
95:0f:15:e1:f6:65:6d:d9:8d:51:7e:83:18:d0:d6:93 root@cloudcc.ctechz.blogspot.com
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
95:0f:15:e1:f6:65:6d:d9:8d:51:7e:83:18:d0:d6:93 root@cloudcc.ctechz.blogspot.com
Once you’ve identity file installed, ssh will no longer authenticate you with a password. Instead it will use your identity files. Now if you’ve supplied a password, when ssh-keygen asked you for it, ssh will still ask you for that password.Instead it will use your identity files.Now if you’ve supplied a password, when ssh-keygen asked you for it, ssh will still ask you for that password.
Using a password when generating identity files basically gives you an option to have stronger security then regular username/password pair. This way, you’re protecting yourself with both identity files and a password.
If you’ve specified blank password, it will let you in, without asking further questions. I.e. you can use identity files to login to a remote computer, without supplying a password and if you’re using same username then even without supplying a username. Just type in ssh <hostname> and you’re in.
# ssh-copy-id
Now to the actual installation. Modern versions of OpenSSH come with nifty script called ssh-copy-id. It will copy identity file (your public key) from home directory on your current computer (/home/<user>/.ssh/id_rsa.pub), to a remote computer. Let’s see it in action.
Now to the actual installation. Modern versions of OpenSSH come with nifty script called ssh-copy-id. It will copy identity file (your public key) from home directory on your current computer (/home/<user>/.ssh/id_rsa.pub), to a remote computer. Let’s see it in action.
# ssh-copy-id root@192.168.1.67
ssh-copy-id will ask you for a password as ssh would, but once you’ve entered the password, you will no longer have to do it again (unless your identity files protected with password). Note that ssh-copy-id has some requirements. When running it, you should already have identity files under your user account. Also, your identity files shouldn’t be installed on the host you’re connecting to, for user you’re connecting with. You can install your identity files under several different user accounts on remote computer.
Now try logging into the machine, with "ssh 'root@192.168.1.67'", and check in:
~/.ssh/authorized_keys
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting. then do # ssh root@192.168.1.67 it wont ask for any password.
Installing identity files manually
First of all you have to understand that identity files located in your user’s home directory. Meaning that even if you’ve installed alex‘s identity on some remote computer, you won’t be able to login to that computer when locally you’re logged in as jeff. This is because when ssh tries to authenticate you on a remote system, it looks for identity files (private key) in your home directory.
Second, ssh saves installed identity files (public keys) under /home/<user>/.ssh/authorized_keys file. Again this is a home directory of the user account you’re trying to log into and if you try logging into different account, ssh will ignore identity files you’ve installed originally.
Identity file installation involves one simple step – copying content id_rsa.pub (or id_dsa.pub) file on local computer into authorized_keys file on remote computer.Content of identity files is usually single line of text. You should copy it as such. If you add a line break symbol in the middle, ssh will not recognize this identity.
Second, ssh saves installed identity files (public keys) under /home/<user>/.ssh/authorized_keys file. Again this is a home directory of the user account you’re trying to log into and if you try logging into different account, ssh will ignore identity files you’ve installed originally.
Identity file installation involves one simple step – copying content id_rsa.pub (or id_dsa.pub) file on local computer into authorized_keys file on remote computer.Content of identity files is usually single line of text. You should copy it as such. If you add a line break symbol in the middle, ssh will not recognize this identity.
echo .pub >> >> ~/.ssh/authorized_keys
3. Further SSH Methods --- X forwarding
X Windows server (the one that you use to have graphical user interface in Linux) allows you to present a UI for a program on a remote computer. Actually, this is the reason why it is called X server. X Windows server is a server because it gives programs a way to present their user interfaces. X Server serves programs. Actual programs on the other hand are X Windows clients. They use X Windows server to present themselves on screen.
Formerly, two programs controlled who can use your X Windows server: xauth and xhost. There are however, two problems with these two. First of all using them is inconvenient.
To present remote application on your local X Windows server you had to run two commands with quiet complex syntax every session. X Windows server uses protocol named XDMCP. It is insecure. As a result someone who has access to your traffic could watch you browsing the internet.
If you run ssh with -Y command line switch, ssh will automatically configure X Windows forwarding to your local X Windows server. This means that when you run ssh with -Y switch, every command or program that has UI, will present itself on your X Windows server computer, rather than on remote computer. No need to run xhost and xauth. ssh does this for you.
What if -Y doesn't work
Both SSH client and SSH server has an option to enable/disable -Y command line switch. if your Linux distribution has strict security settings and keeps X forwarding disabled. If this is the case, we will have to enable X forwarding.
Configuration
To allow root access, we have to tell SSH server to accept such connections. To do this, we have to modify SSH server's configuration file and tell sshd (that's the name of SSH server program) to reread it's configuration. SSH server configuration file is /etc/ssh/sshd_config. Note that to modify the file you will need root access.
Option that controls root access called PermitRootLogin. To allow root login, simply append:
PermitRootLogin yes
# /etc/init.d/sshd reload
Option that controls root access called PermitRootLogin. To allow root login, simply append:
PermitRootLogin yes
# /etc/init.d/sshd reload
X forwarding
We've seen how to enable X Windows forwarding with -Y command line switch.Another thing that you may want to do is to disable X forwarding.
To enable X forwarding automatically, you have to modify ssh configuration file /etc/ssh/ssh_config and appending ForwardX11Trusted directive. Like this:
ForwardX11Trusted yes
No need to reload anything. Once you save the file, ssh will automatically imply -Y on every new connection.
On the other hand, to prohibit clients from using -Y, we should remove X11Forwarding directive from /etc/ssh/sshd_config. OpenSSH disables this option by default, but many Linux distributors enable it. So, if X forwarding works for you, this means that there's X11Forwarding yes line somewhere in /etc/ssh/sshd_config.
On the other hand, to prohibit clients from using -Y, we should remove X11Forwarding directive from /etc/ssh/sshd_config. OpenSSH disables this option by default, but many Linux distributors enable it. So, if X forwarding works for you, this means that there's X11Forwarding yes line somewhere in /etc/ssh/sshd_config.
No comments:
Post a Comment