Find the answer to your Linux question:
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 22
Originally Posted by rfxcasey the 'permitrootlogin yes' is commented out. if that is the case, then you won't be able to log in as the "root" user, which by default ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #11
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353

    Quote Originally Posted by rfxcasey View Post
    the 'permitrootlogin yes' is commented out.
    if that is the case, then you won't be able to log in as the "root" user, which by default is usually the only user in Puppy Linux (at least on mine it is). fyi, to specify the user when you log in via ssh you can do it like this:
    Code:
    ssh username@localhost
    or using the lower-case L flag:
    Code:
    ssh -l username localhost
    that username you specify must be a valid system account on the Puppy box with a valid shell, i.e., look in /etc/passwd. In that file, the first column is the username, the 6th col is your home directory (e.g., /root) and the 7th is your shell (e.g., /bin/bash).

    I'll try to scan the port from my Windows box.
    for that I'd recommend SuperScan v3, it is tiny, does not need to be installed (is just an exe) and works great.

  2. #12
    Just Joined!
    Join Date
    Sep 2009
    Posts
    16
    Did a port scan with nmap, here's the results:
    Code:
    C:\>nmap 192.168.0.115
    
    Starting Nmap 6.25 at 2013-07-21 05:36 Eastern Daylight Time
    Nmap scan report for 192.168.0.115
    Host is up (0.000092s latency).
    Not shown: 999 closed ports
    PORT   STATE SERVICE
    22/tcp open  ssh
    MAC Address: 00:E0:18:B2:18:ED (Asustek Computer)
    
    Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds
    
    C:\>
    Looks like port 22 is open and the service is running. I'm thinking this means either something is wrong in the sshd_config file or security keys. I'm thinking other possibilities could be my client machines IP is being blocked (but then I guess the port scan or pinging wouldn't work) or something in my putty settings is not right but I have basically tried all the options and combinations of them with still no avail. I'm really leaning towards the sshd_config but I don't really know enough about it to be effective. Anyone with some experience or who can post a good config file, please do chime in. I would have thought the default setting would work just fine but apparently not.

    Perhaps putty is trying to autologin with the wrong username and password or the sshd server is only allowing autologon with a specific username and password. I'm not even sure what the default login username and password are supposed to be for Puppy's sshd package. Seems like putty is trying to autologon or sshd is expecting an autologon explicitly with the correct name and pass and when it doesn't get it it's kicking the client off instantly.

    I just tried using a an alternate SSH client AbsoluteTelnet and when attempting to connect here is what I get:
    Code:
    Running in FIPS 140-2 Mode
    Validating FIPS certified DLL...Passed
    
    Connecting to 192.168.0.115:22
       attempting 192.168.0.115:22...     Success!
    Remote Server Disconnected Unexpectedly
    So it definitely looks like the ssh server is up and listening and I am actually able to connect but it is some sort of authentication or protocol issue cause the server is just dropping the connection automatically. If anyone knows why please help me out.
    Last edited by rfxcasey; 07-21-2013 at 11:29 AM.

  3. #13
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    okay, i finally got my puppy 4.2 to run a friggin ssh daemon and actually accept logins. in the end, i relied wholly on PET packages from the official sources (usually a good idea).

    so basically i reboot my Live Puppy VM, so that i was sure i had a pristine state (i don't save any settings to a pup file or whatever).

    then once at the desktop, i install Dillo, then download these files from the official Puppy 4 repo:

    Code:
    openssh-5.1p1-SSHD+Dev.pet
    openssh-5.1p1-client.pet
    openssl-0.9.8e.pet
    openssl_DEV-0.9.8e.pet
    though you could more easily grab them with wget in a terminal (that's all dillo is doing anyway). i downloaded them to /tmp.

    then i fired up Puppy Package Manager, and installed each of these four packages one at a time, using the "find a PET to install from hard drive" option. i installed them in this order:

    Code:
    openssl
    openssl_DEV
    openssh-5.1p1-client
    openssh-5.1p1-SSHD+Dev
    not sure if the order makes a diff, or if all of those are necessary, but i'm recording everything i did.

    then i ran the two commands to add the sshd group and user.

    then i fired up the daemon like this:
    Code:
    /usr/sbin/sshd -D
    i ran it in the foreground so i could monitor connections.

    then from another machine, i logged into it:

    Code:
    ssh root@puppy_ip_address
    the root password by default is "woofwoof".

    see if that works for you. i think for me it was the openssl_DEV package, but right now, i'm too tired to research...

  4. #14
    Just Joined!
    Join Date
    Sep 2009
    Posts
    16
    Thanks for the reply atreyu. I'll give it a shot when I get home from work and let you know the status. I didn't find too much pertinent information on the matter so I really do appreciate the help.

  5. #15
    Just Joined!
    Join Date
    Sep 2009
    Posts
    16
    Ok, update. Did like you said, didn't work, but.... I ran sshd in debug mode and here is the output when I try to connect from my Windows machine using Putty.
    Code:
    [root@Arcade:/usr/sbin]/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.
    Server listening on 0.0.0.0 port 22.
    socket: Address family not supported by protocol
    debug1: Server will not fork when running in debugging mode.
    debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
    debug1: inetd sockets after dupping: 3, 3
    Connection from 192.168.0.190 port 51020
    debug1: Client protocol version 2.0; client software version PuTTY_Release_0.62
    debug1: no match: PuTTY_Release_0.62
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_5.1
    debug1: permanently_set_uid: 1001/3
    debug1: list_hostkey_types: ssh-rsa,ssh-dss
    sshd: [net]: symbol lookup error: sshd: [net]: undefined symbol: EVP_Cipher
    debug1: do_cleanup
    [root@Arcade:/usr/sbin]
    The 'Address family not supported by protocol' seems a bit troubling but I'm thinking that is because there is an attempt at a IPv6 as I haven't added the switch to disable it. I don't think that's the main issue but what I do think the problem is would be 'sshd: [net]: symbol lookup error: sshd: [net]: undefined symbol: EVP_Cipher' which is kind of obvious as its the last debug entry before killing the sshd process completely it seems. I also remember getting a error a while back when generating the ssh1 key to the same effect mentioning EVP_Cipher. I figured I'd be using ssh2 anyway so I disregarded it.

    UPDATE: Ok, just to document what I've done. Trying to get rid of the 'EVP_Cipher' error I deleted and regenerated the public keys in ~/.ssh.
    Following steps 1 and 2 of this tutorial:
    HTML Code:
    https://help.github.com/articles/generating-ssh-keys
    Then, for whatever reason, I copied the files generated to my /etc/ssh directory though this was probably totally unnecessary.

    Next I noticed I was missing 'openssl-0.9.8e.pet' so I downloaded and installed it.

    Rebooted the machine. Went to start sshd with usr/sbin/sshd -d but it was already running which hadn't been happening before. Tried to connect with Putty and got a dialog to accept rsa key "Wooo Hoooo!" followed by:
    Code:
    Using username "root".
    root@192.168.0.115's password:
    Attempted to login as root with password 'woofwoof' but access is denied, so its working I just don't know the freaking password I think. Tried all caps but no good.
    Last edited by rfxcasey; 07-23-2013 at 08:25 PM.

  6. #16
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Quote Originally Posted by rfxcasey View Post
    what I do think the problem is would be 'sshd: [net]: symbol lookup error: sshd: [net]: undefined symbol: EVP_Cipher' which is kind of obvious as its the last debug entry before killing the sshd process completely it seems. I also remember getting a error a while back when generating the ssh1 key to the same effect mentioning EVP_Cipher.
    yeah, the EVP cipher error comes from a call to a function in a file that is missing, in a standard install, i think (like mine was, anyway). my theory was that the openssl_DEV package contained these file(s), and the following command makes me definitely think so:

    Code:
    # grep -i EVP_CIPHER $(cat /root/.packages/openssl_DEV-0.9.8e.files)|wc -l
    209
    Attempted to login as root with password 'woofwoof' but access is denied, so its working I just don't know the freaking password I think. Tried all caps but no good.
    are you sure root is permitted to log in? check the sshd_config file.

    if that's not it, you can always change the root password. open an rxvt terminal in Puppy, and run the 'passwd' command. you should already be root, so it will prompt you to enter root's password (twice). then try to ssh in. i just tried that and it worked, too.
    Last edited by atreyu; 07-24-2013 at 01:20 AM. Reason: made blah clearer

  7. #17
    Just Joined!
    Join Date
    Sep 2009
    Posts
    16
    Ah, brilliant! Silly me, I was so engrossed in this I didn't even think to change the root password which is one of the few things I actually know how to do. Yes, 'permitrootlogon' or whatever it is exactly is un commented and set to yes. Regardless I am light years ahead of where I was before your help so thanks again. Hopefully this will be all downhill from here on out. It's taken WAY too long to get this sshd working properly but I guess if I learned something I can just chalk it up to part of the growing process. I'll let you know when I have full access.

  8. #18
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Quote Originally Posted by rfxcasey View Post
    Yes, 'permitrootlogon' or whatever it is exactly is un commented and set to yes.
    hmm...then i would guess it is that the root password has been changed. that or PAM is screwed up, too or something.

    I'll let you know when I have full access.
    yes, keep us posted!

  9. #19
    Just Joined!
    Join Date
    Sep 2009
    Posts
    16
    Ok, something strange is going on. I changed the root password on my Puppy machine but when I go to log in after entering user name and password I don't get a command prompt. All I get is the cursor under the password statement and that's it. I killed the process and tried to start manually through /usr/sbin/sshd -d so I can get some debugging but when I try to connect like that I still get the symbols lookup error and Puppy instantly drops the connection to Putty on my Win machine with 'Connection refused'. If I reboot and let sshd start itself then I can connect but as mentioned above only get a cursor after the password is entered, no prompt.

    Update: Something even stranger, I rebooted my Puppy again and tried to log in with Putty and can you believe it, it actually gave me a # prompt albeit with a message 'Type 'xwin' to start X, or 'xorgwizard' to run the Xorg Video Wizard' as if x crashed, the other thing is if I try to do a 'shutdown' command I get somthing to the effect of 'gtk could not open display' so it seems like Puppy is trying to push an x server desktop environment through the ssh terminal connection. This gets better by the minute. Not really sure what that is all about but I can browse the directories on my Pup so its not all bad. Just don't understand why it didn't work the first time I rebooted which is a bit troubling. I'll have to test more.
    Last edited by rfxcasey; 07-24-2013 at 02:03 PM.

  10. #20
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Quote Originally Posted by rfxcasey View Post
    Update: Something even stranger, I rebooted my Puppy again and tried to log in with Putty and can you believe it, it actually gave me a # prompt albeit with a message 'Type 'xwin' to start X, or 'xorgwizard' to run the Xorg Video Wizard' as if x crashed, the other thing is if I try to do a 'shutdown' command I get somthing to the effect of 'gtk could not open display' so it seems like Puppy is trying to push an x server desktop environment through the ssh terminal connection. This gets better by the minute. Not really sure what that is all about but I can browse the directories on my Pup so its not all bad. Just don't understand why it didn't work the first time I rebooted which is a bit troubling. I'll have to test more.
    The 'xwin' message is nothing to worry about. some login script is detecting that the DISPLAY variable is not set, i guess, and is offering to set it for you. obviously, you don't want to run 'xwin' in a remote shell.

    as to running 'shutdown' remotely, the problem there is that puppy has replaced the shutdown prog with a script that supports various different shutdown methods, and they are served via a graphical tool; gtkdialog3. if you want to see it, export the display on your remote machine. you can either do it by using the -Y arg with ssh, e.g.:

    Code:
    ssh -Y root@puppy_ip_address
    and that should set the DISPLAY variable on the puppy machine. if that doesn't work, you can set the DISPLAY variable manually, once you've remoted into the puppy box, e.g.:

    Code:
    export DISPLAY=x.x.x.x:y.z
    where x.x.x.x is the ip address of your local X server machine, and y.z is the display number (usually 0.0 or 1.0). you can just look at the DISPLAY variable of your local machine first.

    then if it is set correctly, when you call "shutdown", the graphical menu should pop up. alternatively, you could call the /sbin/shutdown and /sbin/reboot commands, which appear to work as they normally do. they probably don't do any nice system state saving or anything, though.

Page 2 of 3 FirstFirst 1 2 3 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •