Re: Philosophy: connecting to a Linux server
I thought lime disease was from squeezing too much of the juice into a gin tonic and a backtick there would make one fall off the barstool - must fight such a dangerous affliction !! Rob van der Heij [EMAIL PROTECTED] m To Sent by: Linux on LINUX-390@VM.MARIST.EDU 390 Port cc [EMAIL PROTECTED] IST.EDU Subject Re: Philosophy: connecting to a Linux server 04/06/2007 01:56 AM Please respond to Linux on 390 Port [EMAIL PROTECTED] IST.EDU On 4/5/07, John Summerfield [EMAIL PROTECTED] wrote: Anyway, HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Including ticks, of course. Sure, since ticks may transfer lime disease. Would backticks help fight it? Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Apr 6, 2007, at 8:53 AM, [EMAIL PROTECTED] wrote: I thought lime disease was from squeezing too much of the juice into a gin tonic and a backtick there would make one fall off the barstool - must fight such a dangerous affliction !! That condition usually indicates an insufficiency of gin. Rest assured, I'm doing my part to combat it. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On 4/5/07, John Summerfield [EMAIL PROTECTED] wrote: Anyway, HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Including ticks, of course. Sure, since ticks may transfer lime disease. Would backticks help fight it? Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
Adam Thornton wrote: On Apr 5, 2007, at 4:13 PM, John Summerfield wrote: Anyway, HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Including ticks, of course. Unless you have REALLY pointy shoes, stamping doesn't really help with ticks. I myself usually use the pliers on my Leatherman. I wonder what effect this has on your Karma ! --Ivan Given that he owns a number of really large dogs, and at least one is female (I think), he's much more likely to be overrun by his dogma if he doesn't... -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On 4/6/07, David Boyes [EMAIL PROTECTED] wrote: Unless you have REALLY pointy shoes, stamping doesn't really help with ticks. I myself usually use the pliers on my Leatherman. Can you mail them to me please? I need to have 360,000 of them in the fall to undo DST. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
Ivan Warren wrote: Adam Thornton wrote: On Apr 5, 2007, at 4:13 PM, John Summerfield wrote: Anyway, HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Including ticks, of course. Unless you have REALLY pointy shoes, stamping doesn't really help with ticks. I myself usually use the pliers on my Leatherman. I wonder what effect this has on your Karma ! Not much, he'll continue right on picking at ticks. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
Adam Thornton wrote: On Apr 3, 2007, at 4:26 PM, Mark Post wrote: On Tue, Apr 3, 2007 at 5:14 PM, in message [EMAIL PROTECTED] , Marcy Cortes [EMAIL PROTECTED] wrote: Hey cool. It worked. Thanks Mark. I replaced the other 1: line with this line below. But it doesn't have the little line in the console that makes us feel all warm and fuzzy that the service finished booting correctly: That is Welcome to SUSE LINUX Enterprise Server 9 (s390x) - Kernel 2.6.5- 7.283- s390x Any idea how I can keep that there? You can create /root/.bashrc and put this in it: #!/bin/sh echo Welcome to `head -n1 /etc/SuSE-release` - Kernel `uname -r` YOU TOO CAN HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Seriously, folks. It's Linux, not Solaris: /bin/sh is POSIX- compliant (boy, was I surprised last week when some of my POSIX scripts barfed-and-died on. So: #!/bin/sh I'd not have that line in ~/.bashrc or ~/.bash_profile or ~/.profile it's not exactly a script. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
#!/bin/sh I'd not have that line in ~/.bashrc or ~/.bash_profile or ~/.profile it's not exactly a script. Yeah, given that you're using it to set environment variables, you probably don't want it running in its own shell, do you? So, yep, just source it. In that case, won't the shebang just turn into a comment? Anyway, HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
Adam Thornton wrote: #!/bin/sh I'd not have that line in ~/.bashrc or ~/.bash_profile or ~/.profile it's not exactly a script. Yeah, given that you're using it to set environment variables, you probably don't want it running in its own shell, do you? So, yep, just source it. In that case, won't the shebang just turn into a comment? Probably, but let's not confuse the peanut gallery. Anyway, HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Including ticks, of course. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
Bruce Hayden wrote: Here is something I've been using on SLES that I got off this list long long ago. It actually makes the console do a normal login, so you get the motd message and it even shows up as a login when you run the who or w commands. However, it still won't display the /etc/issue file unless you put cat /etc/issue in the script below. In your inittab, replace the mingetty line for ttyS0 with: 1:2345:respawn:/sbin/agetty -L -n -l /sbin/consoleshell 9600 /dev/ttyS0 dumb Then create a script named /sbin/consoleshell with the following contents, and be sure to make it executable! #!/bin/sh cat /etc/issue exec /bin/login -f root or similar -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Apr 5, 2007, at 4:13 PM, John Summerfield wrote: Anyway, HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Including ticks, of course. Unless you have REALLY pointy shoes, stamping doesn't really help with ticks. I myself usually use the pliers on my Leatherman. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
Adam Thornton wrote: On Apr 5, 2007, at 4:13 PM, John Summerfield wrote: Anyway, HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Including ticks, of course. Unless you have REALLY pointy shoes, stamping doesn't really help with ticks. I myself usually use the pliers on my Leatherman. I wonder what effect this has on your Karma ! --Ivan -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On 4/4/07, Vic Cross [EMAIL PROTECTED] wrote: This OpenSSH patch[1] is (IMHO) in need of more airplay. AFAIK Gentoo is the only distro that includes it as part of their OpenSSH package (I don't have SLES10 or RHEL5 nearby, they may have finally picked it up). Yes, it does solves some problems, which is why I wanted to use it. We ended up removing all passwords and only allow authentication by cryptic keys. The root password was also gone, and access was entirely through sudo (without password obviously -the LDAP database also defined which users on what system were in the group that could use sudo). And managed routine processes that needed root access would go through the SCIF interface to the already logged-on root account. Suppose the primary reason of OpenSSH-LPK not being mainstream is that it is a bit of a quick hack. The author did some ad-hoc schema to stuff the public key into LDAP. What you really want is to have a user certificate in the database (the public key signed by some trusted authority). This avoids the need to trust the LDAP server (or fall-back mirror) on its blue eyes only. The other part that I would like to see is to hold the host public keys as well, instead of every user end up with copies in his private storage (and not being surprised when they don't match). For shops using LDAP for authentication, it makes a lot of sense -- you can have all your user detail in a sturdy LDAP directory, and using appropriate filter configurations for nss_ldap and pam_ldap you can still provide per-server access control[2]. The 'uploading' of the key can be done with any of the LDAP administration tools, such as phpldapadmin, LAM, or Luma -- the authorised key is just an ASCII text field so cut-and-paste will work. I know some installations automated maintaining copies of authorized_keys (at least for root) by replication from a master so that all required public keys were there when needed. But the security policy was that the user should be able to have his public key removed when compromised. That's hard to do when you don't know where it is kept (and a compromised system may be modified not to remove the key when the master is changed). Having it in one place makes it possible for the user to manage it. Another method that works is to share user home directories via NFS. When a user logs on to a system their home directory is automounted, which makes their ~/.ssh/ and consequently their authorised keys available. This caused a problem for us with developers who could have root access on their development system but not on production servers. If they could mount my home directory on their development system they could put extra keys in my authorized_keys file and then have that automount on production systems as well to gain root access. It may be helpful to distinguish between daily use and exceptional access to systems. I worked with folks who moved all their daily system admin stuff into cfengine and other managed processes. That avoided the need for support staff to login on production systems, and doing so would need to be justified by a problem ticket. If you can get that far the requirements are different. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server (fwd)
On 4/4/07, shogunx [EMAIL PROTECTED] wrote: Oh my. If this list is set to not echo posts back to the sender, then you all have my sincerest apologies. When I did not see my post, I assumed someone did not like my commentary, and I saw a similar script as the one I posted. Given that assumption, I assumed I was speaking to whomever did not allow said post through. Sorry all! I've run into situations like that before. I suppose there would be a point in having the default as REPRO for new subscribers to the list. Not sure we can, but alternatively some hints in the welcome note could help (Harry?). You could also set the option yourself or check on the archives web pages. We do not moderate the posts to the list. If necessary we point someone to Adams cough syrup, or at worst tell the poster in public that his behavior was not appropriate. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Adam Thornton Sent: Tuesday, April 03, 2007 5:18 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Philosophy: connecting to a Linux server snip YOU TOO CAN HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Seriously, folks. It's Linux, not Solaris: /bin/sh is POSIX- compliant (boy, was I surprised last week when some of my POSIX scripts barfed-and-died on. So: #!/bin/sh echo Welcome to $(head -n1 /etc/SuSE-release) - Kernel $(uname -r) No, it doesn't make much difference here. But $() is nestable, and backticks are not without very careful escaping, and they make the logical grouping of the command line much, much clearer. You also don't have to escape embedded double quotes with $() command substitution. It's a good habit to cultivate. Adam And people don't mistake $(...) for a ' as I have seen in magazines where some copy editor replaced the back tick ` with a '. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Apr 4, 2007, at 2:30 AM, Rob van der Heij wrote: I know some installations automated maintaining copies of authorized_keys (at least for root) by replication from a master so that all required public keys were there when needed. But the security policy was that the user should be able to have his public key removed when compromised. That's hard to do when you don't know where it is kept (and a compromised system may be modified not to remove the key when the master is changed). Having it in one place makes it possible for the user to manage it. This is what we do currently. However, we're a small enough organization that the number of key changes is fairly small, and the amount of log output and manual file inspection I have to keep tabs on to determine that cfengine really is doing what I asked it to is reasonable. If I had to manage thousands of machines and hundreds of users with privileged access this would probably be infeasible. It may be helpful to distinguish between daily use and exceptional access to systems. I worked with folks who moved all their daily system admin stuff into cfengine and other managed processes. That avoided the need for support staff to login on production systems, and doing so would need to be justified by a problem ticket. If you can get that far the requirements are different. For what it''s worth, I really don't recommend cfengine. It's not that it doesn't work--once you have it set up it works tolerably well--but that its error messages range from unhelpful to pathologically mendacious. Specifically, I can't find the target directory should not masquerade as a key authentication failure. I have heard that puppet is nice for solving the same problem. However, I went to LISA last year with high hopes of finding a solution I liked, and was disappointed to learn that the whole area of configuration management is a giant minefield of competing philosophies. The next major revision I do will probably use puppet for file distribution and scheduled process maintenance (like, HUP the nameserver if the master zone file has changed), but just use good old makefiles to push out all other tasks (like user provisioning or deprovisioning). Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server (fwd)
I suppose there would be a point in having the default as REPRO for new subscribers to the list. Not sure we can, but alternatively some hints in the welcome note could help (Harry?). It's a list header option (cleverly labeled Default-Options=). Harry would just need to set it and (optionally) update all the member entries. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
Here is something I've been using on SLES that I got off this list long long ago. It actually makes the console do a normal login, so you get the motd message and it even shows up as a login when you run the who or w commands. However, it still won't display the /etc/issue file unless you put cat /etc/issue in the script below. In your inittab, replace the mingetty line for ttyS0 with: 1:2345:respawn:/sbin/agetty -L -n -l /sbin/consoleshell 9600 /dev/ttyS0 dumb Then create a script named /sbin/consoleshell with the following contents, and be sure to make it executable! #!/bin/sh exec /bin/login -f root Another thing I've done is replace /sbin/sulogin with this script: #!/bin/bash #Always log in without asking for a password HOME=/root exec -l /bin/bash --login --noprofile Then, if you go to single user mode or have an error, you are automatically in a root shell. Now, you can either remove or lock the root password and not worry about who knows it.. On 4/3/07, Marcy Cortes [EMAIL PROTECTED] wrote: Hey cool. It worked. Thanks Mark. I replaced the other 1: line with this line below. But it doesn't have the little line in the console that makes us feel all warm and fuzzy that the service finished booting correctly: That is Welcome to SUSE LINUX Enterprise Server 9 (s390x) - Kernel 2.6.5-7.283-s390x Any idea how I can keep that there? Marcy Cortes -- Bruce Hayden IBM Global Technology Services, System z Linux Endicott, NY -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On 4/3/07, shogunx [EMAIL PROTECTED] wrote: That sounds like a recipe for disaster unless you have the tightest of physical security. As Mark points out, physical security is not really the issue here. In most mainframe installations you will find that physical access to the hardware is very restricted and controlled. The virtual raised floor that z/VM provides uses logical access control to manage that virtual hardware. Those controls are much more granular and easier to keep up-to-date. I don't believe security becomes more tight by additional doors that use the same key to unlock. Or like in many installations, a single master key for all locks that is shared amongst staff members for daily operation. One of the basic rules is to separate authentication (who are you) and access control (what can you access). Sharing a (common) root password breaks that rule even when you change it on a regular basis in a way that is not predictable. We found it more productive to allow staff members to authenticate themselves for root access to the server, and audit that access. You get much of that with RACF and a spooled console to a central archive. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
McKown, John wrote: This is more generic to Linux than specific to z/Linux, but perhaps you will indulge me. I am curious as to the best practice to allow a user to connect to a Linux server. 1) Telnet and use a normal userid/password - nope, ain't gonna happen. 2) SSH and use a normal userid/password - well, maybe. At least it is encrypted. 3) SSH and a userid plus ssh-keygen certificate (what is that called?) 4) Xvnc??? Not really; the authors of realvnc say the password encryption's trivially broken. vnc over ssh is fine. 3) How do you give the key to the other person? USB thumb drive? Email shudder? I guess that emailing a public key would not be bad. True? My public key gives me access to your system. Anyone want it? Do tell me the details of how to use my new account:-) More generally, email can be secure; you encrypt it and you sign it. Send it to the wrong person, all she gets is a mess of digits. Someone try to forge my mail, they need my private key. 4) Should the administrator keep copies of everybody's ssh-keygen file in a secure location (USB thumb drive?) Or should ssh-keygen be rerun in the case of a problem? I would have a procedure in place, but I don't think it would include backups. Regenerating, yes. 6) In any of the above, should logging on with a password be disabled by removing the password from /etc/passwd or /etc/shadow (I forget how to do that, off hand - I can look it up.)? 7) I think the above removes the ability to do an su to the userid by any other user than root. True? I use sudo, configured to use a person's own password. Then, sudo passwd -l root and root's password us unusable. Note that sudo with one's own password grants access to any account. OTOH, keeping root out of other's accounts needs some work too. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not reply off-list -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
That sounds like a recipe for disaster unless you have the tightest of physical security. Not in a virtual machine. Access to the console is protected by the VM security management system, which is usually well-monitored and well-instrumented. If you can get to the console, the machine is completely compromised anyway (a guest can always look at it's own virtual storage or just hit PA1 to kill the whole mess), so there's no real protection offered by not having the root user automagically logged in. I still don't like it much as general practice, but it's not the major risk it would be in the discrete server community. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
Hey cool. It worked. Thanks Mark. I replaced the other 1: line with this line below. But it doesn't have the little line in the console that makes us feel all warm and fuzzy that the service finished booting correctly: That is Welcome to SUSE LINUX Enterprise Server 9 (s390x) - Kernel 2.6.5-7.283-s390x Any idea how I can keep that there? Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Monday, April 02, 2007 21:45 To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] Philosophy: connecting to a Linux server On Mon, Apr 2, 2007 at 11:55 PM, in message [EMAIL PROTECTED], Marcy Cortes [EMAIL PROTECTED] wrote: Rick wrote: If you have an automatic login of root on the console, that should provide enough escape for when all other things fail. How are you setting that up? I've looked and it wasn't obvious to me. This entry in /etc/inittab is how I do it in Slack/390: 1:12345:respawn:/bin/bash -i Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Tue, 3 Apr 2007, Marcy Cortes wrote: Hey cool. It worked. Thanks Mark. I replaced the other 1: line with this line below. But it doesn't have the little line in the console that makes us feel all warm and fuzzy that the service finished booting correctly: That is Welcome to SUSE LINUX Enterprise Server 9 (s390x) - Kernel 2.6.5-7.283-s390x Any idea how I can keep that there? make a script: #!/bin/bash echo Welcome to (Novell is a sellout) LINUX Enterprise Server 9 (s-390x) - Kernel `uname -r` /bin/bash and call the script instead of /bin/bash from inittab substitute SUSE above if you like. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Monday, April 02, 2007 21:45 To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] Philosophy: connecting to a Linux server On Mon, Apr 2, 2007 at 11:55 PM, in message [EMAIL PROTECTED], Marcy Cortes [EMAIL PROTECTED] wrote: Rick wrote: If you have an automatic login of root on the console, that should provide enough escape for when all other things fail. How are you setting that up? I've looked and it wasn't obvious to me. This entry in /etc/inittab is how I do it in Slack/390: 1:12345:respawn:/bin/bash -i Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Tue, Apr 3, 2007 at 5:14 PM, in message [EMAIL PROTECTED], Marcy Cortes [EMAIL PROTECTED] wrote: Hey cool. It worked. Thanks Mark. I replaced the other 1: line with this line below. But it doesn't have the little line in the console that makes us feel all warm and fuzzy that the service finished booting correctly: That is Welcome to SUSE LINUX Enterprise Server 9 (s390x) - Kernel 2.6.5- 7.283- s390x Any idea how I can keep that there? You can create /root/.bashrc and put this in it: #!/bin/sh echo Welcome to `head -n1 /etc/SuSE-release` - Kernel `uname -r` Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Apr 3, 2007, at 4:26 PM, Mark Post wrote: On Tue, Apr 3, 2007 at 5:14 PM, in message [EMAIL PROTECTED] , Marcy Cortes [EMAIL PROTECTED] wrote: Hey cool. It worked. Thanks Mark. I replaced the other 1: line with this line below. But it doesn't have the little line in the console that makes us feel all warm and fuzzy that the service finished booting correctly: That is Welcome to SUSE LINUX Enterprise Server 9 (s390x) - Kernel 2.6.5- 7.283- s390x Any idea how I can keep that there? You can create /root/.bashrc and put this in it: #!/bin/sh echo Welcome to `head -n1 /etc/SuSE-release` - Kernel `uname -r` YOU TOO CAN HELP STAMP OUT BACKTICKS IN OUR LIFETIME. Seriously, folks. It's Linux, not Solaris: /bin/sh is POSIX- compliant (boy, was I surprised last week when some of my POSIX scripts barfed-and-died on. So: #!/bin/sh echo Welcome to $(head -n1 /etc/SuSE-release) - Kernel $(uname -r) No, it doesn't make much difference here. But $() is nestable, and backticks are not without very careful escaping, and they make the logical grouping of the command line much, much clearer. You also don't have to escape embedded double quotes with $() command substitution. It's a good habit to cultivate. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Apr 3, 2007, at 5:17 PM, Adam Thornton wrote: Seriously, folks. It's Linux, not Solaris: /bin/sh is POSIX- compliant (boy, was I surprised last week when some of my POSIX scripts barfed-and-died on. Er, I seem to have forgotten what I was doing there. barfed-and-died on Solaris 10) is what I meant. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
That's because on Linux, /bin/sh is typically just a symlink to /bin/bash. I would imagine if you were to use bash on your Solaris machine the result would be what you were expecting. And vice versa, if you were to actually use the real bourne shell on Linux, it would fail. -Sam -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Adam Thornton Sent: Tuesday, April 03, 2007 6:20 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Philosophy: connecting to a Linux server On Apr 3, 2007, at 5:17 PM, Adam Thornton wrote: Seriously, folks. It's Linux, not Solaris: /bin/sh is POSIX- compliant (boy, was I surprised last week when some of my POSIX scripts barfed-and-died on. Er, I seem to have forgotten what I was doing there. barfed-and-died on Solaris 10) is what I meant. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server (fwd)
oh, and by the way, thakns for the censorship, and snarfing my script as your own. dick. sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ -- Forwarded message -- Date: Tue, 3 Apr 2007 17:48:24 -0400 (EDT) From: shogunx [EMAIL PROTECTED] To: Linux on 390 Port LINUX-390@VM.MARIST.EDU Subject: Re: Philosophy: connecting to a Linux server In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 3 Apr 2007, Marcy Cortes wrote: Hey cool. It worked. Thanks Mark. I replaced the other 1: line with this line below. But it doesn't have the little line in the console that makes us feel all warm and fuzzy that the service finished booting correctly: That is Welcome to SUSE LINUX Enterprise Server 9 (s390x) - Kernel 2.6.5-7.283-s390x Any idea how I can keep that there? make a script: #!/bin/bash echo Welcome to (Novell is a sellout) LINUX Enterprise Server 9 (s-390x) - Kernel `uname -r` /bin/bash and call the script instead of /bin/bash from inittab substitute SUSE above if you like. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Monday, April 02, 2007 21:45 To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] Philosophy: connecting to a Linux server On Mon, Apr 2, 2007 at 11:55 PM, in message [EMAIL PROTECTED], Marcy Cortes [EMAIL PROTECTED] wrote: Rick wrote: If you have an automatic login of root on the console, that should provide enough escape for when all other things fail. How are you setting that up? I've looked and it wasn't obvious to me. This entry in /etc/inittab is how I do it in Slack/390: 1:12345:respawn:/bin/bash -i Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Apr 3, 2007, at 5:43 PM, Kielek, Samuel wrote: That's because on Linux, /bin/sh is typically just a symlink to /bin/bash. I would imagine if you were to use bash on your Solaris machine the result would be what you were expecting. And vice versa, if you were to actually use the real bourne shell on Linux, it would fail. The $() as a command substitution delimiter is guaranteed by POSIX. If a platform's /bin/sh is POSIX compatible--no matter whether or not it is actually bash--the construction will work. I submit that there is no reason to ship your system with a non- POSIX /bin/sh in the 21st century. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server (fwd)
On Tue, Apr 3, 2007 at 6:56 PM, in message [EMAIL PROTECTED], shogunx [EMAIL PROTECTED] wrote: oh, and by the way, thakns for the censorship, and snarfing my script as your own. dick. Were you directing this vitriol at anyone in particular? I can't say I've seen anyone engaging in censorship, nor anyone snarfing your script. Regardless, you might want to be a little more professional on the list in the future. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server (fwd)
That's the second obtuse comment I've seen out of you today. Clearly uncalled for. shogunx wrote: oh, and by the way, thakns for the censorship, and snarfing my script as your own. dick. sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
I guess all I was trying to indirectly point out was that this behaviour is caused by the fact that Solaris has the heirloom Bourne shell as /bin/sh (which existed prior to POSIX.2). By the way, the XPG version (/usr/xpg4/bin/sh) on Solaris does support $(). I do agree and wonder why at this point Sun doesn't either update it or move it out of the way (I'm sure some customers still need/want it) and put a POSIX.2 compliant shell in its place (bash?). -Sam -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Adam Thornton Sent: Tuesday, April 03, 2007 7:11 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Philosophy: connecting to a Linux server On Apr 3, 2007, at 5:43 PM, Kielek, Samuel wrote: That's because on Linux, /bin/sh is typically just a symlink to /bin/bash. I would imagine if you were to use bash on your Solaris machine the result would be what you were expecting. And vice versa, if you were to actually use the real bourne shell on Linux, it would fail. The $() as a command substitution delimiter is guaranteed by POSIX. If a platform's /bin/sh is POSIX compatible--no matter whether or not it is actually bash--the construction will work. I submit that there is no reason to ship your system with a non- POSIX /bin/sh in the 21st century. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Apr 3, 2007, at 6:46 PM, Kielek, Samuel wrote: I guess all I was trying to indirectly point out was that this behaviour is caused by the fact that Solaris has the heirloom Bourne shell as /bin/sh (which existed prior to POSIX.2). By the way, the XPG version (/usr/xpg4/bin/sh) on Solaris does support $(). I do agree and wonder why at this point Sun doesn't either update it or move it out of the way (I'm sure some customers still need/want it) and put a POSIX.2 compliant shell in its place (bash?). Or, you know, even the XPG4 one. I mean, really, it's not 1986 anymore (XPG4 would get us all the way to 1988!), and surely you can stick #!/usr/crusty/bin/sh on your shell scripts that really, really depend on something that's actually *different* in POSIX (which isn't much that I'm aware of). I like knowing that I have $() and semi- sane arithmetic with $(()). If I'm actually using bash-isms, requiring me to use /bin/bash is fine. But I think that in 2007 I really, really ought to be able to assume the 2001 POSIX standard will be implemented by the default shell found in /bin/sh. I understand that Solaris must go to some lengths to remain bug- compatible with its former self. But I had naively expected that things had gotten better since Solaris 2.5 when all the useful stuff was in /usr/ucb/bin. Now it's just in xpg4 or, more often. sfw. I think I've been thoroughly spoiled by GNU userland. I found myself installing tons of stuff from sunfreeware.com (yes, the same sfw) in order to get anything actually *done*. I've gotten used to little things, like --owner 0 --group 0 in tar (a GNU tar extension) to let me make owned-by-root tarballs for distribution without having to build them as root. I strongly suspect that NexentaOS might be the best thing ever: Solaris kernel, Debian userland. I haven't been successful in installing it under Parallels yet though. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server (fwd)
Oh my. If this list is set to not echo posts back to the sender, then you all have my sincerest apologies. When I did not see my post, I assumed someone did not like my commentary, and I saw a similar script as the one I posted. Given that assumption, I assumed I was speaking to whomever did not allow said post through. Sorry all! I've run into situations like that before. On Tue, 3 Apr 2007, Mark Post wrote: On Tue, Apr 3, 2007 at 6:56 PM, in message [EMAIL PROTECTED], shogunx [EMAIL PROTECTED] wrote: oh, and by the way, thakns for the censorship, and snarfing my script as your own. dick. Were you directing this vitriol at anyone in particular? I can't say I've seen anyone engaging in censorship, nor anyone snarfing your script. Regardless, you might want to be a little more professional on the list in the future. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Mon, 2007-04-02 at 16:11 +0200, Rob van der Heij wrote: We did it slightly different with an experimental patch to OpenSSH that allows for the public keys to be kept in LDAP. That means there's only one place where the public key is held. That LDAP server would allow the end-user to upload a (new) public key through some authenticated interface. And the Linux servers can trust that LDAP to provide the right public key. The same LDAP also gives user and group information for Linux to allow login. This OpenSSH patch[1] is (IMHO) in need of more airplay. AFAIK Gentoo is the only distro that includes it as part of their OpenSSH package (I don't have SLES10 or RHEL5 nearby, they may have finally picked it up). For shops using LDAP for authentication, it makes a lot of sense -- you can have all your user detail in a sturdy LDAP directory, and using appropriate filter configurations for nss_ldap and pam_ldap you can still provide per-server access control[2]. The 'uploading' of the key can be done with any of the LDAP administration tools, such as phpldapadmin, LAM, or Luma -- the authorised key is just an ASCII text field so cut-and-paste will work. Another method that works is to share user home directories via NFS. When a user logs on to a system their home directory is automounted, which makes their ~/.ssh/ and consequently their authorised keys available. I used to keep my private key on a USB-key, but convenience (or the lack thereof) was a barrier. I'm wondering if some little mobile-phone app that worked over IR or Bluetooth would be a substitute -- people sometimes take more care of these. ;) Cheerio, Vic Cross [1] Known as OpenSSH-LPK. Used to be hosted by the OpenDarwin project, but now seems to have new owners... There's a Trac at http://dev.inversepath.com/trac/openssh-lpk. [2] pam_ldap provides it's own function for access checking based on an attribute in LDAP, but we found it was better to use a filter in the nss_base_* settings. If you only use the pam_ldap setting, ALL accounts in LDAP show up as accounts on the system even though the users don't have access, which will confuse your auditors... Better to filter out the unauthorised accounts at the NSS level so they don't even show up. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Mon, 2007-04-02 at 16:11 +0200, Rob van der Heij wrote: We did it slightly different with an experimental patch to OpenSSH that allows for the public keys to be kept in LDAP. That means there's only one place where the public key is held. That LDAP server would allow the end-user to upload a (new) public key through some authenticated interface. And the Linux servers can trust that LDAP to provide the right public key. The same LDAP also gives user and group information for Linux to allow login. This is an excellent patch that needs a lot more airplay. I don't know why it's never been picked up by mainstream distros; Gentoo is the only one I know of that includes it (I don't have SLES10 and RHEL5 systems to check, though, they may have finally picked it up). Combined with the pam_ldap and nss_ldap configuration options[1] that allow you to restrict user accounts to a subset of all your hosts, you can have all your users in a single LDAP but still provide access only to certain hosts. On the general handling of SSH keys however, the important thing to remember is that the private key belongs to the USER (Rob and Adam have both implied this in their posts). Administering them centrally means that there are sysadmins that (literally) have everyone's keys[2]. You may find that some of your users would create their keys with a greater strength than your default policy might provide, and you shouldn't really tell your users that they have to make their key less safe than they want to. :) [1]ppaam_ldap -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server (fwd)
On Apr 3, 2007, at 7:10 PM, shogunx wrote: Oh my. If this list is set to not echo posts back to the sender, then you all have my sincerest apologies. When I did not see my post, I assumed someone did not like my commentary, and I saw a similar script as the one I posted. Given that assumption, I assumed I was speaking to whomever did not allow said post through. Sorry all! I've run into situations like that before. You need to SET REPRO to receive copies of your own postings. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
I just noticed there is a man page on solaris that details its standards compliance. Try 'man standards' for the somewhat lengthy details. Here is the bit I found most relevant: If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 conflicts with historical Solaris utility behavior, the original Solaris version of the utility is unchanged; a new version that is standard-conforming has been provided in /usr/xpg4/bin. For applications wishing to take advantage of POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 features, the PATH (sh or ksh) or path (csh) environment variables should be set with /usr/xpg4/bin preceding any other directories in which utilities specified by those specifications are found, such as /bin, /usr/bin, /usr/ucb, and /usr/ccs/bin. -Sam -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Adam Thornton Sent: Tuesday, April 03, 2007 8:04 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Philosophy: connecting to a Linux server On Apr 3, 2007, at 6:46 PM, Kielek, Samuel wrote: I guess all I was trying to indirectly point out was that this behaviour is caused by the fact that Solaris has the heirloom Bourne shell as /bin/sh (which existed prior to POSIX.2). By the way, the XPG version (/usr/xpg4/bin/sh) on Solaris does support $(). I do agree and wonder why at this point Sun doesn't either update it or move it out of the way (I'm sure some customers still need/want it) and put a POSIX.2 compliant shell in its place (bash?). Or, you know, even the XPG4 one. I mean, really, it's not 1986 anymore (XPG4 would get us all the way to 1988!), and surely you can stick #!/usr/crusty/bin/sh on your shell scripts that really, really depend on something that's actually *different* in POSIX (which isn't much that I'm aware of). I like knowing that I have $() and semi- sane arithmetic with $(()). If I'm actually using bash-isms, requiring me to use /bin/bash is fine. But I think that in 2007 I really, really ought to be able to assume the 2001 POSIX standard will be implemented by the default shell found in /bin/sh. I understand that Solaris must go to some lengths to remain bug- compatible with its former self. But I had naively expected that things had gotten better since Solaris 2.5 when all the useful stuff was in /usr/ucb/bin. Now it's just in xpg4 or, more often. sfw. I think I've been thoroughly spoiled by GNU userland. I found myself installing tons of stuff from sunfreeware.com (yes, the same sfw) in order to get anything actually *done*. I've gotten used to little things, like --owner 0 --group 0 in tar (a GNU tar extension) to let me make owned-by-root tarballs for distribution without having to build them as root. I strongly suspect that NexentaOS might be the best thing ever: Solaris kernel, Debian userland. I haven't been successful in installing it under Parallels yet though. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Apr 3, 2007, at 8:46 PM, Kielek, Samuel wrote: I just noticed there is a man page on solaris that details its standards compliance. Try 'man standards' for the somewhat lengthy details. Here is the bit I found most relevant: If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 conflicts with historical Solaris utility behavior, the original Solaris version of the utility is unchanged; a new version that is standard-conforming has been provided in /usr/xpg4/bin. For applications wishing to take advantage of POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 features, the PATH (sh or ksh) or path (csh) environment variables should be set with /usr/xpg4/bin preceding any other directories in which utilities specified by those specifications are found, such as /bin, /usr/bin, /usr/ucb, and /usr/ccs/bin. Well, at least they're honest about it and it's documented. And I guess if I were more familiar with Solaris, I'd have thought to look. Thanks. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Apr 2, 2007, at 8:45 AM, McKown, John wrote: 2) Or should the user do the ssh-keygen on his workstation, then give the public key to the administrator to put in the user's ~/.ssh/authorized_keys file? Yes. 3) How do you give the key to the other person? USB thumb drive? Email shudder? I guess that emailing a public key would not be bad. True? That's the whole point of public-key cryptography. The public key is *public*. 4) Should the administrator keep copies of everybody's ssh-keygen file in a secure location (USB thumb drive?) Or should ssh-keygen be rerun in the case of a problem? You remove the public key from authorized_keys, and generate a new pair. 5) Is there any way for the administrator to guarantee that the user uses a passphrase on his ssh-keygen key file? I can't find it Unknown, but I doubt it. The end user can always re-key access to his private key file, and (I think) change it to no password if he wants; this does not change the actual key, so the remote end doesn't know. 6) In any of the above, should logging on with a password be disabled by removing the password from /etc/passwd or /etc/shadow (I forget how to do that, off hand - I can look it up.)? Depends on what your local security policy is. Also depends on how you have PAM set up. I think it's generally a good idea to disable password-interactive logins, but it really depends on what you need to be able to do. 7) I think the above removes the ability to do an su to the userid by any other user than root. True? Removing the password certainly would. Adam -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
Hi, John. - Original Message Follows - From: McKown, John [EMAIL PROTECTED] To: LINUX-390@VM.MARIST.EDU Subject: Philosophy: connecting to a Linux server Date: Mon, 2 Apr 2007 08:45:53 -0500 This is more generic to Linux than specific to z/Linux, but perhaps you will indulge me. I am curious as to the best practice to allow a user to connect to a Linux server. 1) Telnet and use a normal userid/password - nope, ain't gonna happen. Very bad ideabut that doesn't stop some sites from using it:-) 2) SSH and use a normal userid/password - well, maybe. At least it is encrypted. You seem to be a bit reluctant to use SSH...is there a particular reason for this? SSH is the de-facto method for making a secure connection to a Linux system, I think. 3) SSH and a userid plus ssh-keygen certificate (what is that called?) Beats me 4) Xvnc??? Personally, I like option 3. But, when I think of security , I am a bit paranoid. The question then becomes: After the userid is set up, who does the ssh-keygen? 1) Should the system administrator logon to himself, then su to the new user, do the ssh-keygen then distribute the private key to the user? 2) Or should the user do the ssh-keygen on his workstation , then give the public key to the administrator to put in the user's ~/.ssh/authorized_keys file? 3) How do you give the key to the other person? USB thumb drive? Email shudder? I guess that emailing a public key would not be bad. True? 4) Should the administrator keep copies of everybody's ssh-keygen file in a secure location (USB thumb drive?) Or should ssh-keygen be rerun in the case of a problem? My personal opinion is that a USB thumb drive is *not* a secure location. Due to their small size and easy misplacement (now, I thought I had that in my pocket...wonder where it got off gto). My opinion only, of course. 5) Is there any way for the administrator to guarantee that the user uses a passphrase on his ssh-keygen key file? I can't find it Not that I know of. 6) In any of the above, should logging on with a password be disabled by removing the password from /etc/passwd or /etc/shadow (I forget how to do that, off hand - I can look it up.)? 7) I think the above removes the ability to do an su to the userid by any other user than root. True? Thanks for any thoughts. If too off-topic, please just ignore this or email me directly to go away, boy. You're bothering me. (W.C. Fields?) Close...it was William Claude Dukenfield:-) DJ -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On 4/2/07, McKown, John [EMAIL PROTECTED] wrote: 3) How do you give the key to the other person? USB thumb drive? Email shudder? I guess that emailing a public key would not be bad. True? The only requirement is that the admin can be certain that this is indeed the public key of user A and not of user B. The risk to address is that user B interferes with the communication and replaces the public key by one for which he has the private key. If your organization has some other reliable way to have the user authenticate himself (e.g. RACF) you could have the user send the public key from there. Or if you have a trusted web application you might have the user upload the public key there. Alternative would be to run ssh-keygen for the new user through some trusted web interface, store the public key on a central place and allow the private key to be downloaded (and discard it after that). 4) Should the administrator keep copies of everybody's ssh-keygen file in a secure location (USB thumb drive?) Or should ssh-keygen be rerun in the case of a problem? No, that would mean the system admin also has access to the user's private key which is not what you want. I would hope a sysadmin has ways to get access to the system and he does not have to use someone else's identity for that. If the user has reason to believe his private key and passphrase are compromised, he would generate a new key pair and give the new public key to the sysadmin. One problem is that you need to remove all occurrences of that compromised key. If you cloned systems and put public key of all support staff in those systems, that may be hard. 6) In any of the above, should logging on with a password be disabled by removing the password from /etc/passwd or /etc/shadow (I forget how to do that, off hand - I can look it up.)? You do that in the sshd.conf. There's an option to disable plain text passwords Yes, I think you should disable that. We did it slightly different with an experimental patch to OpenSSH that allows for the public keys to be kept in LDAP. That means there's only one place where the public key is held. That LDAP server would allow the end-user to upload a (new) public key through some authenticated interface. And the Linux servers can trust that LDAP to provide the right public key. The same LDAP also gives user and group information for Linux to allow login. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On 4/2/07, Adam Thornton [EMAIL PROTECTED] wrote: 7) I think the above removes the ability to do an su to the userid by any other user than root. True? Removing the password certainly would. Tee hee hee. If you have an automatic login of root on the console, that should provide enough escape for when all other things fail. Funny enough security rules at my previous place did not allow this. We were not allowed to have no password for root, but were required to set a new one every so-many days. :-( -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
Rick wrote: If you have an automatic login of root on the console, that should provide enough escape for when all other things fail. How are you setting that up? I've looked and it wasn't obvious to me. Thanks in advance. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Mon, Apr 2, 2007 at 11:55 PM, in message [EMAIL PROTECTED], Marcy Cortes [EMAIL PROTECTED] wrote: Rick wrote: If you have an automatic login of root on the console, that should provide enough escape for when all other things fail. How are you setting that up? I've looked and it wasn't obvious to me. This entry in /etc/inittab is how I do it in Slack/390: 1:12345:respawn:/bin/bash -i Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
That sounds like a recipe for disaster unless you have the tightest of physical security. On Mon, 2 Apr 2007, Mark Post wrote: On Mon, Apr 2, 2007 at 11:55 PM, in message [EMAIL PROTECTED], Marcy Cortes [EMAIL PROTECTED] wrote: Rick wrote: If you have an automatic login of root on the console, that should provide enough escape for when all other things fail. How are you setting that up? I've looked and it wasn't obvious to me. This entry in /etc/inittab is how I do it in Slack/390: 1:12345:respawn:/bin/bash -i Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Philosophy: connecting to a Linux server
On Tue, Apr 3, 2007 at 1:31 AM, in message [EMAIL PROTECTED], shogunx [EMAIL PROTECTED] wrote: That sounds like a recipe for disaster unless you have the tightest of physical security. For z/VM guests, you have to get past the physical security, and know the userid and password of the Linux system. For LPAR installs, let's just say I haven't seen too many mainframes sitting in wiring closets. Except for SHARE, WAVV, etc., I haven't actually been anywhere near a mainframe in years and years. Tightest of physical security doesn't begin to approach what most mainframe shops employ. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
