I have two linux boxes one is running Fedora Core 10 @ IP 10.10.10.10 with a username of XXX and the other is Fedora Core 6 @ IP 6.6.6.6 with a username of YYY.

• In both the boxes I have disabled root logins via SSH.

• I double checked both the machines /etc/allow host and deny host no entries have been made.

1. Now I can ssh from FC10 to FC6 - WORKING
   
   [root@FC10 ~]# ssh YYY@6.6.6.6 -p 21
   
   reverse mapping checking getaddrinfo for abts-tn-dynamic-6.6.6.6.broadband.in [6.6.6.6] failed - POSSIBLE BREAK-IN ATTEMPT!
   YYY@6.6.6.6's password:
   
   
   
2. When I try to do the other way around it is not working I simply don't know why.

[root@FC6 ~]# ssh XXX@10.10.10.10 -p 21
The authenticity of host '10.10.10.10 (10.10.10.10)' can't be established.
RSA key fingerprint is f9:d7:0a:a3:70:77:e6:85:19:ee:df:d0:08:fa:25:bb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.10.10.10' (RSA) to the list of known hosts.

After this the password prompt never appears.


The FC6 is running on VMware located remotely. I can ssh into the FC10 from the base machine on which FC6 is running on but not directly from the Vmware system.

Hi,

A lot of things can be wrong......

1) Are you able to ping from 10.10.10.10 to 6.6.6.6 (and the reverse)?? You need a working network connection between your box and the VMWare guest (both ways).

2) Why are you using port 21? That port is reserved for ftp, not ssh/scp (port 22 is default).

3) The error (..... POSSIBLE BREAK-IN ATTEMPT) is caused by this option UseDNS yes. It looks like 6.6.6.6 cannot be resolved to a FQDN. Either set UseDNS to no or make sure ip's and FQDN can be resolved (first option is probably the easiest).

I do believe that the network between your box and the VM guest isn't set up correctly.

Hope this gets you going again.

asdf

Kindly don't mind the asdf I just posted to see where the reply appears.

1. I cannot really test pinging because I know that very my router is going to stop those ICMP responses. However I can confirm on thing that both the system will ping because I am able to establish SSH connection from FC10 to Vmware FC6.
   
2. I have to use port no 21 just because I have a firewall which blocks 22 which I cannot change so I am hit the internet facing interface of the router on port number 21 and then routing it back to port number 22 on the LAN facing network.
   
3. Lastly I tried setting the "UseDNS no", according to your reply I need to change this option on FC 10. I did not work I tried to change it on the other system as well with tough luck.

[root@FC10 .ssh]# cat /etc/ssh/sshd_config | grep DNS
UseDNS no
[root@FC10 .ssh]#

[root@FC6 .ssh]# cat /etc/ssh/sshd_config | grep DNS
UseDNS no
[root@FC6 .ssh]#


Kindly have a look at the digram in case the phrasing of my sentenses are wrong because as my school teacher said a picture can speak thousand words :-)

Hi,
It has to work both ways, being able to go from A->B does not automatically mean that you can go from B->A.

If you have a telnet client installed try something like this (from FC6 to FC10):

telnet 10.10.10.10 21

If the output looks something like the following, you can assume a working connection:

Trying 10.10.10.10...
Connected to 10.10.10.10.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.5

Like I stated before, there could be a lot that's not configured correctly, this could be one of them.
- Are you sure this re-routing (port 21 -> 22) is set up correctly?
- Are there any ftp daemons listening on port 21 as well? You need to be sure that only ssh uses port 21 if you set it up this way.

What did not work? Do you still get the POSSIBLE BREAK-IN ATTEMPT error?
This is, at this stage, not that important. Make sure you can connect both ways using ssh/scp before fixing this 'error'.

I have to assume that the Base System you mention in your diagram is the VM Host? If so, I do miss a connection for Base -> FC6 (and reverse).

Although I cannot be 100% sure, I still believe that the network (especially the VM Guest) isn't set up correctly. Focus on that first by making sure it works (both ways!!).

1. I really appreciate you, Druuna for showing interest in solving my problem.
   
2. I am able to get both the ssh version information from A to B and B to A.
   
   • [root@FC10 ~]# telnet 6.6.6.6 21
     Trying 6.6.6.6...
     Connected to 6.6.6.6
     Escape character is '^]'.
     SSH-2.0-OpenSSH_4.3
     ^C^]
     telnet> quit
     
   • [bala@FC6 ~]$ telnet 10.10.10.10 21
     Trying 10.10.10.10...
     Connected to ABTS-AP-dynamic-10.10.10.10.broadband.in (10.10.10.10).
     Escape character is '^]'.
     SSH-2.0-OpenSSH_5.1
3. I came to know that my routing from port 21 to 22 is working fine when I tried to SSH into both these machines successfully from a third machine who's IP is 7.7.7.7
   
4. I have a base system which is running an OS and in that I have installed VMplayer and installed FC6 into the VMplayer, FC6 has a NATed IP with the base OS inorder to access the internet.

The base system IP configuration given below

Ethernet adapter VMware Network Adapter VMnet8:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.203.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter VMware Network Adapter VMnet1:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.31.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.1.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1 :- Router’s non-internet facing interface’s IP


PPP adapter ISP:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 6.6.6.6
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 6.6.6.6



VMplayers IP Configuration given below:

IP: 192.168.203.130
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.203.2

[bala@FC6 ~]$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:9E:A8:86
inet addr:192.168.203.130 Bcast:192.168.203.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe9e:a886/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1074 errors:0 dropped:0 overruns:0 frame:0
TX packets:556 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:87960 (85.8 KiB) TX bytes:69334 (67.7 KiB)

looks like fc6 to fc10 ius failing on auth. what auth mechanisms are you using?

Hi,

Looks like the network is working, output is as expected.

chitambira might have a good point, what do you see when you try to set up an ssh connection using verbose output.

First try the one that you know is working (FC10 -> FC6): ssh -v YYY@6.6.6.6 -p 21
and compare that to (FC6 -> FC10) ssh -v XXX@10.10.10.10 -p 21

I did notice something else: You are trying to do this as root, are both ssh configuration set up to allow this (one seems to be, what about the other). This is what the entry looks like PermitRootLogin no (I do not allow root to use ssh, which is from a security point of view the better option).

You should also have a look at the log files (/var/log/, probably message, but others could also hold information). FC6 and FC10 should be checked, maybe take a look at the host logfiles too.

Hope this gets you going again.

1. I really did not understand about the authentication method. I just use password to authenticate between system's when prompted for one.
   
2. I went in as su - mode in FC10 after logging on as a normal user.
   
3. I did one more thing I saw that the connection was getting established between FC6 and FC10
   
   [XXX@FC 10 ~]$ netstat -ant
   Active Internet connections (servers and established)
   Proto Recv-Q Send-Q Local Address Foreign Address State
   tcp 0 248 10.10.10.10:22 7.7.7.7:36446 ESTABLISHED
   tcp 0 0 10.10.10.10:22 6.6.6.6:1196 ESTABLISHED
   [XXX@FC 10 ~]$
   
   
4. I am attaching the verbose for both the machine below.

[XXX@FC10 ~]$ ssh -v YYY@6.6.6.6 -p 21
OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 6.6.6.6. [6.6.6.6] port 21.
debug1: Connection established.
debug1: identity file /home/XXX/.ssh/identity type -1
debug1: identity file /home/XXX/.ssh/id_rsa type 1
debug1: identity file /home/XXX/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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: checking without port identifier
The authenticity of host '[6.6.6.6]:21 ([6.6.6.6]:21)' can't be established.
RSA key fingerprint is f4:3c:17:ea:8d:59:e2:0a:63:32:5c:7a:e0:4d:09:ff.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[6.6.6.6]:21' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
*******************************************************************************
Banner :- Bla Bla Bla
*******************************************************************************

debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
reverse mapping checking getaddrinfo for abts-tn-dynamic-6.6.6.6.broadband.in [6.6.6.6] failed - POSSIBLE BREAK-IN ATTEMPT!
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Trying private key: /home/XXX/.ssh/identity
debug1: Offering public key: /home/XXX/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/XXX/.ssh/id_dsa
debug1: Next authentication method: password
YYY@6.6.6.6's password:


[YYY@FC6 ~]$ ssh -v XXX@10.10.10.10 -p 21
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.10.10.10 [10.10.10.10] port 21.
debug1: Connection established.
debug1: identity file /home/YYY/.ssh/identity type -1
debug1: identity file /home/YYY/.ssh/id_rsa type -1
debug1: identity file /home/YYY/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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 '10.10.10.10' is known and matches the RSA host key.
debug1: Found key in /home/YYY/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
Connection closed by 10.10.10.10
[YYY@BulletLinux ~]$

Hi,

You did not answer an important question: Any other info in the log files?

I see you are using 2 different ssh versions (OpenSSH_5.1p1 vs OpenSSH_4.3p2) and 2 different ssl versions (OpenSSL 0.9.8g vs OpenSSL 0.9.8b), a little search shows that there are a few known problems/bugs with this configuration. But I won't go as far (yet) to put the blame on this, maybe there's some important info in the log files that could still solve this issue.

Another question you haven't answered yet: Are you able to ssh from/to your base (FC6 <-> Base) and if that works, what ssh/ssl version is running on the Base machine?

Not much to go on, but maybe some important info will show up.

BTW: When you do a su - you are root.

Oops I missed that point of logs. The FC 6 box is located at about 700KM from the place I am currently located at.

I am able to SSH into the FC6 from the base OS. I did not try the opposite because the base is running on Windows.

I will respond with my findings in the log Files tomorrow.

on FC6, run # /usr/sbin/sshd -d and give backl the output
your ssh could have been built against the wrong/not appropriate ssl version

also try to increase the debuglevel for ssh login attemp, # ssh -vvvvv user@10.10.10.10
If you look closely, both connection are arriving at this point:
debug1: SSH2_MSG_SERVICE_REQUEST sent
but FC6 --> FC10 is dropping conxn at this point without giving us the next anticipated mesg debug1: SSH2_MSG_SERVICE_ACCEPT received suggesting that the sshd on FC10 is refusing and subsequently dropping that connection. We need to know why? so increase the verbosity as above and lets see. Also, try to clean up any key files (any previous host information) and then establish a new connection
Did you try to use a windows ssh client to connect to FC10 from a windows machine?

1. I did not find any messages in the log file I tried to
   
   #tail -f /var/log/messages
   Nothing showed up here.
   
   tail -f /var/log/secure
   May 20 18:02:14 localhost sshd[6986]: Connection closed by 6.6.6.6
   
2. I did try to ssh into FC10 from my windows base system using Putty and I was successful.
   
3. Here I have executed the command you have asked for.
   

[root@FC 6 ~]# /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.3p2
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
Cannot bind any address.
[root@FC6 ~]#

[root@FC10 ~]# /usr/sbin/sshd -d
debug1: sshd version OpenSSH_5.1p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
debug1: Bind to port 22 on ::.
Bind to port 22 on :: failed: Address already in use.
Cannot bind any address.
[root@FC10 ~]#

[root@FC6 ~]# ssh -vvvvv XXX@10.10.10.10 -p 21
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.10.10.10 [10.10.10.10] port 21.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 116/256
debug2: bits set: 502/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host '10.10.10.10' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug2: bits set: 519/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
Connection closed by 10.10.10.10
[root@FC6 ~]#

lets see your /etc/ssh/ssh_config on FC6

[root@FC6 ~]# cat /etc/ssh/sshd_config
# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no

# no default banner path
#Banner /some/path
Banner /etc/issue


# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
[root@FC6 ~]#