How To Enable Verbose Mode For SSH Logins?
0 comments 12/09/2010 06:43:00 AM Posted by Surendra Kumar AnneLabels: How-To's, SSH, Troubleshooting
How we can login to remote server through ssh?
#ssh user@servername
or
#ssh -l user servername
or
#ssh ip-add
So when you will execute the above command you will get the password prompt. But if you want to see what will happen when you execute ssh command you have to enable verbose or debugging mode. To do this we have to apply -v option at the time of login as shown in below example.
#ssh -v surendra@ftp2.linuxnix.com
root@krishna:/home/surendra# ssh -v surendra_a@ftp2.linuxnix.com
OpenSSH_5.5p1 Debian-4ubuntu4, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to ftp2.linuxnix.com [92.32.56.78] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.0
debug1: match: OpenSSH_4.0 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'ftp2.linuxnix.com' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
surendra_a@ftp2.linuxnix.com's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_IN
Last login: Thu Dec 9 20:02:47 2010 from 1.23.6.79
After logout
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to ftp2.linuxnix.com closed.
Transferred: sent 2072, received 2072 bytes, in 27.7 seconds
Bytes per second: sent 74.8, received 74.8
debug1: Exit status 0
So if you want more verboseness you can use up to 3rd level(-vvv) as shown below
#ssh -vvv surendra_a@ftp2.linuxnix.com
Hardening SSH Server In The DMZ(De Militarised Zone)
0 comments 3/17/2010 04:31:00 AM Posted by Meghana M BhombhoreLabels: Security, SSH
Its good to harden your box which is in DMZ.
What is DMZ?
Ans : DMZ is a De Militarised Zone where we will be keeping our servers, so that they can be access by out side people. Let me explain more about this DMZ. Who are not familiarise(And this activity is most of the time a Network admin work).
1. DMZ is a place where we will be isolate machines from companies local LAN.
2. These DMZ machines will have different IP address range and subnet.
3. The communication between two machines in DMZ is blocked for security reasons.
4. We cannot login to Local LAN machine from a DMZ machine, but we can login to DMZ machine from local LAN(only one way communication from LAN).
5. Ping to these machines will be disabled(most of the companies will do this for security reasons).
6. The way these machines communicate totally depends on network team what type of rule they set on their routers.
7. The security of DMZ machines are more when compared to local LAN machines(in other ways every thing is restricted to DMZ machines).
8. Only required ports are opened on DMZ machines and remaining ports are in closed or reject state(This should be done on system by Linux admin and on network level done by companies network engineer).
Once you keep your Linux machine in DMZ first and far-most thing to do is to secure SSH logins to the server.
In this post we will see some security measures for SSH to be taken when system is kept in DMZ. Most of the SSH settings are located in /etc/ssh/sshd_config (Red hat/Debian based systems).
1. Set Maximum failed login attempts, so after that many login attempts connection to the server is reseted and once again we have to connect to server.
MaxAuthTries 3
Here I have set failed login attempts to 3.
2. Disable root to login through SSH. This is a good option to force the user not to use root user to login to the server
PermitRootLogin no
Here we set it to no which indicates root can not login.
3. We should disable logging of users who donot have passwords.
PermitEmptyPasswords no
4. Allow only users who have passwords.
PasswordAuthentication yes
5. Specify who should access this server. I can say this one is more secure because SSH will allow only the users who are specified here.
AllowUsers test1 test2
Here I have allowed only two users i.e. test1 and test2.
6. Set-up a login banner to give warnings to the users how are logging in to that server
Banner /etc/ssh-banner
Please specify the warning message in /etc/ssh-banner.
Once done the above changes in /etc/ssh/sshd_config file just reload the ssh server.
Note : Don't restart SSH service on production servers. Its not advisable to do it. so in-order to update your changes always use reload option. Most of the services will support reload option with service command.
#service sshd reload
Please share your experience which you feel not mentioned in this post.
How To Reduce Delay Getting SSH Login Prompt
0 comments 3/10/2010 05:46:00 PM Posted by Meghana M BhombhoreLabels: DNS Servers, How-To's, SSH
Recently we have installed a new RHEL5.4 machine. Its located just few kilometres from our office. But when I have observed at the time of logging in the shell prompt is taking considerable time to appear(though connection is taking a fraction of second, after entering the password its taking more time). So we did some tweeking and found out this is related to DNS. We have to change dns related entries in ssh config file to reduce this delay.
Note : Be careful when doing this on production servers. This activity may disconnect all the users from the system who are logged in to that machine using SSH.
By default UseDNS option in this file is disable. We have to uncommet this option and then edit this entry to no. As below..
Just search for UseDNS..
[root@tst ~]#vi /etc/ssh/sshd_config
before config
#UseDNS yes
After config
UseDNS no
save and exit the file and then just reload ssh service to take effect what ever changes we did..
#service sshd reload.
Now try to login and observe, delay will be reduced.
Please share your thoughts on this..
