# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# 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
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2
# 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
#LogLevel INFO
# 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 no
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# 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 and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowTcpForwarding yes
#GatewayPorts 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
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
# no default banner path
#Banner /some/path
# here are the new patched ldap related tokens
# entries in your LDAP must have posixAccount & ldapPublicKey
objectclass
#UseLPK yes
#LpkLdapConf /etc/ldap.conf
#LpkServers ldap://10.1.7.1/ ldap://10.1.7.2/
#LpkUserDN ou=users,dc=phear,dc=org
#LpkGroupDN ou=groups,dc=phear,dc=org
#LpkBindDN cn=Manager,dc=phear,dc=org
#LpkBindPw secret
#LpkServerGroup mail
#LpkFilter (hostAccess=master.phear.org)
#LpkForceTLS no
#LpkSearchTimelimit 3
#LpkBindTimelimit 3
# override default of no subsystems
Subsystem sftp /usr/lib/misc/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server
And here's the emerge information for ssh:
michael@camille ~ $ cat emerge-openssh.log
These are the packages that would be merged, in order:
There were no 'official' logs, but a website I found on google suggested
running
/usr/sbin/sshd -ddd -p 2202
and then trying to shell over with
ssh -p 2202<boxname>
Here's the output. I piped it to a file:
[snip]
I tried upgrading PAM and rebooting, but it didn't solve the problem.
I'm running pam-1.0.1, if that matters...
what problem? you haven't actually said what is / isn't working! What's
the output from the client when you try and ssh in with the command "ssh
-p 2202 <boxname>"?
--
Iain Buchanan <iaindb at netspace dot net dot au>
Don't go easy on each other just because you're brother and sister. I
want to see you both fighting for your parents' love.
Michael Sullivan wrote:
> On Fri, 2008-09-12 at 15:27 +0930, Iain Buchanan wrote:
>> Michael Sullivan wrote:
>>> I hooked up my old server box today so that I could update the software,
>>> only to find that I could not ssh over to it:
>>>
>>> michael@camille ~ $ ssh bullet
>>> Permission denied (publickey,keyboard-interactive).
>>>
>>> There were no 'official' logs, but a website I found on google suggested
>>> running
>>>
>>> /usr/sbin/sshd -ddd -p 2202
>>>
>>> and then trying to shell over with
>>>
>>> ssh -p 2202<boxname>
>>>
>>> Here's the output. I piped it to a file:
>> [snip]
>>
>>> I tried upgrading PAM and rebooting, but it didn't solve the problem.
>>> I'm running pam-1.0.1, if that matters...
>> what problem? you haven't actually said what is / isn't working! What's
>> the output from the client when you try and ssh in with the command "ssh
>> -p 2202 <boxname>"?
>>
>
> I thought I was pretty clear on that, but here it is again:
>
> michael@camille ~ $ ssh -p 2202 bullet
> Permission denied (publickey,keyboard-interactive).
>
> As you can see, I'm still locked out.
>
>
try
# ssh -p 2202 -vv bullet
or
#ssh -vv bullet
as that will give you debug info from the client side of the connection.
Is it safe to assume that you logged into it via the console to start
SSHd on 2202? Also, does your user exist on the box? It sounds like
'no', especially when btmp is involved.
--
Eric Martin
Key fingerprint = D1C4 086E DBB5 C18E 6FDA B215 6A25 7174 A941 3B9F
...
debug1: sshd version OpenSSH_4.7p1
debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
This appears suspicious to me. I would delete that file on the ssh
server & restart ssd - the key will be regenerated (this may take a
minute or two).
If you have previously ssh'd successfully to this from a client then
you may get "incorrect key" errors - just delete the applicable line
from ~/.ssh/known_hosts on that client. If my guess is correct then
you'll be able to log in.