connect as a root by SSh

[taboo]

im in my house and my knoppix is at university.. how can i get connected to knoopix as a root with ssh?? ki have an user account and i can log as user, but never like a root, (had change my root password)!!! i need to enter with root privileges!!!!
thanks

[OErjan]

If i was you i would use su instead to become root.
login as usual and then su - thEn hit enter, type the root password then enter again, you are now ROOT!
most smart persons do NOT alow direct root access over telnet, ssh... it is not a path traveled by the wise.

[Cuddles]

im in my house and my knoppix is at university.. how can i get connected to knoopix as a root with ssh?? ki have an user account and i can log as user, but never like a root, (had change my root password)!!! i need to enter with root privileges!!!!
thanks

taboo,

I am a little confused, are you trying to connect to your "university" computer from your "home" computer? Or are you trying to get information on your "home" computer to be used on your "university" computer? Or, are you trying to connect as root, or not, because you changed the root password? About the only thing I can understand about your posted issue, is, that you need to be root.

Your subject line states you want to connect "by ssh" as root, that is quite simple, follow the directions in man ssh -=- it expains how you can connect to a remote Linux system either by a user or by root. The problem is, you will need access to both systems to make "the connection".

If all you are trying to do is "be root", then, OErjan has you covered in his response.

If you are attempting to use ssh to remotely login in as root, to another system, and through an "open" line network - i.e. dialup - this, as OErjan has stated, is not a secure network setup. I do the root ssh thing, but, only, on a "trusted", "firewalled", "secure", "local" network. I am quite sure that, even with all of this, it is still not the best, or safest, thing to be doing. Our "network" is using hard-wired network connections, two systems with a "cross-over" cable between them, no other "local" system has "local" connections with these two systems. I have a firewall protection that locks down any outside connections, but, allows only these two systems the ability to connect with each other. And, I do, run a ssh root access between these two systems, as well as a shared printer, and shared / (root) and /home partitions. If you are trying to do the ssh thing, the man pages show you can use this "connection" as root, or any "user" that is on "both" systems. In other words, if user "cuddles" exists on both systems, user "cuddles" can be made to use ssh to remotely login to the other system. Running a "user" through ssh is a lot safer, and, if the user has the ability to "become" root, on both systems, through the use of su, they can run that on the other system, and still become root, when they need it.

One of the biggest things, about Linux, is, the use of "root" when you need it, and, not, when you dont. This "ability" can be "locked down" from users that do not need root, and allowed, for those, who do need it. It would be a lot safer to run a remote user, even through ssh, as a "user", first, and then, if need be, that user can become root at the remote system, if they need to be. I only have the root ssh running becuase I am running on a "trusted" network, and, I am sure of what systems can, and cant, connect. In an environment where you have a lot of unknowns, and possible connections, this may not be something you want to do.

Just my thoughts,
Ms. Cuddles

[RoyalMail]

The ssh thing is great! One point; the first 's' in ssh stands for secure! Lots of handshaking and public/private key generation goes on behind the scenes. You need to have ssh servers and clients running at both ends, then (in a Konsole) issue 'ssh <username>@<myuniversity.ac.us>' or even the IP of your Uni network if DNS is not available on you home machine (best nslookup to get the IP, then stick that in your /etc/hosts file). Once logged onto your Uni network, issue the 'su' command and log into the root account (assuming you have privileges to do that).

Of course if the Uni IT dept has any sense they will not allow this because of possible insecurity at your house!

Regds, RM.

[Dave_Bechtel]

> You need to have ssh servers and clients running at both ends

Actually only the computer you're logging into remotely has to have an ssh server running; the client side only needs an ssh client.

The ssh thing is great! One point; the first 's' in ssh stands for secure! Lots of handshaking and public/private key generation goes on behind the scenes. You need to have ssh servers and clients running at both ends, then (in a Konsole) issue 'ssh <username>@<myuniversity.ac.us>' or even the IP of your Uni network if DNS is not available on you home machine (best nslookup to get the IP, then stick that in your /etc/hosts file). Once logged onto your Uni network, issue the 'su' command and log into the root account (assuming you have privileges to do that).

Of course if the Uni IT dept has any sense they will not allow this because of possible insecurity at your house!

Regds, RM.

[Cuddles]

RoyalMail,

True that ssh does "secure" communication, I had read the man pages for ssh, a way back, and didnt want to "give out" false information, so... Here are some, excerpts of the man pages:

ssh (SSH client) is a program for logging into a remote machine and for
     executing commands on a remote machine.  It is intended to replace rlogin
     and rsh, and provide secure encrypted communications between two
     untrusted hosts over an insecure network.  X11 connections and arbitrary
     TCP/IP ports can also be forwarded over the secure channel.

     ssh connects and logs into the specified hostname (with optional user
     name).  The user must prove his/her identity to the remote machine using
     one of several methods depending on the protocol version used.

Here is where it gets tricky... It all depends on what method, that will depend on what "secure" is...

SSH protocol version 1 (First example)
... This form of authentication alone is normally not allowed by
the server because it is not secure.

Most of the time, when you want to connect two systems, remotely, chances are, as I did, you will go with the RSA method. This is explained, and examples given, within the man pages for ssh, and what, I think, RoyalMail, was describing. It provides a form of "trust", over a "secure" connection, under "untrusted" lines, and such. The two systems "communicate", to each other, different forms of a "key". One part of the "key" is provided by the "server", and only known by the "server", the other part, from the "client", both parts of the "key" are then "put together" to form the "correct key", that "completed key", is then tested for "access" to the "server". All of this, is done encrypted, and again, each systems doesnt contain the whole key, thus, no one can "fake" any part of the key. This kind of secure connection, can be seen as a "safety box" at a bank. Where one person has one key, and the bank, has the other key. The box can not be openned, unless both keys are inserted, and the correct keys.

As with any connection, remotely, secure, or not, keeping your keys safe, is paramount. When I went through the setting up of ssh on my own two systems, I had to "copy" a key, from one system to the other. My guess here, is, that, if an "attacker" can obtain that "copy" as well, they could also gain "trusted" access, as well. My thinking is, if the system isnt "secure" in the first place, using a "secure" remote connection, will only allow an "untrusted" connection, with a "trusted" access, which, may, only add insult to injury, when trying to make a "secure" system. To re-use my previous analogy; if the bank allowed everyone access to the "banks key", the security of the safety box is in jeopardy, if the user allowed everyone access to the "personal key", the same holds true.

Just my thoughts,
Ms. Cuddles