Adding SSH Ciphers

I've done a fair amount of googling for information about adding ciphers to ssh but no real luck. Is it possible to add a cipher to ssh? I can't even seem to find the location of supporting files (if there are any) for ssh.
I am looking to add the RC6 cipher to ssh. Any help with finding information on adding ciphers and if possible the files for RC5 or RC6 would be greatly appreciated.

The predecessor to both of these ciphers is RC4 or arcfour which is included in the ssh client as arcfour128 and arcfour256.

Similar Messages

  • SSH ciphers help

    Hello,
    One of my co-worker changed our the ssh ciphers that we currently use.
    We made a change to /etc/ssh/ssh_config on our Solaris 10 servers. Security said that we have to use aes128-ctr or higher, but not aes128-cbc.
    The issue is that many of the ssh clients (Tectia) on Windows will not connect to our Solaris servers. Has anyone had this issue? Is there a setting I can set to get this working again?
    Thanks

    Ok I have found the answer. I upgraded the client (tectia) and now it works.

  • [SOLVED] Problem with adding a SSH connection to startup

    Hi guys. I have a problem with adding ssh connection to startup. i want this command to run before kde login screen  and keep running all time.
    ssh -D 9292 remoteuser@remotehost
    but it doesnt connect. Thanks for help!
    Last edited by alperenel (2011-03-11 00:10:27)

    cactus wrote:
    ssh -fN -D 9292 remoteuser@remotehost
    you need -f, which sends ssh to the background, and -N which does not execute a remote command.
    If you need it to run as a user other than root, then you probably need to utilize su as well.
    it didnt work either. i am putting it in rc.local but doesnt work.

  • SSH on Outside interface on ASA 5510

    Hi All,
    I need the ssh access on my ASA outside interface and have added
    ssh ipremoved 255.255.255.255 outside
    access-list acl_outside extended permit tcp host ipremoved any eq 22
    but this is the log i get from ASA
    Oct 06 2012 16:10:04: %ASA-3-710003: TCP access denied by ACL from ipremoved/39884 to outside:ipremoved/22
    Cisco Adaptive Security Appliance Software Version 8.2(5)
    Device Manager Version 6.4(5)
    can someone please help me
    many thanks
    cheers..

    many thanks for the quick reply
    my connection is something like below
           Site A                                                                                   Site B
    PC--10.6.40.148 ---- ASA public IP -------------cloud --------------------public IP ASA
    Site to Site IPsec VPN
    Am able to ssh to the ASA on the private ip management interface, now i need to ssh to the site B public IP to manage
    I have allowed the acl on site A ASA for the PC to go i can see the hit count on it
    The  reason being i need to manage the Site B ASA on public because on Site A am changing the internet provider and so if i have the acces to site B  ASA i can change the peer IP to new IP and reestablish the VPN
    many thanks for the help
    cheers

  • SSH on SG200 series switches

    Community,
    Can someone tell me what the intention behind adding SSH to the SG200 series switches was.  Is it to allow SCP copies to and from the switch for configuration and firmware updates OR is it to allow CLI access to the switches.
    I have tried to SSH to the switch using PuTTY from Windows and native SSH from Linux/Unix clients, but nothing happens.
    Is there some other area of configuration to enable communcation via SSH?
    Thanks.                  

    Hi, any access feature would be under security -> tcp/udp services
    SSH, telnet, etc is not included there.
    The only SG200 switch which supports a CLI is the SG200E models (which has supported CLI for as long as I can remember , at least 2 yrs).
    Please reference the documentation, Chapter 18 start page 276.
    http://www.cisco.com/en/US/docs/switches/lan/csbss/sf20x_sg20x/administration_guide/78-21139.pdf
    As far as I can tell this is for things like Secure Copy.
    There is also CLI information in chapter 19, here's the excerpt. This is in context with SSD.
    The Menu CLI interface is only allowed to users if their read permissions are Both
    or Plaintext Only. Other users are rejected. Sensitive data in the Menu CLI is always
    displayed as plaintext.
    Password recovery is currently activated from the boot menu and allows the user
    to log on to the terminal without authentica
    tion. If SSD is supported, this option is
    only permitted if the local passphrase is identical to the default passphrase. If a
    device is configured with a user-defined passphrase, the user is unable to activate
    password recovery.
    -Tom
    Please mark answered for helpful posts

  • Encryption failed because its identity could not be confirmed

    Hello. I've been having this issue from time to time; I'm trying to connect to another computer which has both *Remote Management* and *Remote Login* activated. On this computer I got *Encrypt all network data (more secure)*, and for some reason after I try to connect to another computer (that has Remote Login activated) I keep getting this error:
    Connection failed because its identity could not be confirmed. This could represent a security problem, or your SSH known_hosts file may be out of date.
    Disable the "Encrypt all network data" security setting or update your SSH known_hosts file.
    How would I update the SSH known_hosts file? And I thought all this was made automatically? I used to be able to do this before, but its not working lately.

    Just found the answer:
    http://support.apple.com/kb/TA27368
    On the admin computer (Mac OS X client computer), choose Go to Folder from the Finder's Go menu.
    Type in the path name to your home folder adding /.ssh to the end of the path. example:
    /Users/username/.ssh where username is your short name.
    Inside the .ssh folder, open the known_hosts file.
    Locate the Servers IP and or its fully qualified Domain name and delete it and the associated characters.Example:
    example.example.com,192.104.192.118 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAutfhNudfFzZ00dyrU5O7/Y1wYhkhVJTSlNLqFROuvkmsB39Y8/> q47cQzdFqRfxsAlirDQKWW2xfr8qAKormuz7fT7so1myuanG24IYPwWmnZdLa3MdQ2zrWDkw672TZUT PBErrZYetej+KnU500mOcvdHjsj0SyPkqVRdPAXs=
    Note: These characters can wrap to several lines.
    Save and close the file.
    Message was edited by: Adrian Chen

  • Jet creation failure

    I am having difficulty getting through the Jet / Create action. The error reported is:
    Problems encountered during plan run or preflight
    The plan (or preflight) "/com/sun/n1osp/untyped/Jet-create" finished with 1 failed host(s). (017034)
    The execNative step failed because the exit status "1" of the command did not match "0" for the command "/opt/SUNWn1sps/N1_Service_Provisioning_System_5.2/cli/bin/cr_cli -cmd fdb.f.lo -ID NM:/com/sun/n1osp/autogen-osprovisioner-jet/provision -s *****". (017068)
    Is there one or many potential causes for this? Is there any way to get more error info?
    Pete.

    Yes, it is remedial, shame to me :-) (I had stumbled across that while waiting for responses). Apparently my SSH is not set up right :
    2006-12-15 17:19:51,015 ERROR [main] com.raplix.rolloutexpress.net.command.DatagramOutputStream (DatagramOutputStream.java:157) - Error sending data
    Error writing the handshake string to the newly established connection. (022181)
    Connection handshake failed, invalid handshake string. Ensure that the path to the N1 Service Provisioning System application is correct, the application is configured to accept ssh connections and that you can ssh to the machine without any prompts. |[Host key verification failed.](022138)
    I am trying to get by with two physical hosts. One has the master on it (sps), and the other (osprovisioner) has the ra, and the virtual OSP host, and I am trying to create the JET on it as well.
    From sps -> osprovsioner, I can ssh -A -t <ip> <command> and things work fine. When I go in the opposite direction (osprovisioner -> sps) I get prompted for a password.. Should this work?
    The below is still somewhat of a mystery to me (the private key for the cli is added (ssh-add) from secure media into the master yet, ssh-agent is run on the JET !?!?:
    Howto Configure SSH for the CLI ClientWith the
    ssh-agent
    Complete this task if you want to use SSH connectivity for the CLI Client with the ssh-agent.
    Create a new operating system user account on the Master Server and the machine on which the CLI
    Client is installed.
    This account should be different from the account that you specified during the installation of the
    Master Server, Local Distributor, or Remote Agent.
    Log in to the Master Server as the new user that you created in the previous step.
    Generate public and private keys for the new user by following the instructions in �How to Generate
    Key Pairs� on page 75.
    Do not reuse the keys that you generated for communication between the Master Server, Local
    Distributors, and Remote Agents.
    On the Master Server, copy the private key file to a secure media.
    % cp /User-home/.ssh/id_rsa path-to-file/.ssh/id_rsa
    User-home is the home directory of the currently logged in user on the Master Server machine.
    path-to-file/ is the path to the secure media where you want to save the private key file.
    Delete the private key file from the local file system.
    % rm /User-home/.ssh/id_rsa
    On the Master Server, concatenate the public key to the /.ssh/authorized_keys2 file for that user.
    % cat /User-home/.ssh/id_rsa.pub >> /HOME-MS/.ssh/authorized_keys2
    User-home is the home directory on the Master Server machine.
    5
    6
    7
    8
    1
    2
    3
    4
    5
    6
    Configuring SSH for the Applications
    Sun N1 Service Provisioning System 5.2 Installation Guide 82 � April 2006
    Log in to the CLI Client machine as the new user that you created.
    Start the ssh-agent.
    % ssh-agent > /User-home/.ssh/agent_vars
    User-home is the home directory of the currently logged in user on the CLI Client machine.
    Add the following line to the .profile, the .cshrc, or the.bash_profile file.
    . /User-home/.ssh/agent_vars
    User-home is the home directory on the CLI Client machine.
    Log out of the Master Server and log back in.
    Upload the private key that you generated.
    % ssh-add path-to-file/

  • Private shares permission can't always save or delete via Mac Win 7 ok

     I have two macbook airs 14 models and one Imac a 14 model Running Yosemite 10.0.4. I also have a 4 year old Windows 7 Toshiba Laptop. I have a Western digital My Book Live duo, with the latest firmware updated 17 July. This NAS has a number of private shares with full admin rights and accessed via wifi and or lan through a static ip address set in the NAS drive From my Windows 7 I just mapped the drive through the IP address and everything works I can open delete save any type of file I want in any program, create directories and for a small NAS drive on a home network it is very fast. However on my Mac’s there are huge problems, none the least is the slowness of accessing files and the drives. It is like watching grass grow, to see and access files in the various private and public shares. The biggest problem is not all files can be saved over e.g. word for mac 2011 save as and not all can be deleted "due to naming and permission’s errors or access rights to delete or modify"  "Word cvannot save this document due to a naming or permissions error." This is incorrect according to the NAS drive admin page and from the Windows 7 machine that allows it to save. Name changes don’t matter no does assigning user rights to the specific file. It is the same with some videos and other files randomly. I have created a start up script for the apple that runs in the user login items. This is the only way I have found to log into the private shares with Macs. I understand you can do something at a terminal level but I have no understanding of this delay 10tell application "Finder"               mount volume "smb://Networkname;usernameassword@Networkname/User1"               mount volume "smb:// Networkname; usernameassword @ Networkname /Photos"               mount volume "smb:// Networkname; usernameassword @ Networkname /User"               mount volume "smb:// Networkname; usernameassword @ Networkname /Scanneddocuments"               mount volume "smb:// Networkname; usernameassword @ Networkname /Scannedphotos"               mount volume "smb:// Networkname; usernameassword @ Networkname /music"               mount volume "smb:// Networkname; usernameassword @ Networkname /General"               mount volume "smb:// Networkname; usernameassword @ Networkname /Videos"               delay 2               set desktop shows connected servers of Finder preferences to falseend tell This script mounts the shares and keeps the folders hidden on the desktop. I see on these WD community forums others are having similar problems at least since 2012 To quote a problem and suggested solution “Checking file info I see the same as another contributorRegardless of whether I connect as guest or connect as admin - the permissions I am seeing on the subfolders of the public share are: daapd   Read & Writestaff       Read & Writeeveryone  Read only. But above the list of permissions it says "You have custom access". Another contributor offered this as a solutionSolution:Went to the web UI usinghttp://drivename.local/which redirected to http://drivename.local/UI/Added ssh to the url:  http://drivename.local/UI/sshChecked the box to turn on sshOpened a terminal window, connected via ssh using the UI-supplied passwordNavigated to the public folder.  Ownership of the public folder was "root" and group "share".  Ownership of the problematic subfolders was "root" and group "root".executed the command "chgrp -R share Public" to change ownership of all files under public to the "share" group.Closed terminal window. Turned ssh back off.  Drive behaves normally. However when I follow this it only brings up the login page no check box to move to the next steps. This may be simple to those who understand these things but alas I don’t.” I am at a loss on how to sort this as I have little knowledge of Apple systems or how to have a WD network share operating like a network should. Is this a Western Digital problem of Apple. I see other posts talking about similar issues relating to file and folder privileges. I saw an earlier post regarding the same issue and a contributor recommended Thank you for any info you can provide

     
    Hello and welcome to the WD Community
    See if the following link helps
    http://community.wd.com/t5/My-Book-Live/AFP-and-File-Permissions-MAC-OS-X-Lion/m-p/247550#M3842
    If stills the same, please contact WD Support directly.
    WD Contact info:
    http://support.wdc.com/country/index.asp?lang=en%22

  • Storage Disappeared! Sort of...

    Hello all,
    I'm running a single host instance of VDI3.0 on a Sun Fire x2200. The storage backend is a Unified Storage 7110. I recently updated the 7110 to the latest firmware version - after which, VDI tells me that my storage is unresponsive. The system shows me as having no storage whatsoever, but yet I am typing this forum post from a virtual machine that was booted and running from the "missing" storage pool.
    As a result of this madness, I am unable to import and boot any new virtual machines. I attempted to add a new storage backend to the system, and when I put in the credentials of the 7110, it does not present the system with a certificate. I can, however, ssh directly into the storage from the VDI provider host.
    I appreciate any insight, because I am totally at a loss on this one.
    Thanks,
    Bob Prendergast

    Hi Bob.
    I suppose you use the 2009.Q2.0.0 version of the 7110 software? The SSH ciphers offered by the SSHD of that release have not a single match in the ciphers list of the SSH client of VDI 3, therefore all SSH connections fail. This issue is currently fixed for the upcoming VDI 3 patch to be released end of this month.
    If you are really in the urgent need of a workaround - and I can't emphasize enough that this workaround isn't even sanity tested yet, so apply it on your own peril - you can download the 1.41 version of the jsch library from http://prdownloads.sourceforge.net/jsch/jsch-0.1.41.jar?download. Shutdown the VDI service on every VDI host ("cacaoadm stop --force"), replace old library at /opt/SUNWvda/lib/jsch-0.1.39.jar with the new one (you need to rename the new library to match the name of the old library) and restart the VDI services again ("cacaoadm start").
    ~Thomas

  • SSH Key login not working when added to gpg-agent

    Hello,
    As I use gnupg, I run the gpg-agent. I run it with systemd --user and it works flawlessly. As I already run gpg-agent, I figured I might as well just add my ssh keys to it as well. Therefore I start gpg-agent with --enable-ssh-support. I use my SSH keys a lot and never had any problems with connecting to anything with a simple ssh .... or pushing things to git etc.
    As the SOCKS_AUTH_SSH envvar needs to be set for ssh-add to work, I added this line to my .bashrc
    export SSH_AUTH_SOCK=~/.gnupg/S.gpg-agent.ssh
    Now, adding my SSH Keys with a simple ssh-add seems to work fine (no errors etc).
    However, when I try to connect to a server now, the following happens:
    ssh -vT [email protected]
    OpenSSH_6.8p1, OpenSSL 1.0.2a 19 Mar 2015
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Connecting to XXXXXXXXX port XXXXX.
    debug1: Connection established.
    debug1: identity file /home/XXXXX/.ssh/id_rsa type 1
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/XXXXX/.ssh/id_rsa-cert type -1
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_6.8
    debug1: Remote protocol version 2.0, remote software version OpenSSH_6.8
    debug1: match: OpenSSH_6.8 pat OpenSSH* compat 0x04000000
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: server->client aes128-ctr [email protected] none
    debug1: kex: client->server aes128-ctr [email protected] none
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Mw5MTDp91yExgStdoMPMwi2yZdoG9MruOm+6XiC5Vks
    debug1: Host '[XXXXXXX]:XXX' is known and matches the ECDSA host key.
    debug1: Found key in /home/XXXX/.ssh/known_hosts:1
    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
    debug1: Next authentication method: publickey
    debug1: Offering RSA public key: /home/XXXXX/.ssh/id_rsa
    debug1: Server accepts key: pkalg ssh-rsa blen 279
    debug1: No more authentication methods to try.
    Permission denied (publickey).
    Which is very strange as id_rsa is my (ecrypted) private key. I am also prompted to enter the corresponding password when issuing ssh-add.
    What could the problem be in this case? Thanks a lot!!
    Last edited by replax (2015-05-18 19:06:58)

    replax wrote:Well, there is something listed in .gnupg/sshcontrol , I am not sure if it is connected to my own key though. I tried ssh-add -l and it will list my one key, although it is different from the one in sshcontrol. I suspect that that is an issue of presentation though, as ssh-add spews out the SHA256 of my key..
    How could I go about verifying that they key is indeed correct? Shouldn't it be added automatically by ssh-add?
    Thanks a lot!!
    Yes it should be added automatically. I suppose you could try it in a new user just to start fresh and see if it works, at least then you'll have either verified that your steps were correct or incorrect.

  • Ssh-add does not stay, er, added...

    I'm troubleshooting an installation of SSH-Keys. I've successfully installed this with another user. After considerable effort can not discover why the two accounts do not behave the same. One account asks for the passphrase on login, and the other doesn't. Both accounts have the single line ssh-add in ~/.bash_profile.
    Where does ssh-add store the added key for each user? Can I inspect this to discover the problem?
    [xtian@frylock .ssh]$ ssh-add xtian_frylock-id_rsa
    Enter passphrase for xtian_frylock-id_rsa:
    Identity added: xtian_frylock-id_rsa (xtian_frylock-id_rsa)
    [xtian@frylock .ssh]$ ssh-add -L
    ssh-rsa AAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xtian_frylock-id_rsa
    Logout and log back in to find,
    [xtian@frylock ~]$ ssh-add -L
    The agent has no identities.
    Last edited by xtian (2013-10-23 23:41:31)

    Ok. Here's the output from the working root account:
    [root@frylock ~]# printenv | grep -i ssh
    SSH_AGENT_PID=701
    SSH_AUTH_SOCK=/tmp/ssh-0HKTJiMZQ6ob/agent.700
    And here's the output from the non-working user account:
    [xtian@frylock ~]$ printenv | grep -i ssh
    SSH_AGENT_PID=836
    SSH_AUTH_SOCK=/tmp/ssh-q6eu9w7ofDc3/agent.835
    Now, I don't launch ssh-agent in .bash_profile. Before I tried to configure gpg-agent and, as near as I can recall, I used the same configuration when I fell back to using ssh-agent. Which is to say I put the eval line in a separate file in /etc/profile.d:
    [xtian@frylock ~]$ cat /etc/profile.d/ssh-agent.sh
    #!/bin/bash
    eval $(ssh-agent)
    Where are the ssh-agent environmental variables set? Not in /tmp
    Last edited by xtian (2013-10-25 22:19:54)

  • Few ?s re: Adding user/SSH/restricting

    I want to set up a user that can SSH in to my box but is restricted to his home directory. So let's say I make user guest, they shouldn't be allowed to venture outside of /home/guest, or access anything outside of /home/guest period. A few questions the more I google the more I am getting confused by all the varying answers:
    1. Doing useradd, what group do I put for this user guest?
    2. How to do the restriction? I have read about rbash but that supposedly only locks the user out of cd'ing outside the /home/guest, but not accessing outside (ls, mv, etc.) ??
    3. Say I give the user+pass for guest to a friend, he SSH's into my box, now how can I in realtime view his shell session? (Watch him cd/ls/etc.)
    4. How would I terminate the SSH session of the guest myself?
    Many thanks for any help

    *nix is designed as multi-user, so if you just make a user that's in the users group (just use adduser if you're not sure about useradd) and they won't be able to harm anything outside of their home directory unless you have messed up the default (fairly secure) settings. You might want to set up quotas if you're worried about them filling /tmp, /home or the various world-writable directories in /var.
    Completing taking away read access from /usr, /bin, etc. would stop them from running anything. Just make sure your home directory is set to 700 permissions and you don't have anything private outside of there.
    question 3 can be answered by a quick google search:
    http://serverfault.com/questions/12419/ … -real-time
    4. pkill, kill, killall? or just kill sshd
    Last edited by thestinger (2011-01-12 04:38:35)

  • SSH - Failure to connect, does not prompt for password,

    I have been using SSH on this iMac with 10.5.4 for over a year, upgraded to Leopard when it came out, never a problem with SSH, but now for no apparent reason, SSH fails when trying to connect through VPN into work.
    I can still connect to other systems on the internet that are not through the VPN.
    I don't suspect this to be a VPN issue because no other employees are having this problem with the VPN, using Mac, Windows or Linux. I can connect vi putty on my windows from the same network... below is my config.
    Here is what I'm getting:
    I connect as- ssh me@hostname and it returns "Permission denied (publickey)." It makes to attempt to prompt me for a password. I do not use a key on this system so it should prompt me for a password. I changed nothing on the system to cause ssh to break, But it's possible that a apple security update caused something to break.
    I have added the following to my ~/.ssh/config file
    PasswordAuthentication yes
    My /etc/ssh_config file is as follows:
    cat /etc/ssh_config
    # $OpenBSD: ssh_config,v 1.22 2006/05/29 12:56:33 dtucker Exp $
    # This is the ssh client system-wide configuration file. See
    # ssh_config(5) for more information. This file provides defaults for
    # users, and the values can be changed in per-user configuration files
    # or on the command line.
    # Configuration data is parsed as follows:
    # 1. command line options
    # 2. user-specific file
    # 3. system-wide file
    # Any configuration value is only changed the first time it is set.
    # Thus, host-specific definitions should be at the beginning of the
    # configuration file, and defaults at the end.
    # Site-wide defaults for some commonly used options. For a comprehensive
    # list of available options, their meanings and defaults, please see the
    # ssh_config(5) man page.
    # Host *
    # ForwardAgent no
    # ForwardX11 no
    # RhostsRSAAuthentication no
    # RSAAuthentication yes
    PasswordAuthentication yes
    # HostbasedAuthentication no
    # GSSAPIAuthentication no
    # GSSAPIDelegateCredentials no
    # GSSAPIKeyExchange no
    # GSSAPITrustDNS no
    # BatchMode no
    # CheckHostIP yes
    # AddressFamily any
    # ConnectTimeout 0
    # StrictHostKeyChecking ask
    # IdentityFile ~/.ssh/identity
    # IdentityFile ~/.ssh/id_rsa
    # IdentityFile ~/.ssh/id_dsa
    # Port 22
    # Protocol 2,1
    # Cipher 3des
    # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
    # EscapeChar ~
    # Tunnel no
    # TunnelDevice any:any
    PermitLocalCommand yes
    My /etc/sshd_config is:
    cat /etc/sshd_config
    # $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $
    # 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
    #Protocol 2,1
    Protocol 2
    #AddressFamily any
    #ListenAddress 0.0.0.0
    #ListenAddress ::
    # HostKey for protocol version 1
    #HostKey /etc/sshhostkey
    # HostKeys for protocol version 2
    #HostKey /etc/sshhost_rsakey
    #HostKey /etc/sshhost_dsakey
    # Lifetime and size of ephemeral version 1 server key
    #KeyRegenerationInterval 1h
    #ServerKeyBits 768
    # Logging
    # obsoletes QuietMode and FascistLogging
    SyslogFacility AUTHPRIV
    #LogLevel INFO
    # Authentication:
    #LoginGraceTime 2m
    #PermitRootLogin yes
    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/sshknownhosts
    #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
    # SACL options
    #SACLSupport yes
    # Change to no to disable s/key passwords
    #ChallengeResponseAuthentication yes
    # Kerberos options
    #KerberosAuthentication no
    #KerberosOrLocalPasswd yes
    #KerberosTicketCleanup yes
    #KerberosGetAFSToken no
    # GSSAPI options
    #GSSAPIStrictAcceptorCheck yes
    #GSSAPIKeyExchange yes
    # GSSAPI options
    #GSSAPIAuthentication 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 yes
    #AllowTcpForwarding yes
    #GatewayPorts no
    #X11Forwarding no
    #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
    # override default of no subsystems
    Subsystem sftp /usr/libexec/sftp-server
    # Example of overriding settings on a per-user basis
    #Match User anoncvs
    # X11Forwarding no
    # AllowTcpForwarding no
    # ForceCommand cvs server

    Also I forgot to mention, I have nulled out the known_hosts file to eliminate any conflicts there, I have verified .ssh is 700 and files config and known_hosts are 600
    output using ssh -v
    debug1: Reading configuration data /Users/<me>/.ssh/config
    debug1: Reading configuration data /etc/ssh_config
    debug1: Connecting to pshx4105a [216.255.177.213] port 22.
    debug1: Connection established.
    debug1: identity file /Users/<me>/.ssh/identity type -1
    debug1: identity file /Users/<me>/.ssh/id_rsa type -1
    debug1: identity file /Users/<me>/.ssh/id_dsa type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5p1 FreeBSD-20061110
    debug1: match: OpenSSH_4.5p1 FreeBSD-20061110 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_4.7
    debug1: SSH2MSGKEXINIT sent
    debug1: SSH2MSGKEXINIT received
    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug1: kex: client->server aes128-cbc hmac-md5 none
    debug1: SSH2MSG_KEX_DH_GEXREQUEST(1024<1024<8192) sent
    debug1: expecting SSH2MSG_KEX_DH_GEXGROUP
    debug1: SSH2MSG_KEX_DH_GEXINIT sent
    debug1: expecting SSH2MSG_KEX_DH_GEXREPLY
    debug1: Host 'pshx4105a' is known and matches the DSA host key.
    debug1: Found key in /Users/<me>/.ssh/known_hosts:3
    debug1: sshdssverify: signature correct
    debug1: SSH2MSGNEWKEYS sent
    debug1: expecting SSH2MSGNEWKEYS
    debug1: SSH2MSGNEWKEYS received
    debug1: SSH2MSG_SERVICEREQUEST sent
    debug1: SSH2MSG_SERVICEACCEPT received
    debug1: Authentications that can continue: publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: /Users/<me>/.ssh/identity
    debug1: Trying private key: /Users/<me>/.ssh/id_rsa
    debug1: Trying private key: /Users/<me>/.ssh/id_dsa
    debug1: No more authentication methods to try.

  • Unable to ssh to servers from Solaris u10 server

    The majority of my systems were built with u5. We've recently added a few x86 VMs and a few zones running u10 and I'm having ssh issues with them. When I try to ssh to them, I'm unable to login using our keys and get presented with the password prompt. I've been looking at previous posts similar to this situation, but none seem fitting. I've tried creating a new dsa key as a test and below are the results.
    $ ssh -i id_dsa2 -vvv newuser@newserver
    Sun_SSH_1.1.2, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
    debug1: Reading configuration data /opt/build/.ssh/config
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Rhosts Authentication disabled, originating port will not be trusted.
    debug1: ssh_connect: needpriv 0
    debug1: Connecting to newserver [10.10.100.99] port 22.
    debug1: Connection established.
    debug3: Not a RSA1 key file id_dsa2.
    debug2: key_type_from_name: unknown key type '-----BEGIN'
    debug3: key_read: no key found
    debug3: key_read: no space
    debug3: key_read: no space
    debug3: key_read: no space
    debug3: key_read: no space
    debug3: key_read: no space
    debug3: key_read: no space
    debug3: key_read: no space
    debug3: key_read: no space
    debug3: key_read: no space
    debug3: key_read: no space
    debug2: key_type_from_name: unknown key type '-----END'
    debug3: key_read: no key found
    debug1: identity file id_dsa2 type -1
    debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3
    debug1: match: Sun_SSH_1.1.3 pat Sun_SSH_1.1.*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-Sun_SSH_1.1.2
    debug1: use_engine is 'yes'
    debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
    debug1: pkcs11 engine initialization complete
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: en-US
    debug2: kex_parse_kexinit: en-US
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
    Unknown code 0
    debug1: SSH2_MSG_KEXINIT sent
    debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: en-US
    debug2: kex_parse_kexinit: en-US
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
    debug2: kex_parse_kexinit: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
    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-ctr hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-ctr hmac-md5 none
    debug1: Peer sent proposed langtags, ctos: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
    debug1: Peer sent proposed langtags, stoc: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
    debug1: We proposed langtags, ctos: en-US
    debug1: We proposed langtags, stoc: en-US
    debug1: Negotiated lang: en-US
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: Remote: Negotiated main locale: en_US.UTF-8
    debug1: Remote: Negotiated messages locale: en_US.UTF-8
    debug1: dh_gen_key: priv key bits set: 134/256
    debug1: bits set: 1600/3191
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename /opt/build/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 68
    debug1: Host 'newserver' is known and matches the RSA host key.
    debug1: Found key in /opt/build/.ssh/known_hosts:68
    debug1: bits set: 1576/3191
    debug1: ssh_rsa_verify: signature correct
    debug2: kex_derive_keys
    debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
    debug1: newkeys: mode 1
    debug1: set_newkeys: setting new keys for 'out' mode
    debug3: aes-128-ctr NID found
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: newkeys: mode 0
    debug1: set_newkeys: setting new keys for 'in' mode
    debug3: aes-128-ctr NID found
    debug1: SSH2_MSG_NEWKEYS received
    debug1: done: ssh_kex2.
    debug1: send SSH2_MSG_SERVICE_REQUEST
    debug2: service_accept: ssh-userauth
    debug1: got SSH2_MSG_SERVICE_ACCEPT
    debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
    debug3: start over, passed a different list gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
    debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
    debug3: authmethod_lookup gssapi-keyex
    debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
    debug3: authmethod_is_enabled gssapi-keyex
    debug1: Next authentication method: gssapi-keyex
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup gssapi-with-mic
    debug3: remaining preferred: publickey,keyboard-interactive,password
    debug3: authmethod_is_enabled gssapi-with-mic
    debug1: Next authentication method: gssapi-with-mic
    debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
    Unknown code 0
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: keyboard-interactive,password
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: id_dsa2
    debug1: read PEM private key done: type DSA
    debug3: sign_and_send_pubkey
    debug2: we sent a publickey packet, wait for reply
    debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup keyboard-interactive
    debug3: remaining preferred: password
    debug3: authmethod_is_enabled keyboard-interactive
    debug1: Next authentication method: keyboard-interactive
    debug2: userauth_kbdint
    debug2: we sent a keyboard-interactive packet, wait for reply
    debug2: input_userauth_info_req
    debug2: input_userauth_info_req: num_prompts 1
    Password:
    On the server
    # /usr/lib/ssh/sshd -ddd
    debug1: sshd version Sun_SSH_1.1.3
    debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
    debug1: read PEM private key done: type RSA
    debug1: private host key: #0 type 1 RSA
    debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
    debug1: read PEM private key done: type DSA
    debug1: private host key: #1 type 2 DSA
    debug1: Bind to port 22 on ::.
    Server listening on :: port 22.
    debug1: Server will not fork when running in debugging mode.
    Connection from 10.10.100.70 port 42731
    debug1: Client protocol version 2.0; client software version Sun_SSH_1.1.2
    debug1: match: Sun_SSH_1.1.2 pat Sun_SSH_1.1.*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-Sun_SSH_1.1.3
    debug2: Waiting for monitor
    monitor debug1: list_hostkey_types: ssh-rsa,ssh-dss
    monitor debug2: Monitor pid 3595, unprivileged child pid 3596
    debug2: Monitor signalled readiness
    debug1: use_engine is 'yes'
    debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
    debug1: pkcs11 engine initialization complete
    debug1: list_hostkey_types: ssh-rsa,ssh-dss
    monitor debug1: reading the context from the child
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
    debug2: kex_parse_kexinit: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: GSS-API Mechanism encoded as toXXXXlw5Ew8Mqkay+al2g==
    debug1: SSH2_MSG_KEXINIT sent
    debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: gss-group1-sha1-toWMXXXXEw8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
    debug2: kex_parse_kexinit: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: en-US
    debug2: kex_parse_kexinit: en-US
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-ctr hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug1: Peer sent proposed langtags, ctos: en-US
    debug1: Peer sent proposed langtags, stoc: en-US
    debug1: We proposed langtags, ctos: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
    debug1: We proposed langtags, stoc: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
    debug1: Negotiated main locale: en_US.UTF-8
    debug1: Negotiated messages locale: en_US.UTF-8
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
    debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
    debug1: dh_gen_key: priv key bits set: 125/256
    debug1: bits set: 1582/3191
    debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
    debug1: bits set: 1602/3191
    debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
    debug2: kex_derive_keys
    debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
    debug1: newkeys: mode 1
    debug1: set_newkeys: setting new keys for 'out' mode
    debug3: aes-128-ctr NID found
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: newkeys: mode 0
    debug1: set_newkeys: setting new keys for 'in' mode
    debug3: aes-128-ctr NID found
    debug1: SSH2_MSG_NEWKEYS received
    debug1: KEX done
    debug1: userauth-request for user newuser service ssh-connection method none
    debug1: attempt 0 initial attempt 0 failures 0 initial failures 0
    debug2: input_userauth_request: setting up authctxt for newuser
    debug2: input_userauth_request: try method none
    Failed none for newuser from 10.10.100.70 port 42731 ssh2
    debug1: userauth-request for user newuser service ssh-connection method publickey
    debug1: attempt 1 initial attempt 0 failures 1 initial failures 0
    debug2: input_userauth_request: try method publickey
    debug1: temporarily_use_uid: 516/516 (e=0/0)
    debug1: trying public key file /opt/newuser/.ssh/authorized_keys
    debug3: secure_filename: checking '/opt/newuser/.ssh'
    debug3: secure_filename: checking '/opt/newuser'
    debug3: secure_filename: terminating check at '/opt/newuser'
    debug1: matching key found: file /opt/newuser/.ssh/authorized_keys, line 2
    Found matching DSA key: 3a:73:9a:93:dd:6e:ae:fb:08:05:e1:16:32:c5:b0:db
    debug1: restore_uid: 0/0
    debug1: ssh_dss_verify: signature correct
    debug2: Starting PAM service sshd-pubkey for method publickey
    debug3: Trying to reverse map address 10.10.100.70.
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss
    Failed publickey for newuser from 10.10.100.70 port 42731 ssh2
    debug1: userauth-request for user newuser service ssh-connection method keyboard-interactive
    debug1: attempt 2 initial attempt 0 failures 2 initial failures 0
    debug2: input_userauth_request: try method keyboard-interactive
    debug1: keyboard-interactive devs
    debug2: Starting PAM service sshd-kbdint for method keyboard-interactive
    debug2: Calling pam_authenticate()
    debug2: PAM echo off prompt: Password:
    debug2: Nesting dispatch_run loop
    Connection closed by 10.10.100.70
    debug1: Calling cleanup 0x8065f39(0x80c7358)
    debug1: Calling cleanup 0x806057f(0x80c8418)
    debug1: Calling cleanup 0x80810c0(0x0)
    monitor debug1: child closed the communication pipe before user auth was finished
    monitor debug1: Calling cleanup 0x80810c0(0x0)
    monitor debug1: Calling cleanup 0x80810c0(0x0)

    I'm lost on why it finds the key, buts fails to accept it. Our build server is not able to deploy to these new systems, even though we use puppet to create the users consistently on each server. Same authorized_keys, sshd_config etc...
    debug1: matching key found: file /opt/newuser/.ssh/authorized_keys, line 2
    Found matching DSA key: 3a:73:9a:93:dd:6e:ae:fb:08:05:e1:16:32:c5:b0:db
    debug1: restore_uid: 0/0
    debug1: ssh_dss_verify: signature correct
    debug2: Starting PAM service sshd-pubkey for method publickey
    debug3: Trying to reverse map address 10.10.100.70.
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss
    Failed publickey for newuser from 10.10.100.70 port 42731 ssh2
    Any help would be appreciated.

  • SSH/PAM login issue with fresh install: edit wiki or raise bug?

    I recently encountered an issue while setting up Arch on a headless server, and was wondering if I did something stupid, the documentation should be improved or I found a bug.
    The problem was that after adding a new non-root user, I couldn't SSH into that user account. I could still login to root via SSH fine. After some research and playing around I found I was able to login by setting UsePAM to no in /etc/ssh/sshd_config. I later realised that this was because I set the login shell for this account to /usr/bin/bash, and not /bin/bash. The problem is that currently /usr/bin/bash is not in /etc/shells, and the default /etc/ssh/sshd_config sets UsePAM to yes.
    As this is a new default install, and I followed the wiki during the install, I feel that this should have been documented somewhere. I don't mind changing the wiki or reporting this as a bug, just I'm not sure which is the correct course of action:
    1. Should I have known to use /bin/bash and not /usr/bin/bash, i.e. the login shell needs to be in /etc/shells? => edit the wiki [1]
    2. Should /usr/bin/bash be in /etc/shells? => raise a bug against filesystem [2]
    Related:
    [1] https://wiki.archlinux.org/index.php/Gr … management
    [2] https://projects.archlinux.org/svntogit … unk/shells
    [3] https://bugs.archlinux.org/task/35724
    [4] https://bbs.archlinux.org/viewtopic.php?id=166464
    Last edited by quigybo (2013-11-02 17:34:42)

    The wiki should be changed. /bin/bash is the correct entry in the list of shells.
    I cannot, however, remember off hand in which context this came up. I just remember this was the developers' response. So I can't point you to evidence to confirm even though I do know that is the correct answer.
    EDIT: https://bugs.archlinux.org/task/33677
    https://bugs.archlinux.org/task/33694
    Last edited by cfr (2013-11-03 03:56:49)

Maybe you are looking for